Config and modules page

Just wondering: should we call this "Configuration and modules" instead of "Config and modules"? Config has a sloppy feel to it -- and it is not really translatable?

I think it's ok to keep 'config' in path, or otherwise we can argue about 'admin' too :)

Awesome job. The purist in me, prefers 'configuration' but I'm willing to settle on 'config' if that is what the majority likes best.

To me, this looks RTBC. Happy to debate the URL path later.

Can someone please be so kind to explain why we have to introduce a completely new admin/config, while the screenshot and everything else looks like a slightly modified version of what we have in admin/settings already?

"Configuration" and "Settings" are, technically, synonyms. I find it totally weird to see admin/config and admin/settings. Which one is what?

That's like having admin/build/menu to administer menus and a hypothetical admin/build/navigation to administer your site's navigation. Huh?

we're going to be replacing admin/settings/foo with admin/config/category/foo in most cases.

Is that the plan? Just because the menu link wants a new title and admin/settings wants some further categorization, we want to rewrite all paths in core and throughout contrib? That, I don't understand.

I held the same position as sun, but catch and Bojhan helped explain things to me.

Currently, admin/settings looks like this:

We want it to look a lot more like this, minus the stuff that's moved under other items (Content, Appearance, etc.):

So admin/settings/foo will no longer be sufficient. It has to be admin/settings/content/foo or admin/settings/reports/foo. And since we have to break the links anyway, we might as well rename "settings" to "config" so that it matches the name of the top-level item.

If all this sounds like a big WTF to you, watch yoroy's video at http://www.yoroy.com/2009/reorganize-drupal-admin-items-within-d7ux-fram.... That helped me "get it" and I think this is a really good change.

I don't have time to review this atm though, sorry.

I reviewed it and it looks good -- and it is an incremental but important step towards implementing the mockups created by the usability team. I can commit this later today or during the weekend.

I'm happy to stick with 'settings', but I don't mind moving to 'config'.

so, I agree that Configuration is better than Config (esp for translation purposes).
it is long, but a long, descriptive navigation title with good information scent is better than shortening it and removing descriptiveness/scent.

Two key reasons we chose Configuration over settings are:
- it sounds more complicated than settings, which in this case is a good thing. it sets expectations for what kind of things are contained within
- is more scalable than 'settings' as noted in earlier posts.

Leisa's comment in #15 convinced me that we should move to 'Configuration'. Makes sense.

So looking at this, its starting to look good. I spend some time today, figuring out how the current contents map to the new IA and I am not totally comfortable yet. I mapped about 40 modules to the new IA, with catch

http://spreadsheets.google.com/pub?key=r3NqKYK4UMfelsw-YQsKxdA&single=tr...

They are not totally there yet, but its a start. I hope we can iterate more on this, as we grow towards a release date.

As webchick said, it's a categorized big'o'list of crap - which is still only attacking half of Jerome's problem. So on the premise that, the reason for this getting in is to start doing some usability testing on this to see whether it fails or not. Then I'd say RTBC it.

oops.

Can we just name it configuration? What does Modules add? Does that just refer to admin/build/modules features? Isn't choosing your modules hih level configuration of your site?

@moshe: I forget where this was stated (somewhere on D7UX.org I think), but basically users know to look for "modules" as the thing that adds features to their site. It's a keyword they'll be scanning for.

I.. didn't mean to do that!

I really like this issue a lot... I think it's going to be an important change!

Perhaps I'm missing something, but is there any reason the attached patch wouldn't be a better way to do this? This avoids breaking any URLs, and seems like it might get us much closer to the end goal, at least as I understand it (see the attached screenshot, and notice the new top-level items under the Management menu).

Obviously, this would need some work since a property named 'plid' was presumably never intended to be a public-facing API :) But that is not hard to fix if this is deemed a good approach.

+    'title' => 'Configuration and modules',

