[development] Remove top-level admin menu items
mroswell at gmail.com
Sun Feb 1 19:15:17 UTC 2009
What to do when the Admin menu gets too long under configuration?
Small fonts of course, one option, but these bespectacled eyes have a
tough time seeing them.
On Sun, Feb 1, 2009 at 1:58 PM, dragonwize <dragonwize at gmail.com> wrote:
> 100% Agreed. Another module I would lump into this category is
> Embedded Media Field. EMF has its configuration under Content
> Management when it is clearly entirely configuration. So much so that
> the menu link item is actually named "Embedded Media Field
> On Sun, Feb 1, 2009 at 12:17, Daniel F. Kudwien <news at unleashedmind.com> wrote:
>> This goes out to some maintainers, specifically related to
>> - Notifications / Messaging
>> - Organic Groups
>> - Panels
>> Those and related/dependent modules are implementing top-level menu items, e.g.
>> - admin/messaging
>> - admin/og
>> - admin/panels
>> in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed.
>> I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building".
>> In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management".
>> Unfortunately, my request for changing this in Notifications was immediately won't fixed , which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules.
>> If the only thing that prevents this from changing are patches, then I'll happily submit some.
>>  http://drupal.org/node/366489
More information about the development