Split Navigation to User and Administration menu

Right now, on a fresh install we only show the

Navigation menu block:
- My account
- Create content
- Administer
- Log out

And the welcome screen with instructions for furhter setup.

So, what should we be adding and or changing here to get users up and running posting content and building his first 'Home | About | Work | Contact' site structure?

Also, see http://drupal.org/node/279333 and http://groups.drupal.org/node/12920 about 'Explaning what the hell a page is', which proposes to enable the book.module by default, drop the existing 'Page' content-type and rename 'Book Page' to 'Page'.

I think we could split out 'admin' into it's own menu - so it maps exactly to /admin

Rename 'navigation' to 'user menu' (or whatever) - this has my account, create content etc. - would make it clearer that 'create content' is a user task, as opposed to an admin task (lots of testing participants looked here first for creating content types etc.).

The other thing to do would be making menus opt-in for the node/add/edit pages - so by default only main/secondary menu are in there, and admin/navigation has to be enabled manually to show up in the select list.

+1 for moving admin tasks to separate menu block.

The menu items under Administer can be seen only with the admin theme, so they are absolutely useless inside Navigation.
The admin tasks are needed on admin theme, and the user tasks are needed on site theme. Only one link is necessary (not the current whole menu structure) to change between the admin interface and the website.

@Catch, I agree on all 3 points presented. What you present seems like a clear usability gain to me, although testing is needed to be sure. For limiting the menu items, I think that setting this is best as part of the default install profile (or if there was a "quickstart") but not the expert profile. "User menu" is more accurate and descriptive than simply "navigation". "Navigation" makes me think the navigation menu is somehow all encompassing, not one of potentially many site menus.

Bojhan: unfortunately there's a few issues which make this a bit tricky to implement. It's easy enough to move the entire admin tree to a new block, but you lose breadcrumbs and other stuff which remain handled by the navigation menu. See #279399: Breadcrumbs are only taken from one menu for more. Fixing those issues is worthwhile in it's own right though, then it'd be easier. For usability testing, if we manage to get this in, then simply moving it will affect every task, so I'm not sure we'd need to test it explicitly or not.

Marking this postponed based on #279399: Breadcrumbs are only taken from one menu.

I like this idea, it would save me from manually doing this on every site (which is usually the first thing I do). If combined with #351249: Finer control over the Parent Menu select box, we could then also set things up out of the box so that the administrative menu items don't show up as available parents when creating story and page nodes. Seeing all those admin items as options confused the heck out of people in the usability testing, so that would be a big win. Has anyone EVER added a story or page to the admin area? I sure haven't, but you have to stumble over all those options every time.

This is actually a really important one…

subscribing

Is this still postponed?

let's break things to make the bugs visible, that will also help the other issue getting fixed..
the next round of usability testing starts within 2 days, so we are already late for that with this change..

adding UBUserTesting2009 tag.

After looking at the snapshots above I'd say the block should be looking more like this:

----
Administration

* Content management
* Site building
* Site configuration
* User management
* Reports
* Help
-----

i.e. loose the superfluous "menu" in the block title, and start with the second level of the admin menu, as the sole "Administer" link is superfluous, too (the block title already tells us that this is "Administration").

Not having a top level item means we'd have no link to the main administration screen itself when people install. You'd have to click into one of them, then use the breadcrumb to get back. So at this point I'd rather the top level link (and a shorter block when not on an admin page).

Removing the 'menu' suffix to the title seems like a good change though, just 'Administration', should be fine.

Block titles do not have to be plain-text. They can be a link. (hint, hint ;)

Edit: patch removes the menu block title if there is only one item in the block.

I am not sure whether this is the right direction. It basically is the opposite of what has emerged in Total Drupal administration revamp.

There is also http://www.drupalusability.org/node/53, which is the very same observation as mine - and the starting consideration for merging "Site building" with "Content management" - which in turn lead to the overall question where one "creates" something and where one "manages" something. Some folks advanced on that in Total Drupal administration revamp, saying that it is confusing if "content" (nodes of a certain type) are created here, and other "site content" is created elsewhere.

