Administration menu or admin_menu should be in core.

To substantiate, one needs to download and install both the above and the Drupal 7 dev version.
Admin_menu and the upper admin bar in Drupal 7 looks almost same but admin_menu is more nifty.
It gives direct and easy access to specific pages without the need for page scrolls or going through extra page loads. The Drupal 7 admin bar looks more like the standard left side menu which has been horizontalised and stuck at the top, with probably no option to unfix it if I want.

It can be argued that Site Configuration drop down can become longer when there are 100 modules but apart from system/core modules others can be left out then with just link to a page of contribs. The rest is easier and direct access, what an admin bar is supposed to be. It is also more descriptive and useful in certain areas like "Add new content" rather than "Add" which being non-contextual adds confusion at least in a few sections.

Personally I found no problem with the system that was in Drupal 6 but usability tests must have confirmed the need of the bar. If the bar has to be there I feel admin_menu should be there.


sun’s picture

Status:Active» Closed (won't fix)

I have learned that Administration menu is for advanced Drupal users only.

kaakuu’s picture

How ?

The project page says "It's a helper for novice Drupal users coming from other CMS"
But I based my observation not from what the project page says but what actually it does.

Neutrally try both and see.

Edited : Apart from Views, CCK, Pathauto it is the MOST commonly used module and lesser used modules are already on the way to core. Just a fact.

sun’s picture

I am quite sure that marking this issue won't fix makes a few other Drupal contributors happy.

It does not make me happy. Especially, because it is my belief that every CMS needs to expose its functionality the way admin_menu does.

However, we have a UX team (and even had a few "UX experts") that already "took the decision" that admin_menu does not belong in Drupal core. Whatever that decision is based on.

Drupal core contributors, as of now, spent a lot of time for duplicating a tiny part of admin_menu's functionality. That work has been committed. And within the remaining time-frame, there is no way to revert and replace this with a proper implementation.

Since most of the current UX efforts seem to forget about the actual user, I'm still trying to prevent other shit from hitting the fan (core) as much as possible. But it's especially hard to follow all issues, because the actual conception lives deeply hidden in arbitrary videos on the net (which is quite similar to the new, envisioned IA for Drupal).

From now on, your first step after installing Drupal is to disable Toolbar module and enable Administration menu.


kaakuu’s picture

Status:Closed (won't fix)» Active

I do not quite follow you ;)

I believe none of the UX decisions are In stone, and I do not understand if not the entire module why some functions cannot be implemented particularly when we are attempting user ease.

What is easier ? Click Add and reach a page of scroll when you have plenty of content types and then click again ? OR just click "Add Poll" and go there?

I will mark this as active again so that in history there is no repentance that no one strongly advocated it. Of course it can be marked "fixed" or "by design" again. I will just change the stamp once.
Not keeping it in core merits better explanation than what has been given here or elsewhere, imho.

PS: Instead of making "Drupal contributors happy." the larger perspective or motto should be make "Drupal users happy".

VM’s picture

admin_menu was never in core, so there is no issue with:
"Not keeping it in core merits better explanation than what has been given here or elsewhere, imho.".

I think what sun is trying to explain here in a diplomatic fashion (correct me if I'm wrong sun) is that he advocated and tried to get admin_menu in core and was passed over in favor of the current incarnation in D7.

kaakuu’s picture

VM, by "not keeping it in core" means by not adding it into core. If that helps!
Sorry, for the language problem.

I hope the real issue is obvious and you can follow it. Is it +1 or -1 from you btw ?

VM’s picture

+1 or a -1 from me is moot as the decision has already been made in this area from what I understand and based on what I see when testing D7.

there is no way to revert and replace this with a proper implementation.

The above is pretty important information, and beyond that eyes and ears are on other issues with the pending code freeze. That said, next time up would be D8.

kaakuu’s picture

Yep! Long old threads or issues come up and got implemented from previous to later versions in Drupal.

Even at this stage if someone at the highest level, find something really useful, if it strikes him like it not struck before decisions or implementations can be reversed, or at least there are many such examples in many software's career.

If it is "next time up would be D8", your +1 or -1 will still matter.
@VM - don't shy away. Give a +1 or -1 for the future. It will take a nanosecond and not waste your time on other issues :)

sun’s picture

I think what sun is trying to explain here in a diplomatic fashion (correct me if I'm wrong sun) is that he advocated and tried to get admin_menu in core and was passed over in favor of the current incarnation in D7.

I think that this was the diplomatic fashion of my frustrated rant.

Anyway. To also close down #543932: Remove the words "It's a helper for novice Drupal users" ?, let me clarify: It was the UX team's decision that Administration menu is suitable for advanced users only. I won't (ever) agree with that, but it is their (wrong) assumption.

D7 has to live with the half-baked thing called Toolbar. Until this gets relevant for D8, Administration menu will have advanced to further areas (probably always >2 years ahead of Drupal core). So there is no point in keeping this issue active.

sun’s picture

Status:Active» Closed (won't fix)
bibo’s picture

D7 has to live with the half-baked thing called Toolbar. Until this gets relevant for D8, Administration menu will have advanced to further areas (probably always >2 years ahead of Drupal core). So there is no point in keeping this issue active.

This is just sad.

admin_menu is awesome and always the first module I install. I can't believe it won't be in D7 core. Browsing the admin-pages without it is simply frustrating. As I see it, leaving it out can only benefit Drupal's CMS competitors.

Sorry for the bother, but can someone tell me what is it that makes admin_menu for advanced users only? Maybe some UX Expert wants to clarify?

WorldFallz’s picture

Wow, this is sad indeed. I have tons and tons of drupal install batch and script files to ease installation and testing of various 'distributions' and admin_menu is the only contrib that appears in absolutely ALL of them. It is, without a doubt, the single biggest time saver in existence. And yes, I found it, installed it, and used it, when I was just a novice.

What's worse, is I checked out checked head this past weekend for the first time in a month or two, and was completely thrown by the new "IA" and toolbar module. Nothing worked as expected. Granted I'm not a novice any more, but I still shouldn't have been so completely thrown off.

I was a usability engineer for many years-- one of the reasons I sought to leave was exactly because of the rise of the so called "experts" at the expense of actual users. Anyone can posit a hypothesis and obtain user test results to reinforce their agenda-- it's really not that difficult. Though in this case it sounds as if the phony user tests were completely bypassed. It's really too bad.

The only good news is with drush I can even automate the disabling of the toolbar and enabling of admin_menu. ;-)

sun’s picture

Status:Closed (won't fix)» Active

It seems like people want to discuss this publicly.

kaakuu’s picture

Thanks. And Yes, yes, yes.
People who download bundled packages are not botherd much which one is core or which one is contrib - they just 'get' the things. Acquia bundles it as default so there is no reason Drupal should not bundle it as default. It does not increase the weight of the light weight core too, instead makes things useful and worthwhile if we have to use an admin bar.

snowmountain’s picture

I think discussions like this help people to see things that perhaps they had not considered, and thereby aid the development process.

I normally would expect to at least be able to understand the reason for the decision, even if I may disagree with it. I just don't see this at all. Please help me to see it. If anyone can point out the benefit - real or even imagined - to newbie users of not having this in core, please share this here. (I'm not talking about the reason that says "it's not for novices" - I'm asking, what is the reason that it is it not for novices? WHY is it not for novices?)

I usually can see arguments for AND against a lot of things - say, Drupal and Joomla. Though I prefer one, and perhaps even think the arguments against the other are not valid, I can at least understand what the arguments are - what they say and claim (even if I tihink the claims are false).

In this case, though, I honestly fail to see any reason at all for this decision. Excuse me if I am missing something. If there is any rationale, it would clarify the issue and help this discussion to have any reason(s) declared. (I am almost thinking there aren't any.)

If the reason is that it's too complicated, then I would ask, isn't the Naviagation menu already there with the same items? Isn't that just as complicated? Even more complicated, since it's a bit more difficult to access, and thus "more hidden" and more difficult?

Anything that makes the job easier makes sense for the novice. The novice would benefit from this.

In a big project, with lots of decisions to make, and a rush to make them quickly, it is possible for developers to overlook the reasons for making one decision, and not give enough time to consider it thoroughly, so that a wrong decision could be made. I hope this isn't happening here but it looks as though it may be.

rszrama’s picture

Just to add to the support, I didn't know this issue already existed when I posted #557352: Admin Menu preserves my Drupal 7 sanity in the Admin Menu issue queue. I didn't quite get why we'd have a toolbar in core without dropdown menus when Admin Menu has been doing this elegantly for some time. With the extra toolbar styling module enabled on the site, Admin Menu rocks my socks. \m/

Basically, I collapsed the Toolbar first, because it took up too much screen real estate. I then later discovered it was a module and that Admin Menu had a 7.x-dev release, so I disabled Toolbar and enabled Admin Menu straight away. This may be because I'm advanced, but when it came to the D7 IA I was a total novice and was absolutely lost. (There was already a related issue, but I totally didn't grok the "People" menu....) Having hierarchical dropdown menus was incredibly helpful, especially since they included the tabbed pages that weren't immediately obvious to me on some of the admin pages.

davyvdb’s picture

I think the toolbar will meet a lot of people's needs. Let's keep it this way for Drupal 7 and re-evaluate for Drupal 8. I've never been a big fan of Administration Menu. It also send the complete administration menu on each request. Not my kind of thing performance wise.

kaakuu’s picture

Admin_menu actually meets a lot of people's need. Its not what I or you may think but a fact.
If there is scope for re-evaluation let us do it know, why the insane hurry to get things out of the door.
Each request in Drupal sends a huge loadful of things whether you see it in browser or not so that is lame imho in this case. Admins do need to see any part of the admin from their control page while they are adminning the site. This makes the task easy and avoid repeated pageloads and clicks. This is much better performance also.

What is easier ? I want to add content from a slection of 5 or 6 content types. I click add content, then wait for the page to load that gives a list of content type and may need to scroll. Then click on what I want. OR just click from a easy drop down "Add Blog" and directly go the blog submission form ?

The Admin_Menu let us do the second.

sun’s picture

Let me just quickly spit in that Davy's point about performance is not true. Administration menu always cared for maximum performance, and 3.x even goes beyond might and magic by being displayed on all pages without actually processing nor outputting anything at all to display it. You will say that this is impossible, but then again, you will have to learn it is indeed possible.

mattyoung’s picture

-1 for admin_menu. Don't like how it drops down its gigantic menu as soon as you mouse over it. It should at least have hover intent to keep it from being over sensitive.

kaakuu’s picture

@mattyoung - But it at least goes away on mouse out ! And is very slim and trim. On the other hand the admin bar now in core, along with browser chrome, sits and sits there obtrusively occupying nearly half of the screen :)

sun’s picture

WorldFallz’s picture

I just have to chime in to all the naysayers here that the usage statistics say different-- admin_menu is 6th on the list of most installed projects. Sixth! Moreover, all the projects above it have been included in core or are discussing/working toward core inclusion. It's also consistently in the 'top rated' and 'top downloaded' categories at Sorry, but if we're going by the 80/20 rule here a handful of naysayers would be clearly in the '20' category. I'm quite confident that in this case the '80' will be disabling the core toolbar module and installing admin_menu but time, and usage statistics, will tell.

Yes I know these numbers are not absolute, but they can sure be used as a rough gauge. I have no clue of the details of the "not for novices" pronouncement (including the when, where, how, and who said it) so this is completely nonpartisan gut reaction on my part, but had it not been for some 'expert' pronouncement or the d7ux project, one has to wonder if this would even need to be a discussion.

And on a completely different tack, with all the important work to be done on core drupal, it seems really quite the waste of time to reinvent the wheel when an enormously successful tried and true contrib project, which has already worked out many of the same issues, is just waiting in the wings. It really leaves me head scratching.

Of course I don't yet contribute to core to this is all a big 'imo'-- take it or leave it.

kiamlaluno’s picture

I used Administration menu, and I removed it only recently because a problem that is not caused by the module.
I found it very useful; the fact the menu shows every time I hover the mouse has not stopped me from using the module.

I was wondering (not having looked at the code of Toolbar, and not knowing how its code differs from Administration menu) if it would be possible to integrate Administration menu with Toolbar. What I mean is that Administration menu could alter the output of Toolbar; in this way, the user would enable Toolbar, and Administration menu if he needs more functionalities.

I don't know if this is possible, or it makes sense; it's just a thought I had.

Michelle’s picture

I didn't realize this issue had been re-activated until WorldFallz pointed over here. I want to add my support for admin menu. I realize that getting it into D7 core at this point is pretty well impossible but add me to the list of folks who will be adding it from contrib to every site I make.

You have a wonderful module, Sun. Don't let the usability folks tell you any different.


mcrittenden’s picture

+1 for what Michelle said. Enabling admin_menu (and now, disabling toolbar) will still be step number one in development for me.

That said, I'm not at all concerned that it didn't make it into core as I know it will progress a lot faster (read: at all) here as opposed to sitting stagnant in core. Admin menu has always been one of those modules that I'm excited to see what the next version brings, and as you said, it's always a little ahead of its time. Being introduced to core would ruin that, IMHO.

EDIT: Is there an issue somewhere where the discussion and decision to not add it to core took place? I'd like to read over the arguments.

leisareichelt’s picture

i've been reading the conversation here and wanted to add some perspective from the D7UX project point of view.
Mark & I acknowledge and agree that the admin_menu module has made a significant improvement to the Drupal UI for many people and that is why it is such a popular and routinely installed module. We fully expect that it will continue to be incredibly popular, particularly with Drupal developers.

At the same time, flyout menus represent both usability and accessibility issues for many users, particularly the users we are seeking to better represent as a part of the D7UX project (ref:

From a usability perspective, there is a significant proportion of the end user population who routinely use only an incredibly small subsection of Drupal's toolset, the admin_menu makes it quite difficult for them to pick out these very few but very important tasks by doing exactly what you more experienced and proficient end users value - providing everything within a single click.

From an accessibility perspective, the flyout menus require a significant amount of physical dexterity in order for end users to perform tasks without error. Again, those of us fortunate enough to be able to wrangle a mouse with accuracy may find the flyouts extremely efficient, but for the very many people who can't (and for us if we happen to sprain our wrist or something similar) it is not a great strategy to make the primary navigation interface something that requires such dexterity.

please don't think that the fact that we have not recommended including admin_menu as a part of D7UX implies that we don't think that it is a great asset to Drupal and, for the intended target audience, well beyond fit for purpose. But within the scope of our project and for the target audience that we are seeking to represent, it is not the ideal approach.

I hope this is helpful

rszrama’s picture

@Leisa - makes perfect sense. : )

Maybe this is too much trouble, but what about Admin Menu w/ various menu profiles that can be assigned to users by role? Drupal allows you to setup input formats and make those available to different roles. The WYSIWYG modules (at least FCKEditor) allow you to setup WYSIWYG profiles that you assign to different roles. What if we had Admin Menu with all its potential available and had usage profiles... for regular ol' users, it could function the same as the Toolbar currently does. For advanced users, it could function the same as Admin Menu currently does.

And I realize this is not exactly a straightforward operation given the way Admin Menu must work with the menu system. Maybe it's not even worth it, but it does seem like it could lead toward a path of 2 dead birds and 1 stone on the ground beside them.

kaakuu’s picture


From a usability perspective, there is a significant proportion of the end user population who routinely use only an incredibly small subsection of Drupal's toolset

Statistics documented in says that the MOST common toolset (for admin jobs) used is Admin_menu. Surely people would have quit by this time if they suffered wrist sprains or mental blocks. And all the people have been using the same sorts of fly out menu LIKE in the Start menu of MS Windows as well as similar menu on numerous websites. What you say is incredible imagination against Admin_menu NOT supported by facts in or in the actual world of computer users.

Its funny to hear that people who are going to be Drupal admins cannot handle mouse as apart from admin menu there are great many areas in admin tasks which are mouse dependant like drag-drop, adjusting Views etc. If you speak about "Accessibility" options no point in discussing as Drupal does not even have a special theme with Accessibility Option or even an option for site users in core to choose such a theme.

And what is the point if your target audience has to immediately or soon after downloading the tar has to disable it and run for the Admin_menu ? This again is not what I think or some 50 test users may think, but some 50000 users, novices included, think and and does every month.

but for the very many people who can't

Admin_menu does not kill the normal menu that was available as a left or right side block in Garland. Those who 'can't' easily could use that. And those who can, could use the easy and full functions of Admin_menu rather than the half baked one. The Admin bar as of now makes difficult contextual sense and makes what can be one click job go through tedious pageloads and extra clicks, that being surely more difficult for novice users.

There has been comments about usabilty expertism above by much learned members of the community above so I refrain from repeating or quoting those :)

sun’s picture

Flyout/dropdown menus represent usability/accessibility issues? Accessibility is taken care of. And the vast majority of the target audience knows exactly this navigation pattern from many, many other CMS, desktop software, web applications, internet portals, etc. If that pattern is not usable, then I must wonder, which other pattern the target audience is more familiar with. Furthermore, the (new) "Toolbar" style for it uses the same large font and spacing as the Toolbar in D7 does. If that leads to accessibility issues, then the Toolbar in D7 has accessibility issues.

I can only recommend reading #16 again. It is not about providing expert tools for advanced users. It is about allowing the user to understand what is under the hood. That is the first and foremost usability issue Drupal has to solve with regard to its navigation.

Drupal is not a naive blogging tool. It's a flexible, modular site building tool. For that sake, the day-to-day tasks are not limited to creating and finding content, but instead, constantly building, extending, and rebuilding a site. Users want to achieve something. They do not want to see the fancy and omg-so-usable buttons on all the time-wasting pages they need to click through.

kaakuu’s picture

Re "Drupal is not a naive blogging tool."

Drupal can actually be that also :) and does very well at that with many users using it that way. For the same purpose Admin_menu shines too well and make those blogging tasks easy. See #18 above and see an installation of buddypress (wordpress mu) - they have similar 'admin' bar with 'fly-outs' .

Whether the user understands what is under the hood fully or not, the Admin_menu makes life easier for them from the word Go.

mcrittenden’s picture

Obviously nothing will come of our discussion here at this point, a few days before code freeze and after hundreds of man hours spent on the D7UX toolbar, and I think we're being a little hard on Leisa, but I can't help but play devil's advocate.

I'd like to point out that the flyout menu functionality in admin_menu is practically the same as the menu system in almost every desktop application (even the browser the user uses to reach their Drupal site to begin with) except admin_menu activates on hover and desktop app menus activate on click (which, if anything, is less accessible IMO). So yes, it may be difficult for users with impaired motor skills or concentration shutters, but not any more difficult than every desktop app.

Also, IMHO it's a valid concern that so many options/menu items might be difficult for the know-nothing client that just wants to add a blog post, but that's a problem that can (and would) be easily solved by implementing something like what was mentioned in #28. Nobody expects to throw a module into core without changing it in some way. Even though that just happened with CCK HEAD, cases like that are definitely the exception.

BUT once again, I'd still prefer it stay in contrib so sun can maintain complete control over it. I just think the reasoning is off.

WorldFallz’s picture

All these opinion powered arguments aside-- sorry, I have to say it again, but the usage statistics, however rough they may be, speak for themselves. If the guiding principal really is 80/20 (which I've seen mentioned over and over and over again in all sorts of posts and issues) and it's not just lip service to justify a particular agenda, we are clearly going against that philosophy here. At the very least, such a decision warrants more than "imo" which is all I've seen to this point.

Also, no one said admin_menu was perfect in it's current state-- I'm sure there are improvements that can be made (like a "favorites" or "quick launch" menu, hoverintent, mega drop-downs, etc.)-- there always are. I just can't help but think how much further along this effort could have been if it started from admin_menu.

I've seen quite a few of the d7ux decisions that could be argued either way but never said anything because I didn't have the cycles to participate and instead chose to defer to the all the hard work that team has done. However, this one just plain eludes me.

kaakuu’s picture

So yes, it may be difficult for users with impaired motor skills or concentration shutters, but not any more difficult than every desktop app.

Then ?

@Mcrittenden, In Windows Start menu, things happen on hover and not on click. To go to finally to a section it is a click both in Windows as well as in Admin_menu.

Doing the right thing is important, more important than calculating how many hours spent on a half baked thing. It takes a moment and an outlook to scrap something in favor of something which is actually massively IN USE and will be MORE helpful to admin users. The Admin_menu is in a ready state and there shouldn't be a problem imho for Sun if other such contribs can have got into core and other such contributors are not having problem. Often the difference between success and failure is a small step and discarding lame excuses :-)

Instead of ego issues, just scrap the admin bar and get Admin_menu into core, please!

mcrittenden’s picture

Then ?

I think we're arguing the same point. We're both saying that there's not much truth to the argument that flyout menus automatically make a menu inaccessible.

Michelle’s picture

just scrap the admin bar and get Admin_menu into core, please!

Freeze is in 5 days. This simply isn't going to happen. But I've been told that the toolbar in core is disable-able. So those of us who want to continue using admin menu can do so.


kaakuu’s picture

Eh? It takes more than 5 days to delete it and add the Admin_menu which is already ready ?
Surely 50,000 to 60,000 users on Drupal org every month and ALL Acquia users all the time get to do it much faster :-)

Thanks for your feedback.

davyvdb’s picture

The toolbar is disable-able indeed. It's just a module providing a "Custom menu". You can add links to it. Kind of like "quick links, favorite links". So admin menu can still grow. We have 2 alternatives now. The toolbar and admin menu. I noticed a lot of colleage Drupal developers install it on their client's sites. The clients like it. They've never haten it. But now we can see what an alternative (well, almost alternative) can do. I stay with my earlier point... Let's see how adminstration menu evolves and start working to get it in 8 asap. And lets see what people think of the toolbar.

Michelle’s picture

@kaakuu: Getting something into core is not trivial. It's not just a simple "mv admin_menu/". Even the smallest patches get tons of scrutiny, fixes, rerolls. Tests need to be made, bikesheds painted. There is simply no way it would happen in 5 days.


kaakuu’s picture


Let's see how administration menu evolves and start working to get it in 8 asap. And lets see what people think of the toolbar.

Admin_menu has developed this far and is used by 50,000 to 60,000 users from D.O p.m. and all Acquia users who get it bundled in the Acuia Drupal. How much more "seeing" is needed? Admin_menu is a toolbar the way it should be and the D7 toolbar is a lame version of it from the user's perspective.

Unless Reinventing Wheels is enjoyed and useful amounts of time decided to be wasted we have already proven, documented and elaborate picture of what the people thinks, and does !

davyvdb’s picture

Guys... You've made your point about the usage base. We all accept that. I was talking about how it will compare next to the simpler toolbar. Will as much people need admin menu? Will toolbar grow to admin menu? A symbiosis?

mcrittenden’s picture

Getting something into core is not trivial

Correct, and that's not counting the time it would take to convince the entire Drupal community that has already committed itself to Toolbar (if that's even possible after all the time spent on Toolbar).