Rename to "Configuration" only.

   // Themes.
   $items['admin/build/themes'] = array(
@@ -538,6 +540,8 @@ function system_menu() {
     'page callback' => 'drupal_get_form',
     'page arguments' => array('system_themes_form'),
     'access arguments' => array('administer site configuration'),
+    'menu_name' => 'management',
+    'plid' => 0,
   );

This item does not belong in the top-level items.

Anyway. Since HEAD was turned into a testing ground for all kind of half-baked functionality without any clear and concrete concept, I resign.

-1 on removing that test. We need to fix the logic of that access function instead. admin_menu suffers from the code in that access function, too -- I had to explicitly define 'menu_name' => 'management' recursively for *all* items below admin* to work around this bug.

I prefer catch's approach so let's go with that. As discussed on IRC, ?q=admin should become the dashboard indeed.

@catch, thanks for working more on this. I'm away for the holiday weekend so don't have time to really look into this right now, but I agree with @sun -- please let's not commit a major change like this until we've figured out the right way to architect it.

Regarding using ?q=admin for the dashboard, I don't see why that would be incompatible with the approach I suggested? The only reason I didn't do that in the patch was that we currently don't have a dashboard to put there. Wouldn't it be as simple as just changing the URL for the "Configuration" menu item and then fixing up its callback a bit?

Second, this does indeed break the toolbar module, which seems like a perfect argument for why it didn't make any sense to pour tons of effort into that patch before anyone knew what the reorganized menu system would look like - it could very well be that we wind up rolling back some code from that patch that never would have needed to be written in the first place, but such is life, I guess :) @catch, can you explain why you think this would require compounding the hacks in the toolbar module? I have not looked that deeply into it, but it seems to me like the toolbar module currently does some hacks where it looks into the management menu trying to find things two levels deep that it thinks it might be looking for. With my approach, wouldn't it simply say "display all items at the top level of the management menu"? This doesn't sound like a hack since it's exactly what the management menu does now :) The "add new content" link is an exception but we already have an issue at #408160: Normal users should not see the create content link appear by default in a menu called "Management" to figure out where to properly move that.

Third, I am realizing we do not need to expose 'plid' at all - it is not plid itself that module authors need the freedom to modify, but rather just the ability to say "by default I prefer my menu item to be at the top level of the management menu" (a.k.a., setting plid to 0). So we could do that with a different hook_menu key.

To not bikeshed this, fairly technical issue - I created an issue at http://drupal.org/node/510110#comment-1775066.

1. admin/config/
   

   Theres about 400 instances of this URL being changed throughout core in the patch at #32. Why not move this url to a core variable? It would be easier to maintain and change in the future.

2. +      // The weight is offset so it is always positive, with a uniform 5-digits.
   +      $blocks[(50000 + $item['weight']) . ' ' . $item['title'] . ' ' . $item['mlid']] = $block;
   

   This comment and the code it is referencing was difficult to understand. Is there a reason or benefit to making the weight positive and 5-digits? Why not 10 digits?

   To make it clearer, you might change the comment to "The weight is offset so it is always positive and guaranteed to be 5-digits."

That's all I could find after reading through the entire patch and checking spelling and code syntax. The bot and Dries are happy. Reviewed and Tested by the Community?

Josh

The weighting comment seems clear enough to me, and I don't think changing 'admin/config' to a variable/constant is necessary (we already have about 5 zillion layers of abstraction in menu/aliases, we don't need one more - and search/replace is pretty reliable, all things considered, when we make further switches).

I think this is RTBC.

Some additional comments:

1. I'm not sure how this patch can be marked RTBC without considering @catch's point in #26 regarding contrib modules? Whatever happens in this issue won't help Drupal's usability much if contrib modules don't actually follow the implementation.

Even for a simple module, based on the discussion at #510110: IA : Configuration & Module we are looking at asking them to move from a current location like http://example.com/admin/settings/modulename/... to something like http://example.com/admin/config/somecategory/modulename/... which is getting to be a long URL. As @catch said, if they don't do this right, they wind up polluting a page somewhere, or possibly polluting the admin toolbar itself.

For a larger module, let's look at an example: Messaging and Notifications. Currently they put things under http://example.com/admin/messaging/.... These pages contain a large chunk of functionality, and the URL has a simple semantic meaning. Presumably under the new plan, we'd ask them to move to http://example.com/admin/config/messaging/... or possibly even http://example.com/admin/config/somecategory/messaging/..., but they may not want to do this if the module's tasks are not all "configuration" related. If they don't bother changing their URLs, messaging functionality would wind up right on the admin toolbar, stuffed next to everything else.

Any thoughts on what module authors would do with this? I am not sure, but the intention of my patch was that modules would not have to deal with the above issues nearly as much. In the event that they don't make any changes to their URLs at all, everything would still basically make sense. And they could put themselves in the top level of the admin toolbar if they really had a good reason to, but they'd have to opt-in to do so rather than opt-out.