sun, I honestly think the discussion of combining site building and content management is not relevant in this discussion. The issue that this patch is attempting to solve is the mass confusion over what the Navigation menu is, and how it is to be used. Users are terribly confused as to how to use this menu, and the mixing of administrative menu items with non administrative items is confusing. The other obvious issue is that the administration menu greatly clutters the parent item select list when adding a new menu item. The overall idea is to take this approach and then combine this with #351249: Finer control over the Parent Menu select box in order to completely remove the administration menu from the select list. This would greatly improve the user experience in adding menus and overall improve several aspects of the menu system.

References

During the usability testing, users were very confused by the wording and description of the navigation menu (http://www.drupalusability.org/node/119). Sure this wording can be re-worked, but the overall understanding of how to use this menu is difficult and is hard to make clear.

The main conceptual issue regarding this menu can be found http://www.drupalusability.org/node/54.

We did test the patch which removes the administration menu from the parent select list and found it quite successful. Many participants had fairly big conceptual issues regarding why the admin menu was available to select as a parent item (http://www.drupalusability.org/node/57), and in order for the patch listed above to work properly, the admin section should be removed from the navigation menu.

On a slightly more critical note, I am not a big fan over how this patch looks out of the box with a block title. The screenshot in #23 without a block title is interesting and definitely better, but I do not know if I am a fan of how things are laid out. I am going to think about some things some more, but I am wondering what others' thoughts are about how this is coming together.

The 'no title if there's only one item' screenshot is definitely better than the single item with a header. I don't think this is at all incompatible with much larger changes (even if it's removing the administration menu as a separate area altogether) - it's a very small patch. It's also more about trying to make the navigation menu less of a WTF than administration as such.

A quick discussion on IRC might made my point clearer: This patch implements and manifests a concept and paradigm we did not (completely) have before.

My issue is that this separation will kill the emerged idea of the Total Drupal Administration revamp thread, because these are two competing concepts - completely separating an administration menu from a user menu - and - questioning the entire separation by moving "Create content" into a structure that could make more sense and would also cover a variety of use-cases where no clear separation between administrators and users exists. In reality, we are facing a variety of user roles and permissions on many Drupal sites.

For me, it boils down to: If we commit this patch, then we will advance on it - just like we do with any other Drupal core improvements. Which means, we will advance on the _separation_ of admin interface and user interface.

The discussion on Total admin revamp raised a very interesting point in that the Navigation menu would make much more sense if the extra "Administer" level would just not exist. Whether that's valid or not is debatable, but it would actually mean that we would just alter the Navigation menu structure, instead of moving some parts of it into a new menu.

That's why these are incompatible directions.

I'm against rushing this patch in. Instead, #382890: Move 'My account, Help & Logout' links to separate menu and place it top right would eliminate some confusing menu items in the Navigation menu, which makes much more sense at this point in time.

As I see issue #382890: Move 'My account, Help & Logout' links to separate menu and place it top right is a duplicate of this one. What is the difference? Both issues deal about splitting the navigation menu to two menus. The placement and which links should be separated is the only difference.. So I don't understand what is wrong with this one.

I'd really like to see this patch go in. I haven't reviewed and tested it, but I wanted to mark it as a Dries' favorite.

Whatever. Not that I spent the last two years with Drupal's administration.

@Pasqualle: The other issue is about moving a few certain links out of the Navigation menu, while this issue wants to implement a user interface concept that conflicts with Drupal's user role and permission system.

ok, checked the 2 patches and the other issue #382890 solution is what I need..

I think this and #382890: Move 'My account, Help & Logout' links to separate menu and place it top right are trying to reach very simliar goals. They are trying to, by default, seperate the links used to administer the site from those used by the users of your site. This breaks down into "New Menu" and "Bucket Menu" where things fall through too.

At this point, I generally prefer this over #382890: Move 'My account, Help & Logout' links to separate menu and place it top right because the way I see it the user facing content is the bucket and the admin is the seperated menu. Also, it mirrors what I've done with some sites to help deal with this issue.

Maybe this ends up having disadvantages we don't like though so I agree we should look at it closely. Closely in how we administer menus in different places, how it affects users, and how it affects module developers that will want links in one place or the other.

I would like to know why some see this issue and #382890: Move 'My account, Help & Logout' links to separate menu and place it top right as the same or something we have to choose between? Sure, they are both part of a bigger push to clean up the navigation menu by re-grouping some items and moving them to their own menu/block.

This particular issue was encountered in all 3 usability tests we had the last year. Managing your Drupal setup is a different thing from creating content. Moving "account | help | logout" to the top right of the screen has become a convention on the web, we should follow that convention.

Anyway. Navigation menu is a mess, these two issues simply want to group some related stuff into it's own menu. I hope to see both committed and test this it on live humans! :-)

Some feedback. See annotated screenshots.

How about (1) removing the administer links from the navigation block and (2) adding admin_menu to core instead?

#402058: Requirements for Administration menu in Drupal core

I'm in favor to moving admin_menu to core but think that it will need to be re-worked as it gives too many menu options. It would also bring up new sets of issues such as what to do when admin menu isn't present (where does log-out go?). Perhaps splitting the navigation menu could be a first step in this direction?

I like Dries' navigation-2.jpg layout but it is missing help and the ordering isn't right. How about this along the top:

Create Content | Administer (... blank space, the rest justified right ...) My Account | Help | Log Out

This layout would assume that Create Content and Administer could both be clicked but also could optionally reveal additional JS drop-downs. I've attached an example of this interface from Wordpress.

Admin_menu at this point mainly takes the existing core structure (including items in local tasks/tabs, which is nice) and presents them in a different ui-pattern that is compact and lets you drill down the hierarchy without clicking through each level. I think these points are it's main attraction over what core gives us.

But adding admin_menu to core is in itself not a solution to the actual problem. It's the regrouping of all admin items into more meaningful sections we should focus on first.

I'd rather see us continue work on regrouping our admin functions to better support the mental models of users (editors, admins) *first* before deciding on a ui-pattern for it.

I like admin_menu a lot, but at this point it's not an answer to the actual questions at hand (yet? :-)

Now this issue gets hypothetical. If admin_menu was moved into Drupal core, then there would be no need for displaying any sub-links below the "Administer" item in the Navigation menu at all. Administration menu would be enabled by default and visible for users who have access to at least one "administrative" menu item - which accounts for different user roles and permissions, and includes site builders, site moderators, and site administrators. I do not know of any Drupal site that has admin_menu installed and still has the "Administer" item in the Navigation menu - the entire sub-menu tree is hidden instead, because it is cruft you no longer need.

The entire admin_menu topic is out of scope for this issue though.

Managing your Drupal setup is a different thing from creating content.

The words "managing" and "creating" are very appealing here. :)

I admittedly do not have a master plan, but I believe this statement is wrong for several reasons.

- First of all, what is "content" and what is not? Do we still think that only nodes are "content"? With the new fields in core, a variety of system objects can have fields (content!) attached to them, not only nodes.

- Different use-cases of Drupal have different audiences and those audiences have a different understanding of "content". Lisa Reichelt blogged about potential audiences in Drupal. As a user in a "site builder" role with corresponding permissions I would assume that everything I can create in my Drupal site and display somewhere is "content". Whether that is a node, a block, a view as page, a view as a block, a panel page, a forum, or even a user profile page. So thinking that "content" is only a node and all users can only create nodes is a community-centric thinking, i.e. a concept that is limited to a very certain use-case and user role.

- What all different audiences have in common is that they may be able to Create, Manage, Maintain, and Configure stuff in Drupal.

I am entirely questioning our current thinking of content as well as separation between users and administrators. Mainly, because it does not account for the "site builder" audience at all.

Per discussion w/ webchick and Bojan in IRC (which is a follow-on to discussion w/ catch and JohnAlbin) this is what I'm working on:

The links currently in "Navigation" would be split among 3 menus: "User", "Navigation", and "Do stuff"

(note "Do stuff" is a code name for some TBD real name that reflects the verby nature of the contained links).

the "User" menu would be the default source for the secondary links and would contain by default likes like "My account" and "logout"
the "Do stuff" menu would have "Create content", "Administer" (?q=admin) and everything under it, and anything similar.
the "Navigation" menu would have what remains from the current Navigation menu.

A pre-requisite for this being sensible is that we have to properly handle finding the active trail (i.e. for building the breadcrumb) - this means defining a default list of menus and an ordering - possibly this should just live in a variable and NOT be exposed in the UI by core.

Needs work still, but some parts are working (e.g. see code for having a list of active menus).

Please don't add admin_menu to core. I've tried to get used to it many times (as it seems to be what everyone else uses) but I prefer simplemenu. Best not to add either to core so the developer can choose which is best for each particular site.

I always split my menus up in the install profile. I create an Admin menu and move the "Administer" and "Create content" menu trees to it (on my sites users don't add much content so I embed node forms in cases where they do). I set simplemenu to use Admin menu, turn on the devel links and sometimes add a logout item. This structure isn't possible with admin_menu as far as I have seen.

The structure of our simplemenu: "Create content | Store administration | Administer | Logout" seems to be quite intuitive for our admin users.

http://groups.drupal.org/node/20138 for overall admin menu discussion and keep this issue on track please, thanks!

more progress. Anyone want to propose a real name for "Do stuff"?

How about:

"configuration..."
"toolbox"
"toolkit"
"administrative links"
"my admin"
"build & maintain"

screen shot

In response to yoroy's comment above, there's actually a split discussion going on at g.d.o:

http://groups.drupal.org/node/19171 - Sun's post on restructuring the menu. It's long but has a lot of good ideas directly ties to this issue, if I understand correctly.

http://groups.drupal.org/node/20138 - Discussion on alternative menu interfaces / utilities. The first discussion was being derailed by utility discussion, so I moved it over here.

I think the current proposal is good - and it seems to conflict much less with sun's complete restructuring at http://groups.drupal.org/node/19171#comment-66151 than simply moving administration out by itself.

I too like the direction this patch is going. There's a handful of followups which would be nice to see (rename menu title from administration, ditch the /admin level of the menu, etc.), but I'm not sure it's reasonable to expect those things within this patch, and I think this is a good first step towards achieving those goals.

re #45: As the user specific stuff is in its own menu with this patch, so "navigation" menu should probably be titled "Navigation" or something similar. The username as headline for that menu seems confusing to me. There might be personalized items in this menu, but on many sites there won't be.

I'm really liking the user links in #45. This makes a lot more sense and opens doors to further changes down the road. "Do stuff" is all admin except for create content and help. Would it make sense to move these two links out as well?

@yoroy - I'll cross post some of my admin_menu points in groups.drupal.org. I'll try to keep admin_menu outside of this conversation from here on out.

@psynaptic - I don't think that people are suggesting moving admin_menu into core as is. I'd assume that something like it or simplemenu would be added after review and feedback. Perhaps this is an area where Mark Boulton will explore in his work.

Installed both default and minimal profiles. Screen shots highlight some patch features. Revised some help text and per IRC discussion renamed "Do stuff" to "Administration" as a short-term name likely to be removed in further re-organization.

forgot screen shots

Looks like the navigation menu needs updating - could probably just say 'menu items provided by modules are added to this menu by default' - and get rid of the hidden stuff.

Screenshots look great otherwise, not looked at the patch yet.

Looks like this change breaks some tests that make assumptions about the UI - will try to fix those up this morning.

add1sun tells me that a substantial re-write of the blog test it at: http://drupal.org/node/299050#comment-1252602

So, I just removed the one assertion that fails for now, since it is a redundant checks for breadcrumb text. All other tests fixed.

With some minor text changes and a little DBTNG cleanup-up per IRC review by catch.

Bojhan wanted to see a scree shot of the menu selector. See attached. Note that I use the minimal profile, so the main menu is empty.

Bojhan's new issue for adding menu weights (may be a dup): http://drupal.org/node/405142

We are running in circles.

"Create content" cannot live in this new "Administration" menu, because the menu would be displayed for regular users who do not have administrative permissions, but are allowed to create content. Which brings us back to #27 and #38.

@sun - suggest another name then.

This menu would be displayed for any user with the ability to create content. The name "Administration" is a place-holder for later re-organization, and plenty of people seem to think that content creation is an "administrative" task (I disagree). It really doesn't matter much what we call it for now - hence my original suggestion of "Do stuff".

Revised patch per long discussion with webchick, yoroy, beerdb, Bojhan, and others.

RIP 'Navigation' menu. Default menu is now 'Module links' which block is not enabled by any profile. We add user links to themes in addition to primary and secondary links. The 'My account' link now shows the user name instead.

Note also fixes use of 'menu_name' in hook menu - ~3 lines of change should be backported to D6

Well, a couple bugs in the last patch, and webchick decided to revert 'Module links' to "Navigation" and leave it as a default enabled block. Trying again w/ screenshots too.

The screenshots in #63 looks good to me -- 'Management' sound a bit odd still. 'Manage' (or 'Build') sound somewhat nicer, but that would probably require us to rename 'Navigation' to 'Navigate' (or 'Browse'). One could argue that those names are more action oriented, which is usually a good thing, but might not be a good thing in this case ... :-) Either way, it is a big improvement over what we have now, and I'm OK to refine the details later. I've yet to review the patch though.

Awesome patch. I played around with a bit, although didn't do a deep code review. Some issues:

• I sort of understand why the patch evolved from (1) having the user menu as the source for the secondary links, into (2) having its own special region in the theme, but in some ways this makes things worse for the site administrator. What happens if I decide that I don't want the user links to appear on the top right of my site? Instead of just unassigning the whole menu, it seems like I have to manually move each menu item to a different location. I know Drupal pretty well, and it still took me a little while to figure that out :) It seems like there's a need for a new "tertiary links" (not a good name) section that menus can be assigned and unassigned to...?
• If you put items in all three of these 'top right' regions (Main Links, Secondary Links, and the new User Links), the theming is all messed up. Really messed up :)
• With this patch, Drupal now ships with 5 menus instead of 3 (though only 3 of them are mentioned in the #description of the "Menu" item - minor bug). I think having 5 makes the list at 'admin/build/menu' a bit overwhelming. Not sure how to deal with that. Theoretically, "Main menu" and "Secondary menu" are superfluous and could be killed, but that's probably a separate issue...
• What was the rationale for replacing "My account" with the username? When you click on "My account", it's pretty clear where you're going. When you click on an out-of-context username, it's not clear at all where you're going - especially with a bunch of contrib modules that might use the username to link to various other kinds of things in other places on the site. Personally I would leave it at "My account" but do something like this on the theme level:
  

  UserName: <a href="...">My account</a> <a href="...">Log out</a>
  

  or maybe

  Logged in as UserName: <a href="...">My account</a> <a href="...">Log out</a>
  

  Although there might be some challenges in getting that to work correctly.

• The difficulty in coming up with a name for "Management" is directly related to the fact that there will never be agreement over whether content creation is an 'administrative' or 'end user' task (it's both, of course, and varies by site). The default configuration of Drupal doesn't have to solve this problem, but it should at least provide some hint of the power Drupal gives to end users. The approach used in D6 and earlier (putting "Create content" right under the username in the navigation menu) at least accomplishes that, even if it's awkward for other reasons. But moving the default location for content creation to a menu called "Adminstration" or "Management" or even "Build" seems like it would hide that functionality and be a step backwards -- anonymous users, for example, do not generally visit a site expecting to "administer", "manage" or "build" it, so they will only be confused by this patch.

  As a partial solution that might be achievable by the current patch, here is a crazy idea - why not pull the invididual "create [type]" links out into their own menu, like so:

  BROWSE
  * Recent posts
  * whatever other menu item goes here
  
  CREATE
  * Article
  * Story
  
  MANAGE
  * Content creation
  > Administer
  

  'Content creation' would point to the current "node/add" ('Create content') page that shows a list of content types to add, since that page really is aimed more at administrators and thus is a bit more of a "manage" task (by default it could get a stronger permission too). However, the menu item itself would no longer have any children. I checked the code and it seems like this would be pretty trivial to add to the current patch, if it makes sense to do so.

Just for fun, I did a rough implementation of my last bullet point above - it did indeed only involve changing a few lines in the patch. The revised patch and a screenshot are attached.

Clearly there's room for more improvement - for example, the "Content creation" (node/add) page could probably disappear completely, with its functionality merged into the Content Types (admin/build/types) page or something like that... and in that case the top level administration items could go into the "Manage" section in addition to the main admin page, maybe like this:

MANAGE:
* By module
* By task
> Content
> Site Building
> Users
> Site Configuration
> Reports

That would be a bigger change, though, presumably not this patch.

Here is a better screenshot - I changed "Content creation" to "Add content" because that's a much better name.

I also noticed that the previous screenshot made it look like this menu item had children (this is due to a small bug combined with the fact that the cache had not been rebuilt before I made the screenshot). As you can see here, the menu item in fact has no children (since they have been moved to the "Create" menu), but the 'node/add' page itself still shows all content types like before.

I kind of like the idea of
Welcome Jane. My account. Log out.

But I'm wondering if we can agree in general, I think so, onhaving that seperate menu, enabled by default, in he upper right inthe core themes, and agree to hash out the
Jane link. logout.
Vs
My account. Logout.
In a follow-up issue.

Yeah! This is a really great improvment!

Maybe the last big picture decision is the extra create menu idea... To help settle the do stuff vs admin discussion.

Is that something people think we need to settle before proceeding?

I think the choice is
A) have a browse/navigate menu and an admin/do stuff menu
or
B) have A) plus a create menu

I think if we can pick a or b, that we can do the wording and naming in separate follow-up issues.

-YesCT (trying to summarize)

I have to say I really like the Management menu in #63. This is exactly what I do in my install profile anyway.

@David - there are several other issues to reorganize the menu. It took 3 days in the #drupal-usability channel to come to agreement on the above very basic splitting, so I am strongly opposed to any additional, fundamental changes within the context of *this* issue.

Webchick wanted 'My account' -> username, and wanted the 3 sets of links. You'll notice that the prior patch removed 'secondary-menu' and then put it back. So, please go into the IRC channel and get a real consensus if you don't like the direction.

So, possible actual bugs:

• 3 tops menus breaks Garland - probably so.
• Menu help needs to be updated.

Maybe we can just remove secondary links as a feature of the Garland page template?

Well, reading the discussion above, @sun in particular has raised some pretty valid concerns that I don't think anyone has addressed yet. I was just aiming for the minimal change to the patch that would address them without totally changing the focus of the issue.

And I think you know my feelings about IRC :) More specifically, a discussion that takes place in IRC but isn't summarized in the issue queue means that people can't come back later and understand the rationale for any ideas put forward there.

