Theme settings for main/secondary variables mismatch with menu settings

I agree that we should switch back to primary and secondary menu instead of main. We will also need a good cleanup as you kindly give out examples.

However we should create specific issues and not try to put everything in a single issue.

Having complicated templates and code for the menu does not make this critical to fix, though.

It should be primary and secondary links, and main and secondary menu. The problem with having both main, or both primary, is that they often don't match up 1-1 on real sites.

No, we got stuck in the original issue with that as well.

On user links being secondary menu, there's an existing issue at #408142: Create a 'user links' menu + page template variable.

Actually it makes sense to link to the whole history while I'm here.

#273137: Split Navigation to User and Administration menu.

#382890: Move 'My account, Help & Logout' links to separate menu and place it top right

#503810: Convert primary and secondary menus to blocks

Basically, an initial patch went in, we opened followup issues for cleanup, the followup issues never got followed up, so what's in HEAD is a bit of a mess.

Changing this to a meta issue [to track related issues].

Sub.

> primary and secondary links, and main and secondary menu

Then you are still using the word 'secondary' for two things that may be completely different!

The only solution I see is to use a completely different set of words, so you have something like Primary and Secondary menu, and Alpha and Beta links.

Well 'secondary is the same, but in D6 they were all called "primary links" and "secondary links" - both the variable and the menus themselves, so it's 50% more different than it was.

@ #5

Can you think of an alternative for secondary menu that makes sense?

How about "satellite"? As in, "main menu" and "satellite menu"?

sat⋅el⋅lite  [sat-l-ahyt]
–adjective
7. subordinate to another authority, outside power, or the like.

This intuitively makes people think of a "smaller", less important menu, and its not confined to any one region of the template ("floats around" to different areas depending on theme). And unlike "subordinate menu", which might otherwise work well, it won't get abbreviated into something like "sub menu", which would be really confusing.

This issue should be 'critical' in my opinion. D7 is really looking good, but this is the most annoying issue I have come across.

I made some comments on this related issue before I found this one:
#410646: "Secondary menu" exists but is no longer the default source for the secondary links

My main gripe is that the so-called "Secondary menu" that is the theme 'feature' (which is actually the User menu), shares the same name as the "Secondary menu" menu.

I'm trying to follow the thread of this issue, but it's quite difficult to jump into at this point. Anyway, I was referred here because of my comments in http://drupal.org/node/511218#comment-2774554. Basically, I think it's quite confusing that when you create a new site with Drupal 7 and then click the "view your new site" link, you see the user menu both in Toolbar and Garland.

catch & xmacinfo have explained why that is, but it still is a bit of an awkward introduction to the Drupal UI.

Does anyone here think there are still changes that can be made to clean up the menu system, both in usability and code, prior to Drupal 7's release? I think #503810: Convert primary and secondary menus to blocks would be awesome, but I can see why that was pushed to 8.x.

I've attached the screenshot of the user menu awkwardness that I posted in the other issue.

> My main gripe is that the so-called "Secondary menu" that is the theme 'feature' (which is actually the User menu), shares the same name as the "Secondary menu" menu.

Yup, that's just a total confusion; has been since D5 at least. :(

#503810: Convert primary and secondary menus to blocks already contains a more detailed discussion about actually required changes.

Yes, but that's for 8 and this is for 7.

Pretty sure it's too late for 7 here, since it's feature and string frozen now.

I don't think this is really a meta-issue; the original proposal is pretty focused, actually. And I think we should at least discuss what can be done about this in Drupal 7 still.

Some examples of some of the confusion popping up in specific comments on other issues:
http://drupal.org/node/503810#comment-2590112
http://drupal.org/node/410646#comment-3167098