2. I am wondering if someone could elaborate on why http://example.com/admin is considered a good location for the dashboard? Naively, I would think http://example.com/dashboard is much better, because it is more generic. Consider drupal.org, where the majority of users fall into the "content creator" category, but very few are site administrators. There are dashboard-like features that would be useful to many of these people, but it doesn't make a whole of sense to send these types of users to an administrative page. (Heck, as a member of the security team I technically have some admin-level privileges on drupal.org, but I still don't think of myself as an "administrator" at all, and visiting http://drupal.org/admin would feel pretty weird to me.) Putting a dashboard at /admin seems like it would limit its usefulness.

3. Reading #510110: IA : Configuration & Module and looking at more screenshots, I am starting to wonder if perhaps neither of the implementation approaches we have discussed in this issue so far is actually the right one? Clearly it's a good idea to add some of the most useful links to the top level, but both current approaches involve moving links rather than copying them, and maybe that's not so good because it means there is no longer any single administration page you can go to when your intention is to find something whose location you don't actually know. For example, looking at this screenshot (originally posted above), while it's nice to have the "Users" link in the Management block in the sidebar (or in the admin toolbar if that were enabled), it is perhaps not so nice that we would no longer have this link in the "User management" section on the main part of the page. When I get to the point where I'm looking at that section, a link to the Users page is almost certainly something I want to see, no? Perhaps we should be careful about totally getting rid of the current /admin page, since although it is not ultra-usable, there is some real value in having a single encyclopedic page that you can go to when you know you want to administer something but don't know exactly what that is yet or where you would find it.

4.

@David - "The "add new content" link is an exception" - yes, that's what I ran into, to restrict the header to that, you need to do check for 'admin' in the link_path, then suddenly you can't move node/add there even if you want to. With the current patch, the admin header, at least, respects the actual structure of the management menu and lets you use normal mechanisms to move things aroud.

OK, so given that the "add new content" link is the only problem, I'd suggest simply ignoring it for now. It causes hacks either way, and based on the issue in which it was committed as well as #408160: Normal users should not see the create content link appear by default in a menu called "Management" it seems overwhelmingly likely that the Management menu is not its final home. If we imagine that it is removed, then either way the toolbar would be able to simply mirror the management menu without requiring any hacks (which would also have the benefit of making it easier for a site administrator to figure out how to add something to the toolbar by hand).

5.

As to changing the callback for /admin then putting config somewhere else - no thanks. If my path is admin/config/somecategory/foo - I want to be able to go back up to somecategory and config. If I hit the dashboard at admin that's fine - configuration is a top level link in the header bar, but having admin/someotherpath as the config page with no relation to the URLs breaks what's currently a very consistent system.

Agreed that this would be a weakness. (Although only for people who mentally navigate by URL; breadcrumbs and everything else would work fine either way.)

See also #513028: Trivialize system_main_admin_page()

@David:

1. Contrib modules were considered in great detail at both the D7UX sprint in Utrecht and in issues like #510110: IA : Configuration & Module and you can see results summarized in the first follow up on that issue. We cannot put our head in the sand and try and hack a new IA look around the current path structures, thinking that contrib modules will kinds-sorta not break, or as you said that "everything would still basically make sense". The idea is to get contrib authors categorize their pages under the new IA, not to kindly let them break. If changing URLs helps this, then all the better. Your hacks make URLs show completely different structures to what can be experienced on the UI, which is quite confusing. Doing this for having a small patch sounds fun but not right for core IMHO. Doing this so contrib module authors don't need to think about putting themselves into the new IA goes against the goal of rolling this out across the whole Drupal module universe. Yoroy's video is a good resource to understand how modules feeling not fit here are suggested to behave.

2. I don't care about the path of the dashboard and I don't think that has any relation to this issue. It is not related to how the config and modules are organized, it is not added in this issue, etc.

3. I agree some kind of overview screen would be good to keep, but don't agree /admin was a good way anytime to scan for things. /admin/by-module was specifically added for the reason of this, and as I've seen Leisa's feedback on other issues, they did not intend to remove it (but provided no way on the mockups to get that for sure). Again, moving stuff to admin/config does not have anything to do of where they are actually listed or appear.

From #520444-19: Use a custom menu for top level toolbar links:

Defer the cosmetics. Why not this way:

1) Turn /admin into /admin/settings, removing /admin, replacing the default sub-item listing on /admin/settings

