Administration Menu

imageThe most important aspect of the administration system is the menu. After all, it is the way we get around! Also, a menu, objectively, defines the areas that an administrator would wish to control and may allow a certain amount of restriction to certain areas. Having looked at the admin in 1.8 and other systems, here is my suggestion.

The menu would be contained in a sidebar (as with 1.8) probably using the same script.  Each section would contain a site function plus all plugins associated with that function. This means that plugins should be allocated to a specific category. Where a plugin modifies and existing function (such as blogs) then this plugin is automatically added to the correct category and to the mother plugin.

Top Level Menu Items

  • Content - things like blogs, pages, and so on. This would also include global settings for these plugins where the user has sufficient privileges
  • User - this section would include management of users, roles, groups, and so on.
  • Plugins - this would be where plugins are enabled/disabled, uploaded, updated and so on. It would have no settings
  • Site Management - this would be where various settings such as site template, metadata, and so on is controlled. Also, for those with sufficient privilages, it would contain access to database settings, javascript and other libraries, domain settings and so on.

Here is a break down of the sections:


The following would be default content items/plugins that are installed with the system:

  • Blogs
  • Discussions
  • Pages/CMS
  • Document/file management

These will appear, even if disabled, since they may contain content that should be available to the administrators.

Other plugins that might be added to this would be an announcement system, image galleries, and so on.

Each item would contain three default pages:

  • Settings - Any settings that effect all instances of the plugin including global enable/disable
  • Permissions - which roles have access to the plugin globablly with regard to read and write.
  • Plugins - any additional functions supplied by add on plugins

In addition, various other actions can be performed. In the case of blogs this could be layout and other template defaults, seeing what blogs exists and being able to disable those indivdual instances, central moderation of all blogs, and so on.

Other plugins would have additional functionality depending on the plugin - it would be up to the developer to create these management functions in line with the guidance.


The user section would containt the following menu items:

  • User Management - a section where users can be added, authorised, given roles, suspended, banned and so on. Must include search tools
  • Profile Management - This is where all editing of the default profile fields and layout is carried out, also moderation of profile content.
  • Role Management - a complex area where roles can be created and then given specific permissions depending on what is required. Default roles would include administrator (one below super admin), moderator, guest, member, group member, group moderator, group administrator.
  • Group Management - a section where groups can be created, moderated, disabled, have members added removed, group templates set, global group settings, and so on. This also contains the master group which is effectively the landing area of the site - this group cannot be removed or disabled while it is the master group. However, it can be swapped with another group.
  • Registration - this would include management of the registration system, any plugins relating to registration, enabling/disabling of registration, and so on.


This is a fairly straight forward are which just manages plugins. The plugins can be sorted by category (categories relating to the other menu sections and sub sections) or alphabetically and so on. Each can be enabled or disabled singularly or globally. Also, plugins can be installed, deleted or updated from here.

Site Management

At the risk of this being the "everything else" category, here are the main sections:

  • General settings - site name, meta data, etc
  • Email - out going email settings (phpmailer, SMTP, sendmail), site from name, site email address, global html/text settings and so on.
  • Look and Feel - site overall template, available templates and layouts for groups, profiles and so on, some CSS settings, site logo, and so on
  • Core Settings - database management (name, backup), site back up, data directories, libraries and so forth.
  • I have added an artist impression of a possible admin console using the above specs - click on it for a larger version.

  • Note:

    I realise I have left out a few menu items, not least of which all logs and statistics which should have a section of their own, but this is just an idea.

  • It is tough for me to separate the implementation challenges from the design issues.

    I'm trying to generalize on the overall principles of these comments:

    • keep the display consistent across the different admin pages.
    • organize the menus by purpose
    • related to above: admins do not care about the settings of individual plugins but prefer a more wholistic presentation of the administration of the site


  • To steal from Microsoft, it comes under the "what do you want to do today" situation.

    From my point of view, when I go into the back office of any application I want to be able to head to a specific area fairly directly. Over geveralising, I probably want to do one of three things - manage content, manage people and manage under the hood; the latter would include template issues, I suppose.

    I think your three points say what should happen neatly. TO expand a little, mostly to clarify ...

    • keep the display consistent across the different admin pages - this basically stops suprises and means once you know how to manage one plugin, you can probably work out the others.
    • organize the menus by purpose - simply to speed up the "what do you want to do today" bit.
    • related to above: admins do not care about the settings of individual plugins but prefer a more wholistic presentation of the administration of the site - The first tab of any plugin should always be the thing you are most likely to want to do on a day to day basis I suppose. Each tab along should be lower in priority. 

      In my image I probably have it the wrong way round. For a discussion plugin it would be Moderation - Settings - Permissions - Plugins, and then an additional one, Help! (That can contain documentation from the plugin developer - I forgot about that bit)

    So yes, I think you have summed it up better than I did!

  • Note about widgets:

    Widgets would more often than not be an underclass of plugin subservient to a major plug in, and should be managed with that in mind.

    For instance, A widget showing recent posts to groups you belong to, or a widget isolating that forum (and other) so that you can display them together on your dashboard, would belong to the Forum plugin. These widgets would be managed under the Plugins tab of the forum management screen. Management options would include enable/disable globally, making available to only certain roles and/or groups and so on.