kaakuu’s picture

@Michelle - True! But we are speaking of something which is ready to get into the core, and something which is half done to keep out of core. Look at it from this angle - you will disable admin bar and install Admin_menu ( without bikeshed and all abracadabra) as it is, thus it will be in your day to day core usage.
Nothing is in so stone in software-world that things cannot be done or undone unless some vested or misunderstood intentions are there, imho.

Its NOT the entire Drupal community that has already committed itself to Toolbar - may be a handful of devs and UX guys and a few others. "Entire" is big word, and a different word - it describes MORE appropriately the massive number of users who download and use it and who FORMS the bulk of the Drupal community. They will be happy if its in core, no convincing needed :-)

mcrittenden’s picture

@kaakuu, sorry, by "entire Drupal community that has already committed itself to Toolbar" I meant "The group of Drupal users who ARE committed to Toolbar" not the entire Drupal community as a whole. Should have clarified.

But we are speaking of something which is ready to get into the core

That's not necessarily true. 1.x doesn't fully invest in Drupal's menu system and 3.x isn't ready until a bug in the menu system is fixed (see #550254: Menu links are sometimes not properly re-parented). If a version of admin_menu were to be committed, it would have to be 3.x as it does things more like "the Drupal way" but nobody's going to feel ok committing a module to core that hasn't even made it to full release yet. It would have to be fully tested, abused, code-reviewed, revised, and tests would have to be written against it. As Michelle said, it's just not going to happen.

kaakuu’s picture

I was talking about how it will compare next to the simpler toolbar.

@davy Imho these talks are reinventing wheels. We should then talk about scaled down versions of Views, CCK etc too and start comparing those. Fruitless wastage of time. Things have evolved over years from simpler to more useful tools.

This toolbar is same as the Admin menu in a block with some hither thither changes, and instead of being at left or right sits at the top. Admin menu is supposed to give access (optionally) to all the Admin functions. The D 7 toolbar does not do that.

kaakuu’s picture


Just for arguing -

#Surprising 1 - can there be better test and review than so many users using it successfully ?

#Surprising 2 - you mean Acquia prepacks such so called 'incomplete' stuff without any good reason ?

Thanks. And BTW, the original issue was about THAT only - getting a suitable Admin_menu ready for D 7. I posted more than 3 weeks ago. A good amount of time. I did not see the vociferous voices at that time !
Was time being purchased so that it could be said "now its too late" :-)