2) Directly use the top-level items of the Management menu from menu router for the toolbar.

3) Build the Configuration dashboard on /admin/settings. Also fix the admin menu system nightmare, which is totally dependent on an "admin" menu link that must live in the same menu as the children.

4) Rename /admin/settings to /admin/config.

@sun, this is similar to what I proposed over at #508458: Config and modules page. The main issues are we add an extra level of depth for every admin URL, and we have to move every single contrib module administrative path down that level too (since for that page to work, we don't have admin/config/mymodulesettings we have admin/config/category/mymodulesettings). In fact you made that same point yourself at http://drupal.org/node/508458#comment-1772230

A) This issue's attempt started with renaming/injecting admin/config. Why not defer that? We have admin/settings already and we can move the admin dashboard from /admin to /admin/settings, maintaining a sane IA and underlying menu router path structure.

B) Config or not, we still need the /admin prefix.

C) One further question is whether admin/config/category needs to be a page that is output on its own. If it's not, then we might think about "tagging" approaches. If it is, what's the problem? If absolutely required, we can still increase MENU_MAX_PARTS + 1.

Gábor:

1. Agreed that my patch was a hack :)... notice that I never submitted it with anything but a .txt extension; it was intended to be an idea to be potentially developed rather than an actual core patch. However, I disagree that it is necessarily bad to have a mismatch between URL structure and site menu structure. Drupal has an entire Menu module whose purpose is to allow people to create such a mismatch, no? I don't think it's a problem if it turns out to be a good idea for other reasons.

   Anyway, the main point is that the IA mostly asks contrib modules to live under admin/structure or admin/config, but not all modules provide "structure" or "configuration". The original implementation strategy (renaming URLs) means that any module which decides not to categorize themselves this way would essentially automatically have to appear in the top level of the toolbar. Maybe that is OK - to some extent it is what happens with admin_menu in Drupal 6 - but it could result in a lot of hard choices being made. And this is harder than Drupal 6, which provides more top-level default "admin" categories for modules to choose from. For example, even some core URLs don't seem like they fit very well with this URL pattern. It's not a showstopper, but something to keep in mind.

2. Agreed that the dashboard is off-topic for this issue... I'm not even sure who brought it up originally, except I guess the idea was that if everything gets moved one level deep, something still has to go at /admin. Frankly, though, /admin could just redirect to /user/dashboard if it came down to it, and that would work fine.
3. I think the overview screen is the most important issue here. Really, it is sort of two issues in one.

   The first is a small issue from a design perspective (since it only involves the placement of a couple links), but a big one from an implementation perspective, and that is the example I mentioned above about whether or not, for example, the main "People" page should continue to be linked from the user management section (in addition to appearing in the toolbar). I think it may be important to do this.

   The second is more general, about whether or not some of the bigger items (e.g., Structure) should also be duplicated. Ideally, it would be nice not to. But the main advantage of having everything on one overview page right now is not scannability, but really searchability. Drupal does not have any way to search for something in the administration area, so people resort to using browser-based search. There are some old patches (such as #102254: Add an administrative search feature) that would change this. Perhaps if we can get that feature in, it's OK - but if not, it's a real problem. In order to find some particular feature I'm looking for, I'd have to click through a couple different pages (structure and config, at least) and check on each page in order to find it? It may be true, as you say, that the admin/by-module page could be the right place to go for a comprehensive overview, but that page would need some work to get there (e.g., menu descriptions), and there seem to be all sorts of other plans for it as well.

Proposal: Let's figure out #3 before writing too much more code here :)

Short-term proposal: There is obviously a lot of interest in getting something that can be user-tested. I didn't explicitly mention it above, but that was one of the motivations for the patch I wrote; it's a very small patch and easy to keep up to date, so for example it could be applied to the D7UX repository if you want to. I've attached an updated version for this purpose, which now works with the toolbar and I believe reproduces the desired top-level IA in the toolbar (not the lower sections, obviously, but those are separate issues, and would automatically appear correctly here once e.g. site configuration gets broken up into subcategories). Again, note the .txt extension; this is not intended to be a real core patch :)...... The one good part maybe worth keeping, though, is that it does make the toolbar simply a direct mirror of the top level of the Management menu, as @sun suggested above.

@David:

1. Looks like you are not getting this. The idea in Drupal 6 is that D6 has this IA with Site configuration, Site building, User management, Content management, etc. and those not fitting at all will have their own top level, others fit under these sections. The idea behind the D7 IA is that we have the Content, People, etc. items, and those not fitting under these will go under "Configuration". Again, this is explained well by Yoroy. Have you looked through his video as I've suggested?

2. Righto.

3. There is not gonna be any "user management" section. Once again, the D6 IA is replaced by the D7 IA, it is not like D7 just picks up some items to at the top and then has another IA under. People *is* the high level user management area, and less used things like user settings are in Configuration. There is no "user management" which spans over these.

Again, as said above, I totally agree that there should be an overview page ("site admin map" if you will), but that is just gonna have items at different places as a result of this reorganization. The lack of such a page is an issue, but is not related to whether we put something here or there. An overview is useful either way.

1. Yes, I've looked through the mockups/video/etc and I and get it -- though the video was quite a while ago, so apologies if I'm forgetting something from it :) But it doesn't change my question. The mockups I've seen for Content and People only allow modules to add items there via tabs, which is limited (not bad, but limited). So most modules are looking at Structure and Configuration as the place where they could go. But still, not everything fits in those categories. Example: Suppose I had a "site export" module that was designed to allow me to download a tarball/database of my site. Does it live at admin/config/site-export? It's not really configuration-related. The Messaging and Notifications suite of modules that I mentioned above is another example. Some of the admin pages for those modules certainly involve configuration-type settings, but others are more about subscription/queue management. So currently these modules create their own top-level category. It's not clear to me how that fits into the new IA.

