admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus)

I think this is a direct consequence of making Modules a tab. I think that depending on how we are going to use tabs in the future, we can either just list all tabs in a menu block (just like other subitems) or designate some tabs as showing in the menu. If this item is not a tab (ie. your patch), there is no way with the toolbar to get there. Please demonstrate if you think otherwise. Breadcrumbs do not help, since they do not allow navigating further down the structure, which is the problem here.

Same issue applies to other things made tabs like the comment overview screen on admin/content/comment.

I'd think that the expert profile will want to enable the toolbar module and Seven as well, and that the solution might be just that: enable toolbar.module as well as Seven in both install profiles?

No, I don't think so... the toolbar module is an optional module (and should remain so, in my very strong opinion, so that power users can swap it out for something like Admin Menu). So the IA still needs to work even without it. Expert profile gives us the opportunity to test with/without.

admin_menu is already compatible with putting items on tabs, since it shows all tabs in the menu structure already. The menu tree generator for the menu block does not display tabs however, since they are used for actions which might make a non-collapsed menu quite busy. However, we are onto moving action tabs into an action area on the admin UI (see #542658: Move action "tabs" out of local tasks), so we might want to end up listing tabs on the menu at the end.

@webchick, I'm not suggesting that toolbar.module becomes a required module. I'm just suggesting that it is enabled by default in both profiles. I agree that power users should be able to swap it out for something like admin menu.

Just imagine all the books and documentation with Seven screenshots. I genuinely believe that enabling toolbar module and Seven will provide the best experience, even for people that start out with the expert profile. The expert profile is about not creating dummy data, it is not about crippling the user experience.

It is unclear if you read my comment wrong, or if you are suggesting that people using the expert profile will not want to use the toolbar and Seven theme? I think most people will want to. I know, I'd use the expert profile _and_ want the Seven and the toolbar module. I imagine many other developers would think alike.

There are effectively a couple of scenarios:

1. We enable toolbar.module by default in all profiles, but allow people to swap it out by a module like admin_menu. In this case, as Gabor suggests, admin_menu does not require this patch.
2. We have toolbar.module but also design an experience for people that don't want to use any toolbar-like module (neither admin_menu nor toolbar module). We'd need this patch to help provide an second experience for people that want no toolbar-like modules. It's going to be a pain during development -- as a contributed module author, I don't want to design and test for two experiences.

Retitled for the more general issue. As said above, pages like admin/content/comment have the same issue. The problem here is that these tabs are not visible in overviews like /admin and menus like the Management menu. Note that currently, even the top level People, Appearance and Content items are not visible on /admin and there is a patch for that at #551080: List non-container items on /admin for a complete overview.

Dries: Sorry, I was trying to say what alexanderpas is saying: that we need to make sure that Drupal works without a toolbar module of any kind and just "raw" menu items. I think I also might've misread in your comment that your suggestion to fix the issue was to enable the toolbar module in all core profiles.

I don't think expert profile and toolbar module/Seven are mutually incompatible, but at the moment the lack of this being turned on by default in both does provide a nice, easy testing platform for this problem.

Because the two issues are quite different I'd love to get them fixed one by one. This one is about tabs not listed in the items of system admin blocks, that one is about no system block being shown for standalone pages.

Once #551080: List non-container items on /admin for a complete overview is committed, I'm happy to help. Will see how time allows.

The configuration and modules item is probably tricky, since it has both subcategories and tabs, but the others only use tabs or categories only, so they should be easy to fix. Not that a contributed module would not possibly add a tab on the Structure item, but that is highly discouraged :)

Here is a first stab at a patch for this problem. The tasks are also queries and then faked to look like menu links for the rest of the processing. At least their required keys are added for later processing. If a container has both a default local task and sub menu items, then the default local task is not displayed, since the overview offers a list of all subitems already.

This is how it looks:

Note that I've also removed an extraneous "List" tab from the People admin page, since that was the only tab. The add user item was migrated to be an action, so we should have removed the orphan default tab. Also, some tabs lack a description. We can either add them here or in another patch.