To recap, the fundamental problem is that in D7 we are using the word "menu" to refer to two different things that don't really have anything to do with each other. This may or may not be a regression compared to D6, which essentially used the word "links" in all those places and also was known from usability testing to be confusing - as a result, everything was changed to "menu" in #270917: UB Usability : Labeling primary link label.. But I think to be clear here we really need two different terms. Mixing it all together gives the false impression that a particular menu is tied to a particular theme feature, which is especially confusing because even now by default D7 doesn't configure things that way (the user menu is displayed in the secondary links, not the secondary menu).

Let's talk about what's ideal to do and then see what's possible still for Drupal 7:

1. On the D7 theme settings page, you can toggle the "Main menu" or "Secondary menu". This setting has nothing to do with those specific menus that appear at admin/structure/menu (and which might actually be displayed elsewhere on the page via blocks; in which case toggling the link doesn't at all do what it implies). We need different terminology here. In the absence of anything else, going back to "Primary links" and "Secondary links" might be OK.

2. In page.tpl.php files, we have $main_menu and $secondary_menu. Ideally, switching back to $primary_links and $secondary_links makes sense, for the same reason as above.

3. The markup surrounding these items in the theme looks like <ul id="main-menu" class="links">. This is confusing because it implies the "main menu" is displayed there even though it doesn't have to be, and also because the actual menu that is displayed there is never referenced in the class/ID; it would be nice to do that.

4. The default menus provided by system.module are called "Main menu" and "Secondary menu". I think this is definitely a good change compared to D6, where they were "Primary links" and "Secondary links". #410646: "Secondary menu" exists but is no longer the default source for the secondary links may make things even better here.

So, what can we still realistically change? The usability testing that was hoped for in #270917: UB Usability : Labeling primary link label. that would validate (or invalidate) whether the new terminology was good did not (as far as I know?) happen, so we are probably at the point where we have to start making some final decisions without it.

At http://drupal.org/node/410646#comment-3167400 JohnAlbin points out that terminology such as "primary navigation" and "secondary navigation" is a lot more common around the web, and may be clearer than "primary links" and "secondary links".

We could consider that here. I think it might be better, although then risks confusion with the default "Navigation" menu that the menu system provides, of course :(

Proposal in 19 sounds good to me.

We actually still have 'Source for the Main links' in the UI at admin/structure/menu/settings

Subscribe. Moderately opinionated comments left elsewhere. :)

sub

Subscribing. I think this is a dupe though, and that it would be easier to discuss all in one place. :/

Let's see if we can fix this. Although it involves a (minor/very simple) API change, I think this is a major bug and a clear regression from D6. The D6 terminology might not have been perfect, but at least it used two different words to represent two different things, and you could teach people what those words meant.

In D7, if we don't fix this we'll be teaching people something like this:

"If you uncheck the 'Main menu' theme setting, that will prevent the main menu from appearing (regardless of whether the main menu itself is displayed in it), but won't prevent the main menu itself from displaying."

And that's not really an exaggeration :)

Attached patch is mostly a straight-up conversion along the lines of what was discussed previously ("menu" => "links" in places where it's appropriate), including some textual cleanups and other stuff that did not make it into the final committed patch at #410646: "Secondary menu" exists but is no longer the default source for the secondary links.

> "If you uncheck the 'Main menu' theme setting, that will prevent the main menu from appearing (regardless of whether the main menu itself is displayed in it), but won't prevent the main menu itself from displaying."

Yes. We have a mess on our hands :(

+++ includes/menu.inc	24 Aug 2010 04:09:32 -0000
@@ -1621,18 +1621,17 @@ function menu_list_system_menus() {
- * Return an array of links to be rendered as the Main menu.
+ * Return an array of links to be rendered as the Main navigation links.
  */
-function menu_main_menu() {
+function menu_main_links() {
   return menu_navigation_links(variable_get('menu_main_links_source', 'main-menu'));
 }

Didn't this ugly 1-liner function got ripped out in that other issue?

Powered by Dreditor.

I don't see how we can do more than half the things in this patch at this stage.

-function menu_main_menu() {
+function menu_main_links() {
...
-function menu_secondary_menu() {
+function menu_secondary_links() {
...
-  $variables['main_menu']         = theme_get_setting('toggle_main_menu') ? menu_main_menu() : array();
-  $variables['secondary_menu']    = theme_get_setting('toggle_secondary_menu') ? menu_secondary_menu() : array();
+  $variables['main_links']        = theme_get_setting('toggle_main_links') ? menu_main_links() : array();
+  $variables['secondary_links']   = theme_get_setting('toggle_secondary_links') ? menu_secondary_links() : array();

Definitely not. Breaks themes. And for absolutely no good reason that I can see?

These changes seem to be included because in the menu settings interface at admin/structure/menu/settings we currently have a bug where we call these "Main links" and "Secondary links" instead of "Main menu" and "Secondary menu," which is what we call them everywhere else. See #270917: UB Usability : Labeling primary link label. for the original rationale behind the explicit links => menu change.

So, rather than breaking tons of stuff, let's just fix the labels here. That makes them consistent with both admin/appearance/settings/seven and the variable names which were already correctly changed in the referenced issue above. A lot of the other string changes in this patch though look pretty good.

Tagging as beta blocker, because this issue has a significant impact on book authors and documentation team.

And I'm trying to understand this:

"If you uncheck the 'Main menu' theme setting, that will prevent the main menu from appearing (regardless of whether the main menu itself is displayed in it), but won't prevent the main menu itself from displaying."

...and how it's any different from D6's behaviour?

Are you saying I can still add content to "Main menu" even when I've turned off display of Main menu in my theme? Or that I can still manually add the "Main menu" block to the right sidebar and it will not respect my theme visibility setting? Well, yes. The same thing happens in D6 too, with Primary links. This isn't a regression.

"If you uncheck the 'Main menu' theme setting, that will prevent the main menu from appearing (regardless of whether the main menu itself is displayed in it), but won't prevent the main menu itself from displaying."

...and how it's any different from D6's behaviour?

At least in Drupal 6 the words were not quite as overloaded. Actually, a fair comparison of the sentences would be this:

D6:
"If you uncheck the 'Primary links' theme setting, that will prevent the primary links from appearing (regardless of whether the "Primary links" menu is displayed in it), but won't prevent the "Primary links" menu from displaying."

D7:
"If you uncheck the 'Main menu' theme setting, that will prevent the main menu from appearing (regardless of whether the "Main menu" menu is displayed in it), but won't prevent the "Main menu" menu from displaying."

Neither is great, but D6 does not overload the word quite as much.

Also, consider that in D6 you could easily use the admin UI to rename the "Primary links" and "Secondary links" menus to whatever you want, and thereby at least remove the confusion on your own site. In D7, the admin UI forbids you from doing this (for reasons I don't entirely understand), so that at least with Drupal core, you are stuck with the "Main menu" menu and the "Main menu" theme setting and no way to remove that confusion. For example, compare:

http://api.drupal.org/api/function/menu_list_system_menus/6
http://api.drupal.org/api/function/menu_list_system_menus/7

(notice the hardcoded human-readable menu names that are in D7 but not in D6), and:

http://api.drupal.org/api/function/menu_edit_menu/6
http://api.drupal.org/api/function/menu_edit_menu/7

(notice the #access line and comment in D7: "The title of a system menu cannot be altered") Perhaps that limitation is its own bug, and if it could be fixed that would make this one less serious.

But the fundamental bug here is that the same word ("menu") is being used to refer to two different things. There should be two words. If it's too late to fix it for themes in D7, maybe we could at least still fix the end-user terminology (although then there'd be an inconsistency between the code and the UI).

Also, consider that in D6 you could easily use the admin UI to rename the "Primary links" and "Secondary links" menus to whatever you want, and thereby at least remove the confusion on your own site. In D7, the admin UI forbids you from doing this (for reasons I don't entirely understand), so that at least with Drupal core, you are stuck with the "Main menu" menu and the "Main menu" theme setting and no way to remove that confusion.

I'd actually be interested in seeing how hard it would be to change this, because I agree that's really confusing, it'd be a simple change UX-wise that would simply bring the behaviour of these menus in-line with what users expect to happen, and also I can just smell the ire of distribution authors everywhere in the air already. ;) But I have the feeling it's a horrible change or we probably would've done it already. :P

But the fundamental bug here is that the same word ("menu") is being used to refer to two different things. There should be two words. If it's too late to fix it for themes in D7, maybe we could at least still fix the end-user terminology (although then there'd be an inconsistency between the code and the UI).

Hm. I'd like to hear more opinions on this, particularly from the UX team. To me, it seems less confusing that we don't call the same thing a "menu" in some places and "links" in another. I sense that the distinction between a menu itself and links in the menu (which I gather is what you mean by "two different things") is purely a Drupal developer distinction, and end users really couldn't give a toss.

Yeah, I agree - it is better to use "menu" in both places.

I still worry about using "Main menu" in both places, though. It gives the false impression that a particular menu is always tied to a particular theme feature - and we are seeing that confusion everywhere. I don't think I have a better name for the menu, though.

There's no doubt its going to be confusing to some users, then again the entire concept of this is baffling to many users and I would gather there are thousands of users who have no clue this feature even exists.

I'm kind of with webchick here - will users really give a toss and actually make the distinction, perhaps they will just see this as being able the "change the horizontal menu at the top of the page", as opposed to the much more abstract "change the source of the horizontal menu at the top of the page".

I see this perhaps rather differently than most here in this queue - the way I see is that "cool, I can change the horizontal menu thingee, and wow, I still have the block I can re-use somewhere else - I can have two main menus, great!".

My 2 cents. And yes, rather too late for variable changes, but I'd be cool with that, and I have 6 themes ported already, in the grand scheme of things its a trivial change for a themer/dev.

The only alternative name for "Main menu" I can think of is "Main navigation" (and then we should also rename "User menu" to "User navigation"). If that's acceptable to the UX team, that would change your sentence to:

"If you uncheck the 'Main menu' theme setting, that will prevent the main navigation from appearing (regardless of whether the "Main navigation" menu is displayed in it), but won't prevent the "Main navigation" menu from displaying."

(though I still think that sentence is way overly confusingly worded just to make a point. ;))

I'm really sensitive about renaming major page elements at this phase, but OTOH I also really don't think we can ship with things like this http://drupal.org/node/511258#comment-3587028, so we should take the opportunity to get it all right.

And Jeff, though that's fine for you, my experience has been that every time we make API changes, it sends the clear signal to theme/module developers that "It's not time for me to port my stuff yet." I have recently seen people removing themselves from their D7CX pledges as a result. This absolutely can't continue. So unless there's a vitally important reason, and "huh, that inconsistency is a little weird" is not vitally important, I'm really not okay with changing things that have been in place for over a year.

Meh. But then we have Main navigation, User navigation, and "Navigation." Margh.

Anyway, could we at least get a patch here that fixes the labels on the menu settings page? That seems like a straight-forward bug fix that at least makes things consistent.

I agree that the internal name changes are too heavy for D7. Let's just fix the UI.

+++ modules/menu/menu.module	18 Oct 2010 15:32:05 -0000
@@ -31,6 +31,14 @@ function menu_help($path, $arg) {
+      $output .= t('Two configurable menu areas are provided within the page template. <a href="@theme-settings-url">Themes</a> may display the menus in non-conventional locations or may choose to omit them completely.', array(
+        '@theme-settings-url' => url('admin/appearance/settings'),

This patch overall looks good.

However, could we try to explain a bit better what this feature does -- if as a newbie I read 'menu area' I might imagine I get the *whole* menu. I want to say 'menu slice' but I worry that sounds too technical. 'One level of the menu' or something like that?

Powered by Dreditor.

Wait... that doesn't look like the patch webchick was asking for? Let's make sure we are on the same page - I thought the new plan was to switch to "menu" everywhere so that at least it is consistent, if nothing else.

Also, regarding this:

Also, consider that in D6 you could easily use the admin UI to rename the "Primary links" and "Secondary links" menus to whatever you want, and thereby at least remove the confusion on your own site. In D7, the admin UI forbids you from doing this (for reasons I don't entirely understand), so that at least with Drupal core, you are stuck with the "Main menu" menu and the "Main menu" theme setting and no way to remove that confusion.

I'd actually be interested in seeing how hard it would be to change this, because I agree that's really confusing, it'd be a simple change UX-wise that would simply bring the behaviour of these menus in-line with what users expect to happen, and also I can just smell the ire of distribution authors everywhere in the air already. ;) But I have the feeling it's a horrible change or we probably would've done it already. :P

I looked into it briefly and it seems like this could be fixed. I think the restriction was introduced earlier in D7 because there was no way for menu.module to alter system.module's blocks (thus, the names you gave them in the menu.module admin UI would not show up when the menu was displayed as a block). However, we now have alter hooks in the block module that should allow this to work just fine. Maybe this would be better as a separate issue, and I don't have time to write a patch right at the moment anyway.

• I don't think that renaming those labels to "menu" makes anything any clearer. Rather the opposite: It increases confusion between what a "menu" is and what it is not. This functionality is about links, not menus. A menu just happens to be the source for the links. Additionally, "links" is technically more correct, because a "menu" commonly means a "menu tree", but these are simple, non-hierarchical link lists.
• The important corrections in this patch are the label changes. The new labels in Menu's settings form make clear that a "menu" is used as source for "links". Additionally, the theme settings still mentioned "menus", although they mean the identical thing as Menu's settings form.
• Another key difference is that the help text on Menu's settings page contains a link to the theme settings. I actually wanted to also add a link back from there to Menu's settings page, but as of now, System's theme settings only use a label, so that would require some hacks.
• Confusion left for D8:
  • By default, Main links and Secondary links are generated out of the Main menu. You can enable the links in your theme. But Menu module is optional, so you may not be able to configure them. Effectively, the entire configuration has to be moved into theme settings for D8 to make any sense.
  • Name clashes of internally used names. Slightly annoying, but doesn't break anything.

> # I don't think that renaming those labels to "menu" makes anything any clearer. Rather the opposite: It increases confusion between what a "menu" is and what it is not. This functionality is about links, not menus. A menu just happens to be the source for the links. Additionally, "links" is technically more correct, because a "menu" commonly means a "menu tree", but these are simple, non-hierarchical link lists.

+1

> Confusion left for D8:

AFAIK the plan for D8 is to move at least part of menu_blocs into core, so in effect you can have any number of 'link slices' from any number of menus, and they are blocks instead of hardcoded theme magic.

AFAICT suns patch very neatly solves this issue, especially the link to the themes, nice touch and much needed. We're not going to get this perfect in D7, and this looks like a contender, at the very least removing the major wtf.

@sun's patch does the same thing I already advocated above, to which @webchick said this in response:

Hm. I'd like to hear more opinions on this, particularly from the UX team. To me, it seems less confusing that we don't call the same thing a "menu" in some places and "links" in another. I sense that the distinction between a menu itself and links in the menu (which I gather is what you mean by "two different things") is purely a Drupal developer distinction, and end users really couldn't give a toss.

I couldn't think of a good argument against that (in fact, I think it's probably true). If you all think you can come up with one, please do - and good luck! :)

In the meantime, I'm going to create a separate issue for the "default menu names are hardcoded and can't be changed via the UI" bug tonight and post a patch there. (So that if this issue starts to go in circles, then at least that won't get lost.)

Patch is at #945654: Default menus have hardcoded titles which cannot be edited

+1 for sun's patch, with screenshot in #38. That might be the best solution we can get for this release of Drupal.

We need sign-off from the UX team to go this route. We explicitly removed the word "links" here because we had numerous evidence during usability testing that people couldn't figure this out.

Tagging.

For background see #302149: Usability: confusing/duplicate use of names in menu admin which was I think where this wording got introduced. I can't find the original issue where the main menu/secondary menu change happened originally now, this would have the original usability reason for changing it from D6 at all. I know that both me and pwolanin worked on that, but yeah, can't find it.

webchick found the original issue #270917: UB Usability : Labeling primary link label. - this was committed with almost zero discussion, and was more or less a find and replace patch, so I think it's completely fine to try to fix it now via the labeling.

* This is not a regression from D6. D6 was completely off the wall, and we changed this in the first place because it was so bad. I haven't seen anyone in this issue who isn't familiar with how it worked in D6, or that has tested D6 vs. D7 back to back. It might not be an improvement over D6 but that's not a regression.

* sun is completely off the mark in #38 where he claims these aren't menus but are actually links, I don't even understand what that means. I can make a menu which is a single level and put it in a block. They are menus, there are legacy variables in the theme system for rendering two configurable menus, which could easily be implemented as menu blocks like any other menu, but hasn't because code freeze happened before that patch got anywhere. If you call them links, then I will point out the the menu blocks render 'menu links' too, that gets us nowhere.

webchick mentioned that the theme settings vs. the menu settings are mismatched, these should be brought into line, anything else is D8.

Discussed this with webchick in irc as well, I'm downgrading this to normal, removing the beta blocker tag, the theme settings sounds like a genuine bug, but just a normal one. I hope people work on menu_block in core for D8 so we can rip this feature out entirely.

> sun is completely off the mark in #38 where he claims these aren't menus but are actually links, I don't even understand what that means. I can make a menu which is a single level and put it in a block

Ok so it's a single-level menu. The UI still need to explain there's a difference between a menu tree and single level of a menu.

I hope people work on menu_block in core for D8 so we can rip this feature out entirely. - catch

Couldn't agree more, just a shame it wasn't ripped out before now.

More or less the problem: The current interface text in the theme settings refers to "menus", which makes users believe that those theme settings map 1:1 to the actual menus, but actually, those "link lists" are configurable and don't necessarily map to those menus. They are link lists, based on an arbitrary, configurable menu, "period." -- Confusing as hell :-D

@catch: It looks like this issue stalled since your last follow-up. After running into this page/form for #950034: Using the same source for main/secondary with a custom menu doesn't work this weekend, I think I wouldn't have been able to configure these menu settings, if I hadn't know the internal code logic.

Nothing new to review

I have to say I have never understood all the things done with main and secondary links. It certainly adds a lot of, to me, unnecessary code to page.tpl and seems to generate an equal amount in template.php in many themes. Aren't 'menus' blocks of class 'block-menu'? I can strip out all that code and simply assign 'main menu' and 'user menu' to the header and footer regions if I want and there are tons of classes and ids available for me to style them. They can certainly be assigned that way in bartik, and thus carried over to new themes as part of default assignment during theme enable. And nothing prevents an administrator locating them where they desire. Just what is it that makes it necessary to hard code these links into a theme?

ps. not to say it isn't useful to manipulate these or any other menus/links but the code in page.tpl implies to me that drupal can't be built ONLY with its generic layout objects, regions and blocks

@dcrocks: #503810: Convert primary and secondary menus to blocks

I am trying to say: aren't all menus rendered as blocks and therefore, since main and secondary links are based on menus, aren't primary and secondary links already blocks. And again, why do they need special treatment? Why do we have them? Is this discussion necessary?

@dcrocks: Please keep that topic and discussion out of this issue. Thanks.

Menu links are blocked in D8, so no need to worry about that anymore.