Note that I'm not necessarily suggesting any major changes to the design. Mostly this would be about having different URLs, and also tweaking the on-screen text (which according to mockups such as those above, currently is intended to have something like "Configuration and Modules => Sitewide Configuration" - i.e., very heavy on the "configuration" idea, although I note the "Application Launchpad" part of the mockup could be fleshed out a bit and would probably help here). However, the URL issue potentially totally changes the implementation, which is why it's important to figure out.

2. Alrighty then :)

3. Sure, I was using the current rather than the proposed terminology, but if you replace "User Management" with "People" or "People Settings" my question is the same. So another way to phrase it might be this: How are People and People Settings going to be cross-linked? The fact that the Drupal admin area currently has a section where you can go to get a list of all links that relate to managing your users is one of the things about the current IA that is actually good, in my opinion (and at least based on my limited understanding of previous rounds of user testing, they tend to agree).

Anyway, there's been a lot of discussion of problems here; we need solutions. Here are three possibilities:

1. Replace "admin/config" with something more generic that will be more relevant for 8,000 diverse Drupal contrib modules. The best I could come up with was "admin/manage", but that isn't great, nor does it really match the "Configuration and Modules" title.
2. Make it so that all URLs like "admin/somecategory" show up on the Config/modules page, except those which are specifically pulled out to be on the top level (i.e., no special admin/config URLs at all). That is basically the approach of the patch in #48, although obviously it would need some cleanup. This has the advantage that it Just Works, but there are disadvantages also.
3. Maybe some kind of hybrid approach, where URLs like "admin/config/somecategory" show up on the config/modules page, and URLs like "admin/manage/somecategory" or even "admin/somecategory" show up there also (but maybe on a separate part of the page?).

Looming over this is the issue mentioned above that there might need to be some links which show up on the config/modules page while simultaneously being duplicated in the top level of the toolbar. That is maybe less of a blocker now than it was 48 hours ago, since it seems a lot of other patches were committed in the interim that would potentially need to be refactored as a result of that anyway... it is going to be messy no matter what :) So at this point, we could maybe just push that question to a followup.

@David: re #50, if you think certain modules don't fit into the IA strategy for Drupal 7, technical solutions will not fix that. Whether they exist in the menu via hacks or in the paths which equal their UI placement, they still can only choose from the existing containers or add their own new container as in Drupal 6. The suggestion would be that they don't add a new container. If you think modules don't fit this scheme, then it is a general IA question and is not at all solved by menu hacks.

re #51: I'm not getting (2) at all. How is it an alternative to making "Config and modules" a better home to the modules you say it does not match? Whether we place menu items top and lower by hacks or not, the placement keeps being the same. See above. On (3), again, I'm not getting this. If you think "configuration and modules" is not the right label for this area, how making things appear here too would solve people finding stuff?

