Menu local tasks/tabs not showing for admin module/theme
fenstrat - September 14, 2009 - 21:20
| Project: | Ubercart |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Description
Ubercart doesn't consistently make use of local tasks / tabs for its menu's. As a result themes that rely on local tabs for navigation are missing key menu items, like product classes, search customers, create/search orders etc.
This issue has come up before. At the time admin_menu was proposed as a solution/workaround. However d7 implements its own toolbar as an alternate/replacement for admin_menu. These ideas are available now on d6 with the admin module/theme. This new approach requires navigation through local tabs.
As more and more people start using the admin module this will become a bigger issue.
An example of a "solution" someone took by modifying the admin menu structure (taken from #513424: Ubercart, Menues not found).
#1
Attached patch makes the following menu items local tasks:
admin/store/orders
admin/store/orders/create
admin/store/orders/search
admin/store/customers
admin/store/customers/search
admin/store/products
admin/store/products/orphans
admin/store/products/classes
admin/store/products/files
I haven't touched the menu item weight's - for now they work. But they probably should be made consistent across the modules.
Also corrects colspan when no product attributes have been added.
#2
Quick screenshot of the problem.
The problem.
The solution.
#3
Hoping to get some eyes on this.
For the growing number of us using admin module to implement ideas backported from d7 this is a releast blocker.
The patch at #1 still applies cleanly to bzr revision 1980 (and rc7 afaik).
#4
The admin module is a great and I would also like to see this issue fixed.
I tested this against RC7 and it all works. I also tested it with garland enabled and nothing appears to get broken there as well, so I can't see any reason why this shouldn't be committed.
#5
For what it's worth, we actually don't want more issues tagged as Release blockers, especially cosmetic issues. I understand this is a helpful patch, and we'll test it if we can, but we're only blocking a 2.0 release for critical bugs at this point.
#6
While I agree this is not a critical issue.
This is not so much a cosmetic change has it is fix to the menu items which are not correctly setup as LOCAL_TASKS and therefore potentially will break in a number of themes - so its not just a admin module issue.
#7
This is not a cosmetic issue. Ubercart's use of menu item's is not correct.
As univate notes this will effect any number of themes which rely (correctly) on Drupal's MENU_LOCAL_TASK items.
I understand the desire to get 2.0 out the door, but it'd be a real shame to see this not included.
#8
Well, I think you're right in that it's not merely a cosmetic issue. But I don't think it's true to just say we have incorrect menu item usage, just weird. : P
Here's the reason as best as I could hash it out w/ Lyle earlier in IM... we have "landing pages" for broad categories of administrative tasks that aren't necessarily tightly related. We have a page functioning as sole default local tasks for each of these menu items, and other categorically associated pages are aligned under the landing page in the menu hierarchy for organization, not necessarily to group the tasks together into local task tabs. This works in some regards... for example, the reports section. But not in others... for example, in the orders menu, it probably wouldn't be a bad idea to organize the various menu items as local tasks, because they're all related to viewing and finding orders.
What stinks, though, is that other modules use these areas, too. Recurring fees, for example, get listed under the Orders heading and coupon management goes under customers (I think). These items definitely aren't local tasks. If we turn all the core items into local tasks, will that render these other items inaccessible or invisible? What it seems like Ubercart should've done is either use more top level categories under /admin/store with local tasks where possible or had unique landing pages for /admin/store/orders, /admin/store/products, etc. instead of the pages as they are now.
Lyle corroborated that the various items under the Products category in the store menu really aren't related. I'll reiterate, though, that just because this doesn't happen in 2.0 doesn't mean it won't happen. I just don't think it's worth holding up a long overdue release to sort this one out when the present structure has served passably well for 3 years. (Especially considering the fact that the module we want to support is still in beta itself... perhaps a fix in UC 2.1 could coordinate w/ a major release of Admin.)
#9
Thanks for the response Ryan ... we can both agree on weird menu usage!
We're turning on sites with admin module. Clients love it. Much smoother/easier admin experience. It's where d7's headed.
But turning on Ubercart = problem. Their store admin is broken. "How do I create an order?", "How do I search customers".
Pretty fundamental stuff.
I think Ubercart's menu structure is pretty sound, the top level groupings make sense. However it's been primarily built with admin_menu in mind which has a unique way to render menu's and outputs a structured menu independent of menu types. As such it doesn't care what menu type you throw at it, it'll render it. So I can't really see sense in the statement "will that render these other items inaccessible or invisible?". Other menu items will still be accessible via admin_menu and themes relying on local tabs can deal with that when the need arrises.
The issue here is Ubercart core.
I can also understand that you have to draw a line in the sand for 2.0.
ps. Ryan, congratulations to you and yours on the baby!