With the release of Joomla! 1.5, the CMS is moving toward a much more modular structure. That is, the core components are getting less and less special treatment, and it is now much easier to implement functionality through developing custom extensions that can replace the core functionality. The user registration and login and authentication processes are prime examples of this, as it is now possible to authenticate users against any number of sources very easily.
There still remain some deficiencies. One significant area is the administrator menu. Everything that is invoked from the administrator menu is a component. From global configuration, to help, to the menu manager, to content. Most of this functionality can be extended or alternatives can be provided using third party components. However, certain core components still get special treatment by nature of their placement in the administrator menu.
Some simple examples are com_content and com_installer. An alternative content component could be developed that could be used as an alternative to the core com_content. So much is possible with the current framework. But a new system would always be second class to com_content, and really only because of its privileged placement in the menu.
A third party installer could also be developed, that would expand on the functionality of the core installer. But an additional installer would always have to be dug into the Components menu.
Additionally, this could really be useful for site administrators where others are working on the site. The menu could be rearranged so that it is more specific to the group that is using the site. Much of the complexity could be hidden so that the interface is even simpler for some users. Users would quickly be able to reach the items they need, and less frequently used items would be hidden.
The mod_menu module in the backend could be modified to work similar to the frontend menus. Therefore, the administrator menus would be managed in a similar (but not same) as the frontend menus. It should not be possible to add or delete entries in the administrator menu – these entries should only be provided by components (as specified in XML files at install time), only move them to different menus.
As an example, by default, there would be seven menus that come preinstalled: 'Site', 'Menu', 'Content', 'Components', 'Extensions', 'Tools' and 'Help'. These menus by default could have their current items in them. But the administrator would be able to move the items between these various menus. New menus can be created and menus can be deleted, but you must always have at least one menu (and if you only had one menu, all the items would be in that one menu).
It may be desired as well to have an option that would be 'Reset Menu to Default', which would reset all the menus to their original places.
Affect on Change Management
I do not believe that this feature would have a significant affect on change management. It would only be available to Super Administrators. The onus would be on them to use it or not to use it. It may require retraining on the part of the administrator, but that would be a choice that would be made by the organization hosting the site. What I'm trying to say here is that the feature would be transparent unless an administrator decided to use it.
Impact on Existing Architecture
I believe that the impact on the existing architecture would be minimal. The adminstrator menu is handled by mod_menu in the backend. This feature would require a component to perform the management, which could be similar to the existing com_menus.
It would require a change to com_installer so that when components are installed their menu items are added into jos_menu. It would also require an additional field in the jos_menu_types table so that the menus can be distinguished. A better implementation may be to create a new table to reduce the impact on mod_mainmenu that is used in the frontend. If the same table is used, mod_mainmenu must have its parameters revised so that administrator menus cannot be selected for display in the frontend. The same could be said for third party menus.
Functional Description of UI Elements
The administrator menus would be handled in the same way that the site menus are managed, with the following exceptions:
- There would be no functionality to Edit, Create, Delete or Copy menu items. It is up to the components to determine which menu items are available
- There would be no default menu item
- The Published/Unpublished functionality would have the similar effect, except it would be called 'Hide/Show'. This would allow some menu items to be hidden
- The Hide/Show functionality would have no effect when a Super Administrator is viewing the site. This is to prevent the Super Administrator from irrecoverably destroying the site (i.e. they can't hide key functionality from themselves). If this is implemented in conjuction with ACL, I would expect that this would be true of anybody who is access to modify the admin menus.
There are three main steps required for implementation of this feature:
- Modification of com_installer to add component menu items to an admin_menus table.
- Creation of a new menu manager that would manage the new menu items.
- Creation of a new mod_menu module to render the new administrator menu.