Everett Zufelt’s picture

Speaking as a Drupal developer and administrator deeply involved in accessibility issues, and being a blind screen-reader user myself...

1. It is a fundamental misconception of accessibility to think that a site needs an "accessible" theme, any theme designed properly should be accessible to users with disabilities.

2. The toolbar does currently have accessibility problems which need to be resolved, as does tabledrag, there are currently issues filed against both of these in the issue queue, we'd love your help. I have not tested the administration menu, but I imagine it does have accessibility issues as well. I doubt either component has accessibility issues that can't be corrected with community willingness.

3. I am less concerned with those who have sprained wrists, as aweful as that must be, and more concerned about making all parts of Drupal accessible to those of us who live on a persistent daily basis with accessibility challenges.

kiamlaluno’s picture

We should then talk about scaled down versions of Views, CCK etc too

Actually, Drupal 7 contains in core just a part of CCK.

rszrama’s picture

@kaakuu I appreciate your zeal for the issue, and I've already posted in this thread twice in favor of the issue... but really, the nature of your responses here comes across as combative with the very people who agree with you and also have a firm understanding of the feasibility of the task for D7. Continuing to repeat the same facts will alienate the people you should be appealing to to support Admin Menu in contrib and target D8. I'll stop weighing in if you continue to pester people about a D7 inclusion.

