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).
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 577384_local_menu.patch | 4.01 KB | fenstrat |
Comments
Comment #1
fenstratAttached 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.
Comment #2
fenstratQuick screenshot of the problem.
The problem.
The solution.
Comment #3
fenstratHoping 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).
Comment #4
univate commentedThe 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.
Comment #5
rszrama commentedFor 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.
Comment #6
univate commentedWhile 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.
Comment #7
fenstratThis 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.
Comment #8
rszrama commentedWell, 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.)
Comment #9
fenstratThanks 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!
Comment #10
terbs commentedAny news on this getting fixed? The patch is no longer relevant as the line numbers have changed. Can we just get this modification made in ubercart's core? The current menu system is incorrect. This is a bug that needs to be fixed! It's been almost a year!
Comment #11
tr commented@aiquandol: Yes, it's been almost a year, and in that time no one from the community has stepped up to address rszrama's concerns from #8. And no one except univate even tested the original patch or replied to the original issue. If you think this issue is important enough, you should spend some time creating and testing a new version of the patch to fix the problem within the constraints Ryan laid out. I'm not about to commit a patch that hasn't been tested, especially when that patch involves changing a lot of the Ubercart menus thus potentially breaking a lot of other things. Keep in mind that Admin's inability to handle Ubercart's menu structure is not necessarily Ubercart's fault, unless Ubercart is doing something not allowed by the Menu API (which I don't think is the case). So while it would be nice to have Admin deal with this better, it *might* be something that has to be addressed in the Admin queue. This can only be determined if someone spends the time and effort to do the research and find out *why* there's a problem here.
Comment #12
fenstratI'd have to say this patch is still correct from the perspective of correcting how Ubercart uses the menu system.
We've since moved away from admin.module-6.x-1.x in favour of the back ported seven theme and admin_menu + admin_menu_toolbar. So I haven't looked at this for a while.
Would be interesting to know if this is still an issue in (the radically different) admin-6.x-2.x
Comment #13
kenorb commentedThe same problem.
I can't find admin/store/products/classes by looking from the menu.
Comment #14
longwaveRe-tested with admin 6.x-2.0, patch is no longer required; the menus are fully accessible from the left hand menu.