add user_menu block to the header region in default install profile

This is going to require GUI and Design changes for Garland.

Here's a patch to add the user-menu block to the header region in the default theme.

Where's the patch?

I really do not think CSS should happen lower down than Garland, we're trying to remove design styles from core, not put more in.

You have other issues to address - such as all menus should have a header (accessibility), which in this case needs to be hidden in Garland and Bartik, so we need the .element-invisible class on the header, but not in Stark.

Don't worry about Bartik - its known issue that the header region looks like crap, we have an issue open for it already.

If this really is the route forward then one would think it makes sense to set the Primary Menu as source for Secondary links which would enable the coupling feature by default (since the other patch is nuking secondary menu out of core).

Yes, we can get somewhat evil here and leverage the block $title_attributes, the docs say we can use this for classes, working on it.

Two things I noticed that are really WTF in style.css:

  .region-header * {
    display: inline;
  }

This is weird! Why would we want this? Disabling this recovers the default styling. See screenshot.

  ul li.leaf a, ul li.expanded a, ul li.collapsed a {
    display:block;
  }

Right.. could be in the sidebar. But not in a header or footer? This makes the whole header region react on the links. To fix, we could make this selector more specific. Or better: add the class .inline to the ul and make ul.inline li{ display: inline; }

OK, Bartik is already doing this:

/**
 * Override or insert variables into the block template.
 */
function bartik_preprocess_block(&$variables) {
  // In the header region, visually hide the title of any menu block or of the
  // user login block, but leave it accessible.
  if ($variables['block']->region == 'header' && ($variables['block']->module == 'user' && $variables['block']->delta == 'login' || in_array('block-menu', $variables['classes_array']))) {
    $variables['title_attributes_array']['class'][] = 'element-invisible';
  }

So needs to be added to Garland - which can be a separate issue after this one.

So what needs to done in this issue?
I'd willing to work on it but could use some scope.

Is Garland styling included? Or separate?

And is it critical?

OK, sounds great. The relevant issue for Bartik is here #845834: Fix Bartiks Header because its totally borked which as some screenshots and ideas.

> we probably need to use THEMENAME_menu_tree__MENU_NAME()

What about if a user moves this menu block to the sidebar, what happens then?

Thinking this is just easier to theme with CSS and don't make assumptions about classes to add etc.

Not coming up with a way right now that doesnt include regex...

Heres a sub-patch (css only) for Garland to test out some CSS.

Ouch, that was way to fragile - check this out...

I don't understand what makes this a critical issue? Putting menu blocks in the header region has been ugly for a long time.... and the workaround is simply to not put them there :)

I slept on it and I still have no real solution - I know this was one of the main reasons I objected to this in the main issue #410646 (what to do with expanded child menu items).

Not having a smart way of dealing with these would introduce a pretty big wtf - both for end users and themers. As a themer I am now forced to deal with this and its not easy - I could do ugly things like hiding child items (display: none) or something smart like position: fixed; (or absolute) and moving it over to the edge of the screen - neither of which is really acceptable in core (some sort of floating position:fixed; menu could be I suppose).

Webchick vetoed our proposed API changes to template_preprocess_page based on the fact that its an API change and would impact on themers who have ported their themes to D7. When I look at this proposed change its on the same level if not worse - because an API change I can deal with easily by making a quick change to my template files - this however is not easy to deal with and forces me to rethink my entire design and jump through many hoops to make it work - theres no easy solution afaict.

If someone thinks up a great way of easily dealing with this I'm all ears - however personally, at this stage of the D7 cycle, I'm not hugely supportive of this change and would rather live with User Menu in the Secondary Links because at least I have a known way of dealing with them easily and its highly likely that my theme already does.

I'm putting this back to normal and making it a feature request - I think that is where it lives better because Drupal is not broken without this, and its not a bug - there is no bug to be fixed - the user menu is output via secondary links which all core front end themes are required to support.