This issue is only supposed to be about splitting up Navigation into something sensible, which is all that's required to fix the actual issue identified in Baltimore testing (and previous).

Adding new theme variables seems like really dangerous scope creep to me given we're already at 70 follow-ups.

I'd suggest we go back to the earlier patch by pwolanin in #52 which:

Moves the user links to the secondary menu.

Keeps 'My account' as 'My account'.

Then - we open up three followup issues:

1. create a 'user links' menu + page template variable (i.e. fix Garland)

2. create proper theme functions for primary, secondary and user links so we can easily add 'Welcome, username' in plain text, which to me seems like better practice than just changing My Account itself. This could then be a theme setting or something - better to do it properly in another issue than force it into this one.
3. Decide on a name for the create/admin menu - or making 'create' top level like David's suggestion - i.e. just pick anything for the damn menu name and avoid bikeshedding it here.

Those are all good ideas, but they're turning this issue into into a quagmire trying to discuss them all simultaneously.

I really need final direction here from Dries or webchick. I feel like we are going in circles - I jumped in on this since I thought we had come to a consensus on the design to be implemented. Just tell me the final decision as to what needs to be done so we can get this issue closed and people can start looking at all the dependent issues.

I say we do what catch recommends in #73.

I like the direction David took his prototype in (I prefer David's screenshot over Peter's), but I prefer to go with Peter's patch for now, and then work towards David's patch with follow-up patches (I think Peter's patch is cleaner, and avoids scope creep).

@catch's plan in #73 certainly makes sense to me, especially if the 3rd followup is considered critical.

As such, I suggest committing this patch with "Do Stuff" as the interim menu name (as Peter originally proposed), since it's actually the most accurate :)

I agree with #76, that will also let us move forward on #351249: Finer control over the Parent Menu select box. I do like David's ideas for further splits and would like to see some follow-on patches for them. But now I guess we need someone to re-roll #52 and get it current.

Ok, here's a re-roll that takes my last patch back closer to prior incarnations. I reverted all the theme changes, and made the user menu the default source for the Secondary links. Put the user account link back to being "My account".

I cleaned up the menu module help and form text more.

Also, fixed two DBTNG bugs in menu.inc 1) where the results were coming back as objects rather than arrays, which causes a fatal error, and 2) where we were again sending in a boolean instead of an int (see lines 1943 and 1954). These bugs hit when disabling/enabling the menu module, so I needed to include them in the patch.

