Differences from Sub-path URL Aliases module?

Bullet points hey...

• As mentioned on the project page this module was born out of a need to allow users to employ aliases when specifying pages to include/exclude, in particular for Block visibility (other example: Smart menus, Smart tabs). For instance "about-us*" instead of "node/123/edit", "node/123/revisions" etc. "Subpath URL aliases" doesn't do that (it probably wasn't meant to). See #683546: Doesnt seem to work with blocks
• "Subpath URL aliases" does NOT show subpath/extended aliases wherever a module calls drupal_get_path_alias(), for instance in the Statistics module top 10 URLs or contributed modules
• It also seems to get confused when the URL for a menu option or a view starts with a node alias. See #570670: Subpath Alias breaks Views and Devel
• Subpath aliases requires the URL_alter module. I wanted to keep Extended Path Aliases as lean as possible with no dependencies.

Hope that answers your question.

BTW, the reason sub-path URL alias has a dependency on URL alter is because *only one* module can declare custom_url_rewrite functions. If people want to use Facebook or Domain access with this module they will not be able to. I'd strongly consider checking out the URL alter module and depending on it. The good news is this functionality was changed into a proper hook for Drupal 7.

Yep that was a consideration. And depending on further feedback I may decide to go down that errh.... path...
Will list this as a caveat.
Agree that this pair of custom_url_rewrite functions was ill-conceived in core D6, and great that we have the URL_alter module to bridge that gap until D7 arrives, with a pair of alternate hooks to use in D6.

Actually I have just removed the reliance on custom_url_rewrite_outbound, so the module should now work with Domain Access. Will investigate Facebook.

Do the two modules play nice together? I am asking because I already use Sub-path URL Aliases.

If I decide to start using this, is there any reason I'd want to keep Sub-path URL Aliases installed? I mean, is there any feature that Sub-path URL Aliases has that this module doesn't already implement?

They won't play nice together. Use one or the other. I don't believe Sub-path URL Aliases can be used when you want to use extended aliases to specify pages to include/exclude for instance for block visibility. See also the points in comment #2.

Is the price of not being dependent on sub-path URL alias hacking core?

@ManyNancy

No, as explained on the project page, Extended Path Aliases original raison d'etre is different from Sub-path URL aliases.
Becoming dependent on Sub-path URL would not have solved what the client needed solved.
The only way I saw and still can see to implement what Extended Path Aliases set to do is by either:
a) hack core as described -- it's only one line
b) do not touch core, use the PECL runkit library instead.
Both options work fine. Pick the one that suits you best.

I may be missing something here, but is the point of this module to duplicate the functionality of Sub-path URL Aliases, but without reliance on URL Alter.
I understand that Sub-path URL Aliases has missing functionality, but I don't understand how that merited the creation of a separate module.

I only ask because I'm not sure which module to use anymore. My instinct is to work out the bugs in Sub-path URL Aliases, but if this is a better implementation, maybe users of Sub-path URL Aliases should switch.

Hi Tim,
No the point of Extended path aliases is NOT to duplicate Sub-path URL Aliases -- if that was the case I would not have developed it.
Extended path aliases originated from a different requirement, as mentioned in comment #2 of this thread and on the project page.
In implementing this requirement it was necessary to also implement most of the functionality of Sub-path Aliases.
Rik

Sorry, I didn't meant to insinuate that you intended to duplicate a module.

I guess my question is really this:
What features does Extended Path Alias implement that are not present in Sub-path URL Aliases, and which features of Sub-path URL Aliases are not replicated by Extended Path Alias?

I think the answer to that question should be on the project pages of both modules, to make it clear which module to use in which situation, since their functionality is now so similar.

Hi Tim,
I can't speak for the author of Subpath URL Aliases. As far as the features of Extended Path Alias in contrast to Subpath URL Aliases see comment #2 of this thread as well as the Extended Path aliases project page.
Rik

@RdeBoer, thank you for this great module. I just installed it yesterday to see if it would fix a problem I was having with Sub-Path URL Aliases/URL Alter. And voila! It worked perfectly. I am posting this just in case it may help others.

We are developing a site using Organic Groups. There are 4 content types designated as group type nodes, and 5 content types designated as standard group posts. We're also using Views to create tabbed group pages. So, for GroupTypeA (e.g., organization), there's a tab for GroupPostA (e.g., discussions), GroupPostB (e.g., documents), etc. The GroupPostA (discussion) tab is a view list of all nodes (discussions) for GroupTypeA (organization).

The problem I ran into is that when I visited a group and clicked from tab-to-tab, the URL for each tab kept switching between the URL alias and the real path. So using my example above, if I was on Organization A's pages, the URL for the "discussions" tab would switch between node/node-id/discussions (real path) and org/group-id/org-name/discussions (aliased path). This behavior was consistent for all Views tabs for all group types and group posts.

When I researched the issue, it seems that others have experienced problems using Views with Sub-Path URL Aliases as well. For some, the issue was related to the Global Redirect module, which we're not using (yet). Long story short: I uninstalled Sub-path URL Aliases and URL Alter first (to avoid WSOD), then installed Extended Path Aliases. Everything is working beautifully so far. More testing today.

@rhymeswithcamera, #16:
Thanks for the feedback! Great to hear it's all working for you.

my two cents:

I read the project page and comment #2 and still don't understand what actually makes them different.

Reliance on url_alter is a feature of subpath_alias and it's a limitation of this module to not be able to play well with other similar modules.

The bugs in subpath_alias are not a reason to duplicate but a reason to...patch subpath_alias.

Hi Greggles,

Thanks for the 2 cents -- that's more than I got for most of my other modules ;-)

I'm sorry my project page and comment #2 in this trail aren't clear to you, as I can't say it much clearer, but I'll try. The first bullet point of comment #2 describes the customer's requirement at the time and the raison d'etre for this module, which was and still is not available in any module, as far as I know.

You can patch SubPath URL Aliases as much as you like, but you won't get all of the functionality of Extended Path Aliases, because it requires a patch of core, as acknowledged by the maintainer of SubPath URL Aliases, the mighty Dave Reid on his project page for Sub-pathauto (http://drupal.org/project/subpathauto), the D7 version of SubPath URL Aliases.

What SubPathURL Aliases and Sub-pathauto do is pass the bug to core to be fixed (see Sub-pathauto project page). What Extended Path Aliases does is give the user a low-impact opportunity to still have the functionality of comment #2 bullet 1, if they want it, be it via a one-line patch of a core-file or by using a PECL library.

An other difference is that internally SubPath URL Aliases uses direct SQL calls, whereas Extended Path Aliases adheres to the core API.

What the D7 versions of both modules have in common is that the custom_url_rewrite issue has gone away from D7 core, so neither require something like the URL Alter module.

A final difference is that the D7 version of Extended Path Aliases came out in February, while Sub-pathauto wasn't released until August.

Hope this clarifies things a bit.

Rik

The first bullet point of comment #2 describes the customer's requirement at the time and the raison d'etre for this module, which was and still is not available in any module, as far as I know.

But there's an issue about it and that issue is "needs more info" and you never provided info or offered a patch. If that's the biggest difference you should have worked to "fix" that issue (IMO).

because it requires a patch of core

I don't see that - can you point it out?

because it requires a patch of core

I don't see that - can you point it out?

I already did, in #19. As I said there it is mentioned on this project page http://drupal.org/project/subpathauto

#1248626: drupal_get_path_alias() does not invoke url alter hook while drupal_get_normal_path() does