Gábor and I spent a while chatting about this earlier today. I think the conclusion we both agreed on is that a "Configuration and modules" page (titled as such) is in theory a good place for a giant variety of modules to go, but that there definitely needs to be some more work done at some point to figure out both how and where the "non-configuration-related" modules can fit on this page.

So if people are very excited about renaming hundreds of URLs to admin/config right now, I'm not going to stand in the way :) I just think we need to make sure to do the followups mentioned above... And since the followups could very well involve renaming the URLs again, I'm not entirely sure it's worth the effort to change them all now before thinking more about it. But I suppose that's up to whoever wants to spend the effort on a patch :)

In the end, it's not about finding the most correct words and descriptions, it's about finding the words that will trigger the right action or response from most people. We will never find a 'correct' label for everything on this page. It's specific purpose is to be a single page for modules to dump their config/setup/whatever links in. Just by keeping this one single dumping ground, people will learn where to look, because if it's not added to one of the top level pages (and I hope most modules will be so modest as to not do that, with the usual suspects as the exceptions) then it must be under Configuration and Modules. Anything that for the purpose of correctness wants to split up the items on this page into more pages makes stuff harder to find because people would have to choose between 2 or more 'semi catch-all terms'. "Don't make me think!".

It seems #52, #52 and #54 gets us back on track. I support the approach catch outlined in the initial post and now hopefully can get back to as per #54. Thank you.

Tested the patch. Note that to test it, you actually need to enable the locale module, since the patch uses that as a guinea pig to introduce the new config path. Although now we have both the "site configuration" and "configuration and modules" containers, it is up to follow up patches to move stuff under "configuration and modules" and categorize properly at the same time. This is how the current config and modules landing page looks. For its design to match the mockups, that would again be another issue. Let's keep this for the IA/path change.

Testbot happy, output looks good, IMHO RTBC.

So, like Gábor says, this patch only enables us to start reorganize the IA for our admin categories.
We'll need follow ups for

- Add modules page as a second tab here and make 'Configuration' (this one) the default tab
- Reorganize admin items on the configuration tab
- Make the visual design match the proposal

RTBC indeed.

I'm willing to give this approach a try, because it allows us to break up the problem in smaller chunks and discuss each of them independently. Committed to CVS HEAD. Let's see how this goes ...

Great, thanks!

Adding tag.

Subscribing.

    'access callback' => array('system_admin_menu_block_access'),

This is wrong and results in a fatal error for pgsql... and sqlite.. access callback is not an array.

here is the fix

accordingly, the parameter isn't needed at all.

third time lucky, needed to remove an access argument. Webchick, go for gold!

Committed. Thanks!

A good example of the problems I described above is currently being provided by #544360: D7UX dashboard module.

The current patch there aims to provide a site-wide administrative dashboard, and therefore (quite reasonably) it tries to use the URL "admin/dashboard"....

However, using that URL and making it a visible menu item would cause the dashboard link to appear in the top level of the toolbar, which is not where it wants to be.

So the only thing that patch can do right now is define admin/dashboard as a MENU_CALLBACK (i.e., no visible menu item at all) and rely on some other mechanism to generate links to the pages it provides ("some other mechanism" meaning the Toolbar module's install function, for now).

I think we will need to continue to discuss this overall issue post code freeze because the current state of affairs still isn't so great.

@catch: The overview screens now in /admin and /admin/by-module are also supposed to go somewhere, so it was easier to use admin/dashboard for now.

@David: In talking with people about the UI (including Mark), it seemed to be logical to maybe even include the Dashboard as a top level item on the toolbar on the left end. It is after all the "admin frontpage", so the "click the leftmost item in the topmost menu to get to your frontpage" metaphor could be applicable.

@catch, that is probaly easily done by making /admin/dashboard the DEFAULT_LOCAL_TASK for /admin instead of /admin/by-task ;)

I'm lowering the priority of this issue from critical to normal, since the various patches were committed a long time ago and this thread has nothing more in it that could be considered critical in any sense of the word.

It seems that this thread was only left open so that the discussion would be easy to find. Can this issue just be closed now?

Months later... and not really happy with the current state of this either - this is still causing some big problems. Relevant followup issues include:

• #596010: Move "Administration" link into Account menu and make Toolbar output first level of 'admin' menu - where I've essentially reposted the patches I had above as an attempt to fix that.
• #759824: "Configuration" IA category has some stuff in it that has nothing to do with configuration