I'll commit this when the follow-up issues have been created and linked to from this issue. Thanks! :)

#408142: Create a 'user links' menu + page template variable
#408148: Create sub-theme functions for rendering menus
#408150: Add "Welcome, $username" to user links
#408160: Normal users should not see the create content link appear by default in a menu called "Management"

for menu fix: #408338: fix_menu_navigation_links_rebuild to correctly handle changing menu_name

Committed to CVS HEAD. Thanks all. See you in the follow-up issues. :)

omg.

don't forget this little issue also for follow-up: #351249: Finer control over the Parent Menu select box

bojhan: here's a screenshot of the default screen after install. let me know if you want something more specific..

err, you need to view that in it's own window, or else the top right navigation gets cut off.

direct link: http://skitch.com/beeradb/be59f/localhost

So glad this got committed. Thanks everyone.

@sun: Could you elaborate on the concerns you have with this issue? I have only skimmed this issue, but agreed with your criticism of earlier patches and was then led to believe that these were resolved.

I learned that "scope creep" is happily accepted for issues tagged with "Favorite-of-Dries". That's a good thing to know and we can advance on it in the future.

I also learned that some parts of this patch were about fixing some internal menu system and breadcrumb bugs. That's a good thing, because some of them can even be backported to D6 - in a separate issue.

