Increase Max Router Parts

no testing needed, really.

In D6 chx and I limited this to 7 based on possible performance concerns.

No performance issues have materialized, especially since we added the menu masks feature to mitigate the worry.

catch, chx, and I discussed in IRC. Catch has not seen the relevant query in menu_get_item() as a problem in any tests, and since we only return 1 router item, regardless, there is not much data being transferred.

subscribing.

Is there any reason for bumping only by 1? Would it not make more sense, assuming now that performance isn't an issue as @pwolanin said, to bump it further to reduce further the chances of running into this as a limitation later? Say to 15?

Happy to apply this patch but admin/settings/image-styles/edit/thumbnail_square/effects/1/delete is pretty darn long and ugly. We can talk about that in the other issue.

Committed to CVS HEAD. Thanks.

@wretched - The potential performance impact is exponential in the # of parts - we went from O(2^7) to O(2^8) - i.e. 128 to 256.

In any case we currently only support links w/ a depth of 9, so we'd have to be considering schema changes and the impact of those to go higher. In any case - a path with 8 parts is pretty darn long.

restoring the component

Thanks for that explaination pwolanin

While trying to work on #550228: Configuration page: Media category I saw, I needed 1 more! This patch is just there to go in when required by the other which still needs consensus.

admin/config/media/image-styles/edit/thumbnail_square/effects/1/delete.

I've seen no problems with the IN() query which this affects when looking through things, so I don't see a problem increasing this.

Hmm, this is a little iffy to me - if you need 9 parts, I think you IA needs work...

False alarm.

I was wrong. But I'm opposed to increase further.

quicksketch wants to reduce the path depth for image styles when #492834: Hover operations for flooded state screens is available, that seems unlikely in the next two weeks. I agree it's a ridiculously deep path.

Well, if admin/config/media/image-styles/edit/thumbnail_square/effects/1/delete is too long, then what of that would go? I mean Drupal has two traditions which result in this path:

- URL "hackery", so you can go to the URL by reading out the main section of where you are on the UI: Administration >> Configuration and modules >> Media >> Image styles
- Drupal has this tradition to include as much as possible in the path, so you can direct links, etc. to that and get a confirm form, which in this case results in edit/tumbnail_squaren/effects/1/delete.

I'd argue that the 'edit' subpath has the less use in here, since if you look at other core items they don't have edit in the path in any case, when you delete menu items, taxonomy terms or whatever, eg. "admin/structure/block/delete/1".

So on what's up with admin/config/media/image-styles/edit/thumbnail_square/effects/1/delete, core does the following:

- for menus, admin root is at admin/structure/menu, add an item at admin/structure/menu/add, manage existing ones at admin/structure/menu-customize/%menu_name/*
- for content types, root is at admin/structure/types add is at admin/structure/types/add and customization is at /admin/structure/node-type/article

Others like blocks and taxonomy do not follow this pattern. However, this "alternate path for entity editing" pattern was introduced so that arbitrary named items can be included in the path. Image styles seem to try to add a sublevel to overcome this issue, while core adds a sibling level to do that for content types and menus. Why not apply the same pattern? That would cut down on path length and use the same solution for the same problem applied elsewhere in core.

+1 for quicksketch's reasonings in #19

Especially loosing breadcrumbs is totally annoying.

Additionally, when even a core module manages to cross the limit, then there is a good chance that many contrib modules will do equally. So I'm not sure whether I'm still opposed to increase further.

Ok, let's increase further then.

why would

admin/config/media/image-styles/edit/thumbnail_square/effects/1/delete

which must be a callback path, not be equally sensible as

admin/config/media/image-styles/delete/thumbnail_square/effects/1

Also, why are we throwing the extra "media" part in there?

Current D7 has admin/settings/image-styles

The "effects" part is the path is not very meaningful - you could also equally well use

admin/config/image-styles/edit/thumbnail_square/1

I'm still resisting this, since I think the depths you have to dive into the admin. Also, the seven theme seems to omit breadcrumbs, so apparently we don't even care?

Also, the seven theme seems to omit breadcrumbs, so apparently we don't even care?

You are treating a bug as an intended feature. ;)

When moving from:

admin/config/media/image-styles/edit/thumbnail_square/effects/1/delete

to:

admin/config/media/image-styles/delete/thumbnail_square/effects/1

then we are losing the parent context:

admin/config/media/image-styles/edit/thumbnail_square

...which apparently is required to form a proper breadcrumb, because it is the parent context (the image style edit page).

True is that "effects" in that path is not necessarily required. I assume that it is there to allow to add/configure/delete further "things", aside from "effects", for an image style.

@tha_sun - well the meaningful context (imho) is that you are delaing with image styles, but anyhow, I still don't see where this new "media" part comes form or why it's needed.

@pwolanin: The reason for "media" in the path is that Drupal 7 core in itself already has a sea of links under the configuration container and not categorizing them would be a hell confusing user interface. Since the Drupal menu system does not provide any other tools for grouping items (so that they show up as "categories" when displayed in the management menu block or admin_menu or the configuration overview screen or any other tool displaying the menu) but to push them one level deep and pick a name there, we do just that. Also, this is in line with Drupal's tradition that the place you find the menu item corresponds to a path in the system, so you can easily navigate by path as well and you don't need to guess the parts of the navigation which were not reflected in the path.

More arguments over the paths at http://drupal.org/node/550228#comment-1938122 under #550228: Configuration page: Media category.

@pwolanin: the breadcrumbs issue is being discussed and hopefully resolved in #548806: No breadcrumbs in Seven. I'd say that practice showed us that the breadcrumbs are indeed missing.

Given no other objections neither here nor on the media category issue, moving back to RTBC.

I still find this rather absurd...

Any better ideas are welcome as always, but they did not surface and we are completely blocked on this one to implement ANY of the IA changes under the configuration and modules section, which is the big bulk of the admin pages.

D'oh! I'm really sorry! I thought I had committed this already. :(

Did so now. Tagging this as "revisit before release" so we can see if there's a way to trim this back once the IA is finished.

It's one thing to destroy the admin structure and make it play hide and seek with me, I am getting used this madness called "d7ux" ( I mean, since when development is "configuration and modules" ? ) but I can fix / get used that. Raising menu parts, even with the menu mask protection is not something to do lightly. I am raising this to critical bug status so we do not release without rechecking it.

i was a bit annoyed at the menu hide and seek until i realized i was being frustrated by the tabs that are hidden off to the right. after i discovered those i've found the new admin menu organization to be amazingly obvious. this is the first admin menu re-organization (since i started back in the 4.7 beta days) that i feel has been worth learning the trouble.

I've re-opened #508458: Config and modules page which added the extra path level in the first place, ideas for admin/category/mypage vs. admin/config/category/mypage vs. admin/config/mypage were put forward there, but none were less ugly than what we have in core. If we could find a nice solution though, then this wouldn't be necessary, hopefully see some of you over there.

D7UX wins over sanity. Noone cared about this issue for months so let's close it. Let's pray the menu masks hold up...

Untagging 7.x issues. On the plus side menu masks did hold up (and back in 8.x routing system finally).