The Elgg core does not do much by itself. It provides the foundation and the plugins determine what the web application truly does. Elgg is distributed with more than 30 plugins that are referred to as bundled plugins. Additional plugins are available from the Elgg community site (http://community.elgg.org/) and Elgg's Github site (https://github.com/Elgg).
Plugins can add significant user-facing functionality or customize minor backend processing. They can override core functionality or extend it. Building a website with Elgg requires writing and using plugins. Chapter 7 and 8 provide a tutorial-based approach to learning to write plugins.
Plugins are installed in the /mod/ directory. Each directory in /mod/ is a plugin. Plugins are structured like mini versions of the Elgg core (though only the classes, languages, and views directories are required to have those names):
/actions/classes/graphics/languages/pages/vendors/viewsstart.phpmanifest.xml
The manifest file describes the function of the plugin and this information is used on the plugin administration page. The start.php file is the boot script of the plugin. It registers callbacks, extends views, and performs other initialization.
When Elgg loads, it includes the start.php file of each activated plugin. In start.php, a plugin registers a handler for the 'system', 'init' event:
elgg_register_event_handler('init', 'system', 'blog_init');This event is triggered when all of the core libraries and plugins have been loaded. It is in this event handler that the plugin does its initialization:
function blog_init() {
elgg_extend_view('css', 'blog/css');
elgg_register_page_handler('blog', 'blog_page_handler');
// Register for search.
elgg_register_entity_type('object', 'blog');
$action_path = dirname(__FILE__) . '/actions/blog';
elgg_register_action('blog/save', "$action_path/save.php");
}This occurs before a request is dispatched to a handler (action or page handler).
Plugins can override views, actions, and language strings. If more than one plugin overrides the same view, then it is the plugin that loads last that has its view used. The same is true for anything else that can be overridden. The plugin order is set on the plugin administration page.
An important convention when writing plugins is namespacing the code to prevent conflicts with other plugins or future additions to the core framework.
Functions normally include the name of the plugin:
function blog_url_handler($entity) {The same is true for language strings (described later in this guide):
'blog:revisions' => 'Revisions',
Views should be namespaced by creating a directory under the default directory named after the plugin:
/mod/blog/views/default/
/blog/
/sidebar/
/css.php
/group_module.phpActions should also begin with the name of the plugin:
elgg_register_action('blog/save', "$action_path/save.php");In addition to these naming conventions, there are Elgg coding standards included in the docs directory. These are the standards that the core developers follow.