Additionally, I learned that the actual topic of this issue was considered minor, a "reversible change", someone can still alter or revert until code freeze. Thorough and solid concepts are plain useless, not worth to discuss. What counts is that a change was committed, as an immediate reaction to a "suddenly discovered" usability issue we somehow did not know before. We can all feel warm and fuzzy now, because, yes, something has been altered.

All concerns raised in #27, #38, and #59 have been ignored. I won't repeat them. Instead, I'm asking myself whether it's worth to raise any concerns at all.

I re-read your comments, and I agree with you totally, except for one point:

If we commit this patch, then we will advance on it

If I got it right, the patch simply moved the user-related links to a new menu by default. If a total-admin-area-revamp were to take place I don't think it could be stopped by 2 links in a different location than before.
I think some more people, preferably some with a little higher ranks in the community should pitch in on this, maybe Leisa or Mark could say a few sentences on what they see happening.
But I definitely do not believe that this is "over".

Therefore: needs work.

@tstoeckler - the patch was committed and we are moving on to the follow-up issues. Setting it to "needs work" now is just annoying unless you have a convincing argument for a roll-back. Please read the last patch in detail and understand the menu API changes and fixes before making any further comments on what the patch does or does not do.

Also we have four followup issues already, adding extras is fine and you can link them from here. pwolanin is right that we don't need this issue re-opened unless there's a need for a rollback.

