Organising and Administrating Plugins

Last updated by Joss

The interface for plugins is, currently, rather confusing. Plugins are displayed in the administration section as one long list with core plugins, tool plugins and layout plugins all mixed up together.

This can cause problems with bugs as it is not clear which plugins are dependant on another, which ones reuse code and so on. There also seems to be a problem with the plugin architecture where the visual layout of the plugin list may have an impact on plugin functionality - I have come across several plugins that say they need to be at the bottom of the list to work which is awkward if you have more than one with that requirement.

Separating into Logical Departments

Bricks and mortar companies are organised by department; each department having specific roles within the organisation. For instance:

  • The Management makes all policy decisions
  • The IT department designs solutions that fulfill those policies
  • The CR/Sales department offers those solutions to the customer
  • The Editorial department has control of any output from those solutions.

It is easy to see how this can be translated to Elgg. Let us take a blog

  • The management decides whether a blog should be made available and what functions it should have
  • The IT department install the blog and customise it to the management brief - they also are responsible for upgrades and so on
  • The CR/Sales department inform the users that a blog is available and enable/disable it for them (side note: this could allow for charging for enabling!)
  • The Editorial department would scrutinise the blogs to ensure they are suitable for the site and moderate them.


This sounds very complicated, but it can be a useful way of separating out the obvious management of any plugin function, even if all the roles are, in reality, fulfilled by just one person!  Some solutions like Joomla have attempted this over the years, but to be honest the result is a mess. Getting the administration section split up in a really clear way (as clear as walking down a corridor and into the right department) would give Elgg a real edge over its competitors.

Plugin Types

Currently, all plugins are grouped together. It would make more sense to group them as follows:

  • Core functionality
  • Layout/template and style plugins
  • End user tools


This allows better organisation of the installation and management of the plugins since it is clear how they are grouped and what role they play. This should also allow for plugins that are designed to modify or effect another plugin - so expanding the blog plugin panel, for instance, would list any additional plugins that have been installed relating to the blog (templates, for instance) and dependencies such as library plugins. Maybe the development of a Plugin Tree, a bit like a family tree, would help this process further.

This is separate from the Departments above since that is about roles where as this is the pure organisation from the point of view of the IT department!


Development and Installation


A plugin developed along the same organisational lines may come in three parts - additional required core functionality, layout and style requirements, and the final tool (the install script would install all three parts, of course).

This method encourages the use of libraries and reusable code and by allowing the install procedure to check for dependencies and downloading and installing required parts, hopefully the system is less prone to getting bloated out by repeat code and the requirement to be “at the bottom of the list” is removed.

Again, this also helps debugging and trouble shooting since the admins have a really solid idea how their particular installation is nailed together.

In addition, this sort of management should eliminate the need to use FTP to install a plugin - the best method being to download from a repository. (installing and upgrading on wordpress is a joy!).

Note, since some developers do, understandably, charge for plugins, some function needs to be added where having purchased a plugin, you can then use the new installation procedure to fetch and install the plugin, complete with dependencies. Where a commercial plugin requires a commercial dependency, then this must be taken into account and the end user made aware that they may need to purchase other bits and how much they will cost.