Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Frankenstyle

From MoodleDocs
Important:

This content of this page has been updated and migrated to the new Moodle Developer Resources. The information contained on the page should no longer be seen up-to-date.

Why not view this page on the new site and help us to migrate more content to the new site!

'Frankenstyle component names' refers to the naming convention that is used to uniquely identify a Moodle plugin based on the type of plugin and its name. They are used throughout the Moodle code (with a notable exception being the css class names in the themes).

Martin Dougiamas invented the word 'frankenstyle' to describe this naming system which was invented by Petr Škoda.

Format

Frankenstyle component names have a prefix and then a folder name, separated by an underscore.

  1. The prefix is determined by the type of plugin. For example, the prefix for an activity module is mod.
  2. The name is the folder name of the plugin, always lower case. For example, the name for Quiz is quiz.

So the frankenstyle component name for the quiz module is mod_quiz.

Plugin types

See Plugin types page for the list of all supported plugin types in Moodle and their frankenstyle prefix.

To get a definitive list in your version of Moodle 2.x, use a small Moodle script with print_object(get_plugin_types());.

Core subsystems

Subsystems in Moodle are not plugins themselves but can be referred to using core_xxx where xxx is the subsystem name as defined in get_core_subsystems().

You can see these being used in the @package parameter in phpdocs, or in the webservice function names. Core subsystems can provide own strings via a file stored in lang/en/{subsystemname}.php. Some of them have a dedicated location with libraries, autoloaded classes and other resources.


Core subsystem Frankenstyle component name Location
Access core_access
Administration core_admin /admin
Antivirus core_antivirus /lib/antivirus
Authentication core_auth /auth
Conditional availability core_availability /availability
Backup and restore core_backup /backup/util/ui
Badges core_badges /badges
Blocks core_block /blocks
Blogging core_blog /blog
Bulk users operations core_bulkusers
Caching core_cache /cache
Calendar core_calendar /calendar
Cohorts core_cohort /cohort
Comment core_comment /comment
Competency based education core_competency /competency
Completion core_completion /completion
Countries core_countries
Course core_course /course
Currencies core_currencies
Database transfer core_dbtransfer
Debugging core_debug
Text editors core_editor /lib/editor
Education fields core_edufields
Enrol core_enrol /enrol
Error reporting core_error
Favourites core_favourites /favourites
File picker core_filepicker
Files management core_files /files
User filtering core_filters
Forms core_form /lib/form
Grades core_grades /grade
Advanced grading core_grading /grade/grading
Groups core_group /group
Help core_help
Hub core_hub
IMS CC core_imscc
Installer core_install
ISO 6392 core_iso6392
Language pack configuration core_langconfig
License core_license
Maths library core_mathslib
Media core_media
Messaging core_message /message
MIME types core_mimetypes
MNet core_mnet /mnet
Dashboard core_my /my
User notes core_notes /notes
Page types core_pagetype
Pictures and icons core_pix
Plagiarism core_plagiarism /plagiarism
Plugins management core_plugin
Portfolio core_portfolio /portfolio
Privacy core_privacy /privacy
Course publishing core_publish /course/publish
Question bank engine core_question /question
Ratings core_rating /rating
Site registration core_register /admin/registration
Repository core_repository /repository
RSS core_rss /rss
Roles core_role /admin/roles
Global search core_search /search
Tabular data display/download (deprecated) core_table
Tagging core_tag /tag
Timezones core_timezones
User core_user /user
User key core_userkey
Web service core_webservice /webservice

Usage

Frankenstyle component names are used in:

Function names

All plugin functions must start with full frankenstyle prefix. For backwards compatibility modules may also use modulename_ as prefix.

Class names

  • All the component classes must sit under the classes (auto-loaded) directory, belonging to their frankenstyle namespace and having a natural name, ex: \mod_forum\example.
  • The use of class names using the frankenstyle prefix is now deprecated (see Coding style), ex: mod_forum_example.

Constants

All plugin constants must start with uppercase frankenstyle prefix, example MOD_FORUM_XXXX.

Table names

All table names for a plugin must begin with its frankenstyle name (after the standard Moodle table prefix).

(The exception to this rule is Moodle activities which (for historical reasons) do not have mod_ in front of the plugin name)

Examples: mdl_local_coolreport, mdl_local_coolreport_users

Plugin configuration table

In the config_plugins table, column plugin, the frankenstyle name is used.

Capabilities

All capabilities for a plugin use the frankenstyle name, except with a / instead of a _.

Example: mod/quiz:viewattempt

Language files

The main language file for each plugin (with the notable exception of activity modules) is the frankenstyle component name.

Examples: /blocks/participants/lang/en/block_participants.php

Renderers

Module Subplugins

It is possible to extend modules without having to change the basic module's code. See Subplugins for details.

Other places (TODO)


Please add more as they come up.

Naming theme variants

Themes that are principally derivatives of some other theme, should be named in a way that clearly implies they are variants, not upgrades, of the parent theme. The format of the name should follow and extend the standard component naming format. So for example themes based on Boost, if they want to mention the word "boost" in the component name, should be named like

theme_boost_something

for example theme_boost_spring, theme_boost_summer, theme_boost_shiny etc. Indeed they can be named just like

theme_something

as there is no need to repeat the parent name (e.g. theme_spring, theme_summer, theme_shiny). The point and reasoning behind this is to avoid confusion - for example a theme_boost2 looks like a new version of the official Boost theme and as such is not a good name for a contributed theme.

See also