i wanted to float an idea about reorganizing the menu insanity for project module. right now, we have paths like /project/mymodule. this started a long time ago due to path aliasing, and now we create the aliases automagically.

however, these paths are under the primary arg of the project URI namespace. this has created numerous problems, like having to blacklist names for any primary path we want (ex. project/issues), and also having to resort to crazy arg processing to find out just exactly what the project module needs to do with a certain path.

so what i'd like to propose is: move all project/mymodule paths to project/view/mymodule (or overview, or whatever). to avoid link rot, we create a primary project menu item, which simply redirects to project/view. this *should* work great, because the menu system has a natural fallback system -- so that if somebody visits /project/mymodule after this change, the menu system looks for project/mymodule as a path, doesn't find it, so reverts back to /project, which then redirects to /project/view/mymodule -- phew!

the doubly great thing here is that because we've already blacklisted all the primary paths (ie, can't create a module named 'issues', etc.), the fallback scheme will always work correctly, as after this change 'issues' module would reside at project/view/issues, and it's generated links would never hit the fallback system.

the only downside i can see is that, going forward, modules that get the same name as a primary project path won't be able to make use of the above mentioned trick in terms of just typing in the URL, while all other modules will. i think that's a pretty small inconsistency to live with for all the benefit to be gained here, though.

Comments

drewish’s picture

drewish commented

i think it sounds pretty good to me. at this point i don't even think the downside you mentioned is really a problem. we just stop automagically creating paths and let those handle the redirection for existing nodes. new ones will only have the new project/view/* path.

hunmonk’s picture

hunmonk commented

we just stop automagically creating paths and let those handle the redirection for existing nodes

i'm not clear what you mean here. if i visit /project/mymodule by typing the url in, how does the menu code at /project determine if the incoming request relates to a project created after this change, as opposed to one created before this change?

the workflow i had in mind was:

  1. user visits /project/mymodule
  2. if mymodule isn't part of regular project menu path, then the callback falls back to /project with 'mymodule' as it's arg
  3. callback at /project takes the first arg, builds /project/view/mymodule, and does a drupal_goto() to that location
  4. if mymodule happens to be the 'issues' module, then the unfortunate user will end up at project/issues, not project/view/issues, because the menu code will trigger the callback at /project/issues, not /project

couple of code technicalities:

  1. if the user visits /project directly, we should sensibly redirect to some kind of summary page, or just build the summary page directly from the callback
  2. if mymodule isn't a valid project in the example above, the user will get redirected to a page not found, which is exactly what we want
pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

As I see the only problem here is the blacklist.

Thinking about the easiest fix, got a simple idea:

put any project* module specific path under /projectS/ (this path is unused on d.o.)

so the project/mymodule path could remain and you could create reserved paths also
like
projects/usage
projects/issues (or simply issue)
projects/user

projects/new
projects/top
projects/top/mostactive
projects/top/rated
and so on..

and no need for blacklist any more.
maybe I am missing something important here, I do not dive deeply into the problem..

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

The d.o. project links are used in core also. http://drupal.org/node/175876
project/Modules; project/Themes; project/Translations

so my idea to change project to projects, is not acceptable..

hunmonk’s picture

hunmonk commented
Version: x.y.z » 5.x-1.x-dev
Category: bug » task

@Pasqualle: i think you might want to re-read my posts. there is no additional base path necessary, and there will be no blacklist. the point is to move projects one layer deeper in the menu heirarchy, thus eliminating path conflicts. the /project path itself would simply be a redirect to avoid link rot.

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

@hunmonk: Yes, I understand your point. It should work without a problem, just the 2 level deep path for projects seems non-standard to me.
Checked sourceforge, mozilla, fsf, apache, eclipse sites. They use /projects, /products, /software as path (except clipse), no second level.

But /project/Modules/mymodule; /project/Themes/mytheme and project/Translations/mytranslation as path seems right to me now, it has some logic. I think /view/ as the unnecessary path segment bothers me most..

hunmonk’s picture

hunmonk commented

@Pasqualle: i really don't care what the second level path label is. it could be /project/whoopee/mymodule for all i care ;)

what i care about most is getting the project names off of the primary path for project module -- only project-generated paths should go there (/project/issues, /project/usage, etc.)

dww’s picture

dww
we/he/they
commented

FWIW, I kinda like /project/[project-type]/[project-name]. However, I *hate* the fact that [project-type] is capitalizied due to taxonomy stuff, so if we go that route, I think I'd like to fix the URLs for those somehow (in another issue).

However, then you have the problem that you can't have top-level project taxonomy terms that match any of project's reserved words. So, it's a much smaller namespace collision problem, but it's still a namespace collision problem. :( This is true of the project browsing pages, anyway, so it's not like it'd be new if we put the projects there, too.

I'd love to see this problem fixed, but I don't have any great ideas right now (and shouldn't be thinking about Drupal at this moment, anyway)...

moshe weitzman’s picture

moshe weitzman commented

hunmonk - what Pasqualle is suggesting that you leave the hundreds of project urls alone and instead move project module's internal urls from project/usage to projects/usage (for example). all of this is a minor point, but it comes down to an optimization question. i think hunmonk's plan gives preferential treatment to internal project URLS like project/usage at the expensive of user created project urls like project/og. i say preferential because those urls are shorter. i think pasquale's suggestion is better, personally.

hunmonk’s picture

hunmonk commented

@moshe: the problem with that approach, IMO, is that it's confusing, and in my mind poorly organized. it's non-intuitive to have two top level paths for the module, especially project/projects -- seems too easy to mix up which is which. while the URL to get to a project's page might be a bit longer (5 characters to be precise, if the second arg is 'view'), the overall organization will make more sense.

moshe weitzman’s picture

moshe weitzman commented

yup, that URL is confusing. hopefully the few people who care about project module understand why they get to feel the insanity ... note that we were faced with a similar issue many years ago when clean urls were invented. dries took extreme pain so that viewing a node would be node/n instead of node/view/n which would have been much easier since the nid would be automatically passed for urls like node/view/n, node/edit/n, etc. dries had to invent callback arguments and explain them (no easy task) just to assure that the urls would be as clean as possible. that may or may not be relevant, but i feel better unloading some nostalgia.

hunmonk’s picture

hunmonk commented
Assigned: hunmonk » Unassigned
avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Status: Active » Closed (outdated)

I am closing this issue, as Drupal 5 is no longer supported.