Collision between subscribe to issues menu paths and subscribe project alias

this is really a bug in the project module, not the fault of the "subscribe" module for having chosen a name that happens to be one of the keywords used by the project module for various menus and pages. so, i'm moving this issue to the right place. also, this would be a problem for any of the following keywords that are currently used for project menu items:

• user
• search
• statistics
• subscribe
• add

here are 3 proposals, none of which make me very happy:

1. currently, for the main subscription page, we use [site]/project/issues/subscribe and for project-specific subscription pages, we use [site]/project/issues/subscribe/[project_name]. instead, let's use: [site]/project/subscribe/issues for the main page, and [site]/project/subscribe/issues/[project_name] for the per-project one. we'd have to do the same thing with all the other keywords i mentioned above. however, then none of these would be grouped under a single "issues" menu item, like you get in the navigation bar now, which sucks since they really are related and sub-tasks under dealing with issues. in fact, at one point i spent a little while trying to make most of these subtabs, instead of just separate pages with their own links. for them to be subtabs, they'd HAVE to be menu items under a common parent item ([site]/project/issues), so going this route would basically prohibit that from ever working...
2. move the default issue query/view page, what's currently [site]/project/issues/[project_name], to be [site]/project/issues/view/[project_name]. this would solve the name collisions with the reserved words, and would allow everything to remain a happy menu tree, but would break TONS of links, bookmarks, and existing practice. :(
3. add a validation check in the project edit/add page to prevent project names from using any of the above listed-keywords. so, you couldn't have a contrib module named "subscribe" or "statistics", and any modules currently named that would have to be renamed. this, too, sucks for all sorts of reasons.

given those 3 choices, i think #1 is the least evil, but still not great. if anyone has a better idea, i'd LOVE to hear it.

thanks,
-derek

p.s. as a work-around to view the issues for the subscribe module, just do this:
- goto http://drupal.org/project/issues/
- select "subscribe" in the drop-down box for "project"

4) Fix all the links so that project/ is always an actual project, and that project internal URLs have some other base URL such as admin/project or project_admin or proj or padmin or somethiing along those lines.

4) Fix all the links so that project/ is always an actual project, and that project internal URLs have some other base URL such as admin/project or project_admin or proj or padmin or somethiing along those lines.

after a brief discussion on IRC, we concluded there's no real solution in the #4 proposed by merlin...

merlinofchaos_: The idea is that if the URL is project/<term>/foo <term> is always a project.
Derek: so where do project issues live?
merlinofchaos_: In project/issues/view/<term> for examp
merlinofchaos_: gr
merlinofchaos_: issues could live in something like project/<term>/issues or some such
Derek: sorry if i'm being jetlagged/dumb, but i don't understand what's different about your proposal.
merlinofchaos_: I don't have a good plan for actually how to rearrange
merlinofchaos_: What's different is that if <term> is *always* a project, then you won't have the URLs bouncing on each other.
Derek: well, a) we still have global pages, that don't have a project in the URL.
Derek: and b) the real problem is what i address with #2...
•: merlinofchaos_ waves his hands
merlinofchaos_: Was just throwing out a possibility, I'm not quite with-it enough to have actually analyzed it

so, i think merlin's suggestion is basically a +1 for the #2 proposal i made above... merlin, please clarify if you disagree with this assessment. thanks.

quick hack solution. just add [site]/project/issues/view/[project_name] as a valid alternative to [site]/project/issues/[project_name]. so,

http://drupal.org/project/issues/subscribe will still give the global issue subscription page, but at least http://drupal.org/project/issues/view/subscribe will give you the issue queue for the "subscribe" module...

not ideal, but better than nothing. i could also change the default link to the issue queue from the project pages to use the "view" version of the URL, but i didn't want to do that in this initial patch.

not fix-related, but the issues for subscribe can of course be accessed using the project nid:
http://drupal.org/project/issues/29077

This just changes all project/issues/subscribe links to project/issues/mail-subscribe to avoid conflicts. Should be fine since module shortnames should only have underscores, no dashes (haven't confirmed this though). This patch is for the 2.x-dev branch. Also, it included the expanded
-// $Name: $
+// $Name: DRUPAL-4-7--2 $

but I manually removed that. Is it okay to leave that in for future reference or is there a diff option to ignore that?

a quick SQL query on d.o yields 13 projects with '-' in the short-name:

• zh-hant
• pt-br
• zh-hans
• drupal-pot
• swish-e
• pt-pt
• bluemarine-phptemplate
• Drupal-fa
• email-feedback-form
• translate-drupal-ad
• sharepoint-like
• manage-theme
• niftycorners-module

some of these are probably bogus values that don't match the directory names in cvs. others (e.g. the pt-pt (portugese translation (portugal, not brasil)) are certainly valid.

however, it's not clear that it matters, and certainly none are called "mail-subscribe" or "subscribe-mail", etc. ;)

i still need to think about this a little more before i commit (and test it), but i guess something like this is ok.

Patch re-rolled against HEAD. Look okay?

I think it's a good idea =)

a) this patch breaks issue subscription entirely, since we need to fix the 'subscribe' case in project_issue_page() to handle the new URL (whatever it ends up being). i positively *HATE* project_issue_page(), but fixing that and reorganizing all this code is a much bigger problem i have no time for now.

b) "subscribe-mail" seems slightly nicer than "mail-subscribe".

i'll just fix locally and commit, i guess. no sense someone else re-rolling...

committed to HEAD and installed on d.o. not backporting, since this is only really an issue for d.o.

Regression? I had opened a new issue for this #362091: Broken links for "Subscribe"-module (searched for existing ones first but seem to have missed this one). In any case, this problem seems to re-occur on d.o.