The following is the standard for plugin structure in Elgg as of Elgg 1.8. Plugins written for Elgg 1.7 and down are strongly encouraged to use this structure as well, though some of the benefits are not as apparent as when used in 1.8.
The following is an example of a plugin with standard structure. For further explanation of this structure, see the details in the following sections. Your plugin may not need all the files listed
The following files for plugin
example would go in
actions/ example/ action.php other_action.php classes/ ExampleClass.php graphics/ example.png js/ example.js languages/ en.php lib/ example.php pages/ example/ all.php owner.php vendors/ example_3rd_party_lib/ views/ default/ example/ css.php forms/ example/ action.php other_action.php js/ example.php object/ example.php example/ context1.php context2.php plugins/ example/ settings.php usersettings.php widgets/ example_widget/ content.php edit.php activate.php deactivate.php CHANGES.txt COPYRIGHT.txt INSTALL.txt LICENSE.txt manifest.xml README.txt start.php
Plugins must provide a
manifest.xml file in the plugin root in order to be recognized by Elgg.
Therefore the following is the minimally compliant structure:
mod/example/ start.php manifest.xml
Plugins should place scripts for actions an
actions/ directory, and furthermore should use the name of the action to determine the location within that directory.
For example, the action
my/example/action would go in
my_plugin/actions/my/example/action.php. This makes it very obvious which script is associated with which action.
Similarly, the body of the form that submits to this action should be located in
forms/my/example/action.php. Not only does this make the connection b/w action handler, form code, and action name obvious, but it allows you to use the new (as of Elgg 1.8)
elgg_view_form() function easily.
Plugins may provide various *.txt as additional documentation for the plugin. These files must be in Markdown syntax and will generate links on the plugin management sections.
- should provide additional information about the plugin of an unspecified nature
- If included, must provide an explanation of the plugin’s copyright, besides what is included in
- If included, must provide the text of the license that the plugin is released under.
- If included, must provide additional instructions for installing the plugin if the process is sufficiently complicated (e.g. if it requires installing third party libraries on the host machine, or requires acquiring an API key from a third party).
- If included, must provide a list of changes for their plugin, grouped by version number, with the most recent version at the top.
Plugins may include additional *.txt files besides these, but no interface is given for reading them.
Plugins should put page-generating scripts in a
pages/ directory inside their plugin root. Furthermore, plugins should put page-generating scripts under a directory named for their handler. For example, the script for page
yoursite.com/my_handler/view/1234 should be located at
In the past, these scripts were included directly in the plugin root. Plugins should not do this anymore, and if any core plugins are found to do this, that is a bug if not present solely for the sake of backwards compatibility.
The reason we encourage this structure is
- To form a logical relationship between urls and scripts, so that people examining the code can have an idea of what it does just by examining the structure.
- To clean up the root plugin directory, which historically has quickly gotten cluttered with the page handling scripts.
All classes that your plugin defines should be included in a
classes/ directory. This directory has special meaning to Elgg. Classes placed in this directory are autoloaded on demand, and do not need to be included explicitly.
Each file must have exactly one class defined inside it. The file name must match the name of the one class that the file defines (except for the “.php” suffix).
Files with a “.class.php” extension will not be recognized by Elgg.
Included third-party libraries of any kind should be included in the
vendors/ folder in the plugin root. Though this folder has no special significance to the Elgg engine, this has historically been the location where Elgg core stores its third-party libraries, so we encourage the same format for the sake of consistency and familiarity.
Procedural code defined by your plugin should be placed in the lib/ directory. Though this folder has no special significance to the Elgg engine, this has historically been the location where Elgg core stores its procedural code, so we encourage the same format for the sake of consistency and familiarity.
In order to override core views, a plugin’s views must be placed in a
views/. This directory has special meaning to Elgg as views defined here automatically override Elgg core’s version of those views. For more info, see Views.
plugin/js view and your plugin should extend
activate.php and deactivate.php¶
deactivate.php files contain procedural code that will run respectively upon plugin activation or deactivation. Use these files to perform one-time events such as registering a persistent admin notice, registering subtypes, or performing garbage collection when deactivated.