That said, there's good precedent in the Token module for essential modules being bypassed in one release and included in the next. I'm very happy it made it into D7. I'm sure it didn't hurt for it to be able to mature another year in contrib.

kaakuu’s picture


A part but useful one, not halfbaked or altered to incomplete use, I think.
So include a part of the Admin_menu instead of reinventing :-)

Thanks. My last post if all these negativity and round-and-round talk goes on. Will like to join again if something positive and tuned to the NEEDS of actual, large, real users happen.

@Everett Zufelt - Opera has special accessibilty themes. Like one with larger, contrasted fonts as default. Windows has too. Think Captcha - however well designed it may be it has audio version too. Thanks for your input.

@rszrama - Point taken. Your advice accepted.

mcrittenden’s picture

Actually, Drupal 7 contains in core just a part of CCK.

Nope, now that #516138: Move CCK HEAD in core is committed, it's got the whole thing :)

@kaakuu: Even 3 weeks wouldn't have been enough time to convince people to undo toolbar, which we've spent months working on, and still have time to get a new module in core. Even 3 months would be pushing it.

@Everett Zufelt: I was wondering how you kept pulling out those much needed accessibility reviews on core patches recently :-) ...really glad to have your help here.

espirates’s picture

The Admin theme being developed for D7 is off the chain, very nice, now in it's own module "Admin" module. It's much better than the Admin Menu, which is why I no longer use the Admin menu. The only thing I'd like to see in the Admin theme is menus like "run cron, current module project pages, clear cache,etc" Admin menu has this.