I think the "big picture" followups to this issue should be dealt with at #408160: Normal users should not see the create content link appear by default in a menu called "Management". That issue is marked as critical, which means that Drupal 7 will not be released without it. It seems that the concerns raised by @sun can (and should) be dealt with there.

In the meantime, it's a little disconcerting that if you read the comments above, this large patch appears to have been committed to Drupal core without anyone actually reviewing the code. A lot of people (including me) reviewed the ideas in the patch but said something like "I haven't reviewed the code yet"......

Since late is better than never, I reviewed the patch now and filed the following followup bug reports (some critical):

• #410636: D6->D7 update does not create required menus
• #410638: "Powered by Drupal" block settings showing up when configuring menu blocks
• #410646: "Secondary menu" exists but is no longer the default source for the secondary links

Also this followup/cleanup, which is too trivial to merit a separate issue - let's just get it in :)

Just text cleanup so trivial indeed - obviously at least one place I just forgot to revert a change.

The secondary menu not being used I thought was going to be handled in #408142: Create a 'user links' menu + page template variable, so I think #410646: "Secondary menu" exists but is no longer the default source for the secondary links may be duplicate to that.

The menu upgrade path was broken prior to this patch from looking at the code, but should be fixed in some form.

Committed follow-up patch in #95. Marking issue fixed, although it looks like we have lots more discussing to do in the follow-up issues.

The usability of this is messed up! The "User menu" is displayed in the "Secondary menu" (which is different to the other "Secondary menu" and the Secondary menu block)

Further comments here:
#410646: "Secondary menu" exists but is no longer the default source for the secondary links

Looks like time was spent making something work with Garland, but didn't take into account the default Drupal output (Stark theme) and the effect on other themes

#751494: D6: Add variable for setting active menu name is a partial D6 backport of the fix for this issue.

Related follow-up discussion also taking place at #410646: "Secondary menu" exists but is no longer the default source for the secondary links.