Frankenstyle

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

Module Subplugins

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

Other places (TODO)

• @package declarations in phpdocs, see Coding_style#PHPDoc
• web service function names
• Moodle Plugins database

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

• Plugins
• Subplugins
• Core APIs
• Automatic class loading