Namespace local tasks that we don't necessarily control

Looking over it it seems fine, but I'm curious if you've had this patch running and tested on a local install. i.e. actually clicking through to all the various affected pages to make sure we got it all covered.

So... I don't actually want to change top level paths like cart/*. There's no good reason for someone to have another shopping cart module on an Ubercart store, and this just doesn't look good/will screw with existing contribs in unknown ways. So... -1 to the last patch.

Just to go back to the original scope of this issue, it's for local tasks... meaning tabs on things defined by other modules, like nodes and users. We want to make sure our modules aren't conflicting on these things where other modules might also be adding tabs. Anything that's an Ubercart object or path doesn't need to be modified. People wanting to write modules interacting with Ubercart can work around its existing paths.

Looks good to me. Don't forget to clear your menu cache, at least.

Committed.

This patch was incomplete. In particular, in uc_order, the path user/#/orders was changed to user/#/uc-orders, but the paths starting with user/#/order (e.g. user/#/order/# and user/#/order/#/invoice) were NOT changed to user/#/uc-order.

I examined the menu_router table on my site and didn't notice any other paths that need a uc- qualification, but I don't have all the core Ubercart modules enabled so I can't say for sure that I caught everything.

In your opinion, do you think it would be better to go through and change all those or just revert uc-orders to orders? I don't know that I even remembered we had changed it to uc-orders, even though my comment above seems to indicate that's what I was expecting. : )

In a perfect world, I wouldn't want to see uc-orders appear in the first place. I don't think that URLs visible to the customer should contain uc- or other idiosyncrasies of the underlying implementation. The user knows what user/#/orders means, but user/#/uc-orders looks strange and might require you to explain to your customers (or your clients, if you're setting up a site for someone else) what the uc- is doing in there. They shouldn't have to or need to know.

However, I recognize WHY the change was made in the first place. Namely, the Menu API doesn't have any way to check on or prevent modules from making conflicting uses of a namespace. Thus for Ubercart to be relatively safe from menu path conflicts Ubercart should make an effort to use non-generic terms like "uc-orders" instead of just "orders" whenever Ubercart defines a sub-menu underneath some non-Ubercart path.

The use case that motivated the original change was node/#/edit/stock being claimed by both uc_stock and webforms. I don't know if this is really webforms, or this is just some name choice made by the admin when creating a webform. If the latter, I would classify it as a mistake by that admin, although the conflict really should be caught and indicated by the Menu API. If the former, then yes, we have a problem, because then webforms and Ubercart won't work together.

I think changing node/#/edit/stock to node/#/edit/uc-stock was reasonable, because the only people seeing these URLs are the people with permissions to edit these nodes. By definition, those people might need to have some idea of the underlying implementation, and the renaming is never seen by the customer. Although maybe product-stock might have been better than uc-stock, but I don't really care...

Likewise the admin/store tree is "owned" by Ubercart, so it wasn't changed. And although there is some small potential that another non-Ubercart module will come along and want to use the term "store", I agree there's no need to change this to "uc-store" to ensure its uniqueness.

I think user/#/orders should not have been changed to user/#/uc-orders, despite the small potential to conflict with other modules that use the user/ menu tree, mainly for the reason I stated in my first paragraph. BUT if the consensus IS to leave it as user/#/uc-orders, I think that user/#/order (without a trailing 's') should also be changed to user/#/uc-order. Not only for consistency but also because user/#/order has the exact same potential to conflict with other modules as user/#/orders. I don't see it as a real big deal either way, just apply the same reasoning to both, whatever you do!

I'm of the opinion that adding uc- to the paths was a mistake. The original problem was caused by uc_stock adding its tab to all nodes, not just products. We just didn't realize it until recently. Now that this has been fixed, I think we should go back to the way it used to be.

Heh. Forgot I committed this.