Plugin Control

Last updated by Joss

Although, as I understand it, the architecture of Elgg forces consistency in the back end desgn of plugins, there seems to be less consistency as to the UIs plugins - this applies both to settings handled by the administrator and any customisation by users.

A reworking of the management interface for plugins could benefit both users and developers by creating a rigid UI framework that allows all to concentrate on what the plugin does rather than how to make it do it, if you see what I mean. Part of that UI would be the permissions side of it that would be common to all plugins allowing the administrator to define who has access to the plugin and to what level.

But this should also extend to templating and customisation. For instance, all input text boxes in all plugins should have, by default, a common class so that they automatically fit in with the site theme. However, this class could also be overridden per plugin by the addition of a class suffix. A similar feature is used in Joomla for the customization of individual modules.

If all plugins always start from the same point, then site administrators will find overall site control much easier and there will be less need to hack individual plugin scripts or need to jump from one css file to another. By the way, I accept that this is probably better currently than I am painting, I have just run into one or two oddities!

Control of plugins from both the admin and user UI should always be the same. One example could be a tabbed interface broken up into:

  • General Settings - standard stuff like enable/disable, Name of plugin, Description, etc (customisable because you may want to call it a Board instead of a Forum) 
  • Permissions - which roles can do what by default
  • Look and Feel - style suffix, icon, background image, borders, edit CSS 
  • Plugin Settings - additional settings peculiar to the specific plugin.

A similar UI would be presented to the user when they add the plugin to their profile page, group, and so on, again, keeping the layout and the naming of settings consistent. Incidentally, this can reduce documentation enormously!

Note: I have expanded this in more detail here: