Add setting to disable auto URL aliases for project nodes

looks pretty good to me. but, i'm not using my normal workstation, so i can't actually test this well right now. will take another look when i have access to my test sites again.

still haven't tested this, but i noticed a minor gripe with the code style: True should be TRUE. otherwise, this really should be RTBC.

Note also that this patch creates a new variable, but does not include code in project.install to delete the variable in hook_uninstall(). That function might not have existed when this patch was originally written, but it's there now.

The 'project' path is a normal menu item and can be disabled via the menu system.

Turned off path aliasing makes sense to me, patch attached.

Attachment	Size
project_alias.patch	2.96 KB

I could be wrong, and haven't checked the code, but it seems like we'd need some additional code in project_project_breadcrumb (or whatever that function is called), since I seem to recall that this function relies on the path of projects being /project/

Does not appear to be an issue. The attached screenshots show the output of project_project_set_breadcrumb() with the patch applied and not. The menu system recognizes the project node as part of the Project* menu hierarchy in both cases.

Attachment	Size
breadcrumb_with_alias.png	41.47 KB
breadcrumb_with_patch.png	41.2 KB

This looks good to me, but I have a few comments:

1. Do we want to wrap:

in something like:

Because if the path module isn't enabled, the setting will make no sense because aliases won't be generated anyway.

2. I fixed a code style error in the patch and reworded the title and description of the setting to be (IMO) more clear.

3. The description text for the Project short name (URI) element on the project node form is this:
"This will be used to generate a /project// URL for your project. This string is also used to generate the name of releases associated with this project."

However, if this new setting is disabled, an alias as such won't actually be created. This would also be the case in the module as it is now if the path module is disabled. Do we want to somehow change this description to be more clear? I'm not sure it's necessary, but for example if the user wanted to use pathauto to create aliases at /project/foo//, then I think the description in that field could confuse project owners.

Attachment	Size
129664_project_alias_setting_7.patch	3.35 KB

Also, what about the code in project_project_view(). $project->uri is used directly there to create links, and that's going to cause a problem if the shortname isn't aliased as expected, I believe. Setting to CNW for that reason.

Attached revision addresses the issues above, as follows:

1) Wrapped in a check, and the variable is set to FALSE if path does not exist.
2) Incorporated.
3) Fixed by adding variant text based on the setting. Also required a modification to project_release_alter_project_form().

As for the links in project_project_view(), these are not affected. $node->uri is actually the stored value of the short name from the form. These do not seem to be path aliases. Instead they are links that are interpreted by project_project_retrieve(), which accepts either the short name or the node id of the project.

Attachment	Size
129664_project_alias_settings_9.patch	4.62 KB

I'd love to get this in before 6.x-1.0 (and I'd probably be willing to commit a backport to D5 if anyone still cares). Anyone up for a re-roll?

Tagging for #439958: Document issues left before 6.x official release

Rerolled for D6 in HEAD.

Attachment	Size
129664-12.project_alias_settings.patch	5.9 KB

Committed to HEAD. I don't care enough for a backport to D5, but if anyone's interested, feel free to reopen this with a patch.

Automatically closed -- issue fixed for 2 weeks with no activity.