i say no to adding Admin menu in core and yes to Admin module which I think is already planned for D7 core.

mcrittenden’s picture

@espirates I think the main thing that people miss from admin_menu that Toolbar doesn't have is the ability to jump to ANY page in the backend with a single click (along with the clear cache, run cron, etc. that you mentioned). As long as Toolbar doesn't have that ability, I'll be sticking with admin_menu.

snowmountain’s picture

@leisareichelt - Thanks for explaining the rationale!

And, definitely, this much is true. "...there is a significant proportion of the end user population who routinely use only an incredibly small subsection of Drupal's toolset,..."

However, in my opinion, the admin menu makes things easier for these folks!

Here's why I think so:

- Without the admin menu, novices who click a menu may still not see what they want, and have to resort to "poking around" with various menus until the items they want show up.

- With the admin menu, because items are not as "hidden", there is less "poking around" and it is therefore easier for the novice to find what they are looking for.

So, seems to me the admin menu still makes things easier for novices.

Thanks for considering this.

espirates’s picture

Point well taken, however, it's been my experience as a novice user and also as a more experienced one that making users (especially beginners) go through all the menus helps them to understand Drupal a whole lot better. There are menus in there that may go unnoticed if they click too quickly. I think a nice option for Admin Theme would be to customize the submenu so we can add what we want there.

The Admin Theme gives a wonderful setup/view to move through various sections with ease. I like the fact that on my way to a particular menu, I can see the whole set and often I change my mind and want to go to another area, this is easy in the Admin Theme. The only things I miss about Admin_Menu are the run cron, clear cache and link to project issues which is very convenient and Admin_Theme plays nicer with the custom theme too.

Each module has positives, but I think combing Admin_Menu best features into Admin_Theme would be win win for everyone.

mcrittenden’s picture

I think combing Admin_Menu best features into Admin_Theme would be win win for everyone

IMO, that best feature *is* the fact that you can get anywhere with a single click, which they obviously can't achieve in Toolbar without using Flyouts of some sort, and the Usability folks have already said that's not going to happen.

EvanDonovan’s picture

I agree with Leisa on this one. The Admin Menu module may be helpful when you have a small number of modules installed, but for me it's been virtually unusable on complex installations where you have 60+ modules installed. The Admin toolbar/theme is simpler since it only includes links for the most common tasks, and each task is associated with an icon. And if there are tasks that you want to add to it, you can, since it's just a regular Drupal menu. (At least in the D6 version; I haven't tried it in D7 yet.) I only wish that it had links to clear cache, rebuild themes, etc.

Anyway, there's no chance that including Admin Menu will happen for D7. I think it's great that Admin Menu is out there for the users who benefit from it, and free to follow its own development in contrib. Should we set this one back to "won't fix"?

EvanDonovan’s picture

After reviewing the D7 version of the Admin Toolbar in its current state, I have to retract my previous comment about its usability. It bears very little relationship to the Admin module for D6, which is quite useful.

The Admin module for D6 was configurable through the Menu module interface, and it had a wide range of tasks on it by default. You could click on the main heading and the shortcuts would appear underneath, each associated with an icon.

By contrast, the "shortcuts" for Admin Toolbar for D7 can be configured through the Menu module interface, but there are only three of them by default, and there's not a list of the other administrative tasks which one can then choose to enable. Even more frustratingly, the JS from Admin module for D6 which changed the shortcuts depending on what top-level option you clicked is missing. This render the shortcuts useless in my mind, and prevents this module from actually being useful to navigate the Drupal admin information architecture.

I just wish that the version of the Admin module that's going into Drupal 7 had been close to what was created as a Drupal 6 module. That version has been widely used "in the wild", and I've personally seen how it helps non-techies use Drupal. Are there any changes that can still be made to the D7 Admin module post-code-freeze to make it hew closer to the way the D6 Admin module works?

sun’s picture

Status:Active» Closed (won't fix)
donquixote’s picture

BUT once again, I'd still prefer it stay in contrib so sun can maintain complete control over it. I just think the reasoning is off.

Core is dead.
Keep this thing in contrib, and I'm sure we will see a lot of nice improvements over time, more than we would see if it was in core.

I think the real issue is that we don't want to spend time enabling enabling a bunch of default modules for each new Drupal install.

The solution is: install profiles, "distributions", or other ways to quickly download and enable a lot of modules. For myself I use a "module enabler" module. The only thing it does is have a huge list of "dependencies[]" declarations in the info file, which I generate from counting enabled modules in the system tables in other Drupal installs I have. I guess others have their own methods.

For new users, I think we should have "featured distributions" on the download page.


About usability.
I think for anyone who wants to install and administer a Drupal site, the admin menu is far superior to any other tool imaginable. Most importantly, it provides an overview of all that is possible with the currently installed modules.
However, we need better tools for the usual "content editor" - that is, the client who wants to write blog articles etc. If the D7 toolbar does that, I dunno - I only had a short glimpse.