Finally, the Configuration and Modules item still has multiple bugs. For some interesting reason, only the Development category shows up and the Modules tab is not listed either. At least the modules tab problem belongs in this issue, but we might as well fix the other items not appearing too. That is a bug with or without this patch though.

Updated patch adds the descriptions. With all core modules enabled I've also found the book module adding a tab but not a description with it. Plus the default content top item mentioned comments, while that one is an optional core module (and comment module alters that description to include comments if enabled). So this one turns out to be also a little menu cleanup :)

Looks of the tabs appearing with the new patch:

The bug with the Configuration and modules area still not resolved. I run the query outside of Drupal and got the expected result, but for some reason, the query in this function does not return all subitems of the configuration and modules area. Very strange. I've verified that the placeholder values are the same as I run on the manual query.

SELECT m.load_functions, m.to_arg_functions, m.access_callback, m.access_arguments, m.page_callback, m.page_arguments, m.title, m.title_callback, m.title_arguments, m.type, m.description, m.path, m.weight AS router_weight, ml. * 
FROM menu_router m
LEFT JOIN menu_links ml ON m.path = ml.router_path
WHERE (ml.plid =14 AND ml.menu_name =  'management' AND hidden =0) OR (m.tab_parent =  'admin/config' AND m.type IN (136, 128))

Note that you might need to fix your plid value depending on your menu_links data. Just to repeat: this bug was here before the patch. But the same bug blocks adding the Modules tab as a sublink though.

Let's try a retest.

Subscribe

Committed to CVS HEAD. Thanks! :)

The other bug with the Configuration and modules overview lacking most items seems to have been independently resolved, so looks like we are good with this commit :) Yay.

It is unclear if you read my comment wrong, or if you are suggesting that people using the expert profile will not want to use the toolbar and Seven theme? I think most people will want to.

No. Many site builders won't use Toolbar and won't use Seven theme. A separate admin theme is old-school anyway - even Typo3 moves away from that in its next release. If your custom theme is not flexible enough for proper usage on administrative pages, then you will build a sub-theme/child theme to ensure a consistent look & feel throughout your site.

+++ modules/user/user.module	9 Sep 2009 21:55:15 -0000
@@ -1305,11 +1305,6 @@ function user_menu() {
-  $items['admin/people/list'] = array(
-    'title' => 'List',
-    'type' => MENU_DEFAULT_LOCAL_TASK,
-    'weight' => -10,
-  );

This needs to be reverted, because there will be no default tab in case other modules add tabs to admin/people.

I'm on crack. Are you, too?

@sun: where else are single default tabs added when there are no other tabs in core? I have not seen such practice before.

Can someone clarify stuff for me, as I am beign pointed to this issue from all directions. This is just a way for people who like zhe old style of Drupal, to keep zhe old style of Drupal. Correct? And to fix that, I don´t use toolbar, seven, ect ect - but I want to use Drupal.

If anyone can point me to other problems its solving please do so. Its not taking over the IA we have worked on for the last months, is it?

@Bojhan: it is just exposing a bigger part of the IA on overview screens, so that it is easier to find pages for those who'd like to keep using the "D4/6 style" overview screens.

@alexanderpas: ok, I've tested the patch and here is how it looks before and after the patch:

Before:

After:

While I agree that this makes it technically easier to add other tabs, it does make for an inconsistent user interface. Other admin pages where tabs exist show up as a list of tabs. Here when you go to the actual page, no tab exists (Drupal does not display a single default tab), so it is not consistent with other pages.

+++ modules/system/system.module	9 Sep 2009 21:55:13 -0000
@@ -1713,7 +1728,16 @@ function system_admin_menu_block($item) 
+    if ($link['type'] == MENU_DEFAULT_LOCAL_TASK) {
+      $default_task = $key;
+    }
+  }
+  if ($has_subitems) {
+    // If we've had at least one non-tab subitem, remove the link for the 
+    // default task, since that is already broken down to subitems.
+    unset($content[$default_task]);
   }

Seems like we need to count the tabs then, and also unset the default local task in case there is only one tab (the default).

I'm on crack. Are you, too?

That screenshot is pretty compelling. consistency++

This needs a re-roll for dashboard.

Committed to CVS HEAD. Thanks!