/admin should only contain categories, to enable users without toolbar.module to reach individual setting areas, currently this setting is unreachable trough the main content area.

this issue is part of #551070: [meta-issue] IA broken when toolbar.module not enabled

Files: 
CommentFileSizeAuthor
#24 show-by-module.patch938 bytesGábor Hojtsy
Passed: 12152 passes, 0 fails, 0 exceptions
[ View ]
#20 Administer.png67.68 KBGábor Hojtsy
#19 551080-admin_overview_fix.patch6.22 KBalexanderpas
Failed: Failed to apply patch.
[ View ]
#13 mockup.png41.12 KBalexanderpas
#2 admin-overview-fix.patch5.96 KBGábor Hojtsy
Failed: Failed to apply patch.
[ View ]
#2 AdministerOverview.png110.83 KBGábor Hojtsy
themes_in_appearance.patch18.8 KBalexanderpas
Failed: Failed to apply patch.
[ View ]

Comments

Status:Needs review» Needs work

Hum, why is this unreachable? It just shows up as a regular admin menu subitem on your management menu, right? If you mean the /admin page does not show this item, then it is a problem with the function generating that overview not that this is a top level item. One of the core concepts of the D7UX IA is that many important actions are moved up top. Including items like the admin/content overview and admin/people for which the same problem applies. The solution is not to obscure them under a level deeper, but to make our listing at /admin include items which are otherwise not containers. The fact that Drupal 6 enforced only containers to be at /admin does not mean Drupal 7 should continue this practice.

Title:move theme selection to /admin/appearance/theme instead of /admin/appearanceList non-container items on /admin for a complete overview
Status:Needs work» Needs review
StatusFileSize
new110.83 KB
new5.96 KB
Failed: Failed to apply patch.
[ View ]

So as said, I totally agree that not listing non-container items on /admin is a complete regression. So we should list them. So went into the system page code and also modified the Seven CSS to account for this. Before this patch, only items which have children were listed. The patch compares the callback to a list of known callbacks used for containers and lists those while other items are shown even if they have no children. If other not-known callbacks are used and have children, they are still shown with their children. The block title is reused as the clickable area and block descriptions are given.

I hope that I've identified the bug you are experiencing, so repurposing this issue with a different approach is acceptable for you.

This sounds like a good intermediate patch until we have a more advanced dashboard per #376103: Make /admin into a REAL dashboard.. It makes development easier, and it enables us to do better user testing. I haven't reviewed the code yet.

Well, I was under the impression that we would not remove this overview page as it serves as a quick overview of the admin options one has, but rather fix up some of its deficiencies it got while we implemented parts of the IA.

Yes, this is what i'm talking about.

First of all, that looks just plain ugly.
- Some blocks are links, with it's header clickable, some blocks are categories with no clickable header.
- Secondly, it leaves no room for contrib to put their own items under those "pseudo-categories"

@alexanderpas: yes, the idea of the D7 IA is that modules would have three options to place their stuff:

- either add them as tabs under Content, People or Appearance (these are top level items)
- or as subitems under Structure
- or as subitems under a category at "Configuration and Modules"

These are the three places where stuff can go. The level of importance and categorization is dependent on the frequency of use and/or importance of items additionally to their relation to the given menu areas. This is how the D7 IA is structured and is reflected on the UI after this patch.

That the tabs from under Content, People and Appearance (where modules *can* put their stuff, and are supposed to do for example with People housing events, signups, etc. listings), is a different question and is handled at #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus).

@alexanderpas It is the IA strategy to not pursue the model of burying top level tasks such as Content listing and User listing. Although I agree that this proposal looks a bit funny, it exposes a critical line of thinking which is good - that it doesn't map visually well to our old /admin - should not be a concern.

The idea was to get rid of this overview because it tested badly -- over and over again. Too much information on one page. That is why it is just an interim solution, IMO.

- either add them as tabs under Content, People or Appearance (these are top level items)
@Gábor Hojtsy
well then, let's display all those tabs (including the default), as part of the category in the overview.
as a bonus, this might also fix #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus)

@Dries
It tested badly, because it was the first thing they saw, and kept hitting it when they entered /admin
A nice dashboard showing as the default local task will put this problem aside, because if they now enter this page, they are specifically looking for it. (did /admin/by-module get tested?)

As an interim solution (pending dashboard, and not the primary location to access these links) I don't have a problem with the two different treatments on this page and I think the ability to link to the non-container items is sufficiency critical as to counter any 'consistency in presentation' arguments.

I have one small suggestion which is to move appearance under the other 'single' items (content & people) - I think this will enhance the scan-ability of the page by keeping the 'singles' together and pulling Config up the page just a little.

I'm also assuming that Site Config will be switched to Configuration & Modules with subsections for Configuration and Modules beneath it?

@leisa: Yes, "Site configuration" subitems are being categorized and moved under "Configuration and modules", this is in progress.

I think we have a solution here:
all /admin/item/tabs (including the default local task) should be listed on /admin/by-task and be grouped by /admin/item (just like, and in addition to /admin/category/item grouped by /admin/category)

This probaly solves most of the problems IA is currently causing with /admin/by-task (anyone willing to create that patch?)

Status:Needs review» Needs work
StatusFileSize
new41.12 KB

and here is an image of what i mean by showing the local tasks of the categories also on /admin/by-task

so... the /admin/by-task page lists the following in each category.
- the default local task of the category itself (on the top, if availble),
- other local tasks (below the default.)
- Sub-items (like it does now, usually not together with the above two, except some exceptions (Configuration & Modules))

Mockup:
mockup.png
As you can see, everything will be reachable again, and the IA is kept intact.
anyone able and willing to create a patch for this? please?

(do take note of the discussion in #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus))

Status:Needs work» Needs review

@alexanderpas: Since you've opened #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus) for that specific issue already, why not solve it there and let this get committed first?

+1 for the mockup in #13. we need a page like this. it is ok to move it away if /admin becomes a dashboard. but please link it from the top toolbar as it is an important page. if it isn't in the top toolbar, then we are expecting admins to keep our whole link IA in their heads (e.g. "Is Content types in Content or in Structure")

@moshe: Agreed. So let's first fix the non-displaying parent items and then go to fix the tabs not showing. Reviews of the patch above are welcome!

Status:Needs review» Reviewed & tested by the community

@Gábor Hojtsy
I agree, the patch in #2 is an acceptable interim solution, RTBC.
my complaints from #5 should be fixed in #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus), and the design from #13 will be a guide for that!

Status:Reviewed & tested by the community» Needs work

I don't want to get too bent out of shape about an interim patch, but could we please make the change suggested by leisa at #10 and stick appearance in with the other 'collapsed' items? It currently looks like a bug.

Move Appearance

Status:Needs work» Needs review
StatusFileSize
new6.22 KB
Failed: Failed to apply patch.
[ View ]

here you go webchick ;)

could've made it faster ;) but mobile development machine (eeePC)was having overheating problems due to heatwave-like temperatures over here.

Status:Needs review» Reviewed & tested by the community
StatusFileSize
new67.68 KB

Confirmed that it works. I was afraid that it would require re-weighting the items, and that would have affected the items in the menu itself as well. Look like it was not required. Cool.

Status:Reviewed & tested by the community» Fixed

Great. Committed to HEAD! Thanks!

When I try to visit dh/admin/by-module I'm getting a bunch of warnings and nothings coming up:
# Notice: Undefined index: show in theme_admin_block() (line 1958 of /Users/amorton/Sites/dh/modules/system/system.admin.inc).
It seems like that line was touched by this patch.

Status:Fixed» Active

Status:Active» Needs review
StatusFileSize
new938 bytes
Passed: 12152 passes, 0 fails, 0 exceptions
[ View ]

@drewish: you are right. The by module page blocks did not have the new show flag. This page adds that flag and also changes to empty() to avoid such notices (although it just helped figure out this bug quickly). Let's get this in.

Status:Needs review» Reviewed & tested by the community

Status:Reviewed & tested by the community» Fixed

Committed to CVS HEAD. Thanks.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

This caused a regression in system_admin_menu_block() - categories with no valid menu children are now shown on the admin/config page - see David Rothstein's example in http://drupal.org/node/591682#comment-2204124

Please roll back. According to Dries this was only an interim solution until the dashboard was in, and it's in now. Either that, or correct it so that we have separate functions for admin/config and /admin/by-task - which wouldn't be particularly hard.

Status:Active» Closed (fixed)

1) #296693: Hide empty admin categories fixes the underlying menu system issue.

2) #618530: System module's "listing" pages (and blocks) should use menu_build_tree() is where we can remove all of those system_admin_menu* functions and rewrite the remaining function into 3 lines.