- Have you ever wondered why, after defining an alias like about-us for, say, node/123, your pages are still riddled with those ugly machine-generated tabs and links like /node/123/edit, node/123/revisions etc.?
- Likewise for /taxonomy/term/% and /user/% links: did you expect to see /dries/track but got /user/5/track?
- Do you find that your browser address bar also shows those ugly numbers instead of your aliases?
- Have you ever been annoyed that upon clicking the Edit tab on, say, the about-us page, blocks that you configured to be visible on all about-us/* pages suddenly disappear?
- In short, would you like your human-readable, SEO-friendly aliases to be carried through on all your tabs, links, Views, and blocks, on all your pages, not just on that single aliased base path?
If so, then this little module is for you.
Extended Path Aliases finishes the job left incomplete by core's Path module, fixing all of the above. And it does so automatically, without any configuration options or permissions to set and without requiring any other modules. Just install and you're away.
The module was born out of a feature request Sub-path URL Aliases would also have to be implemented. This explains the partial overlap in functionality between the two modules. However, Sub-path URL Aliases (D6) or Sub-pathauto (D7) do not implement the function mentioned in the 4th bullet point above.. In realising this feature it became clear that functionality similar to
Extended Path Aliases is meant to continue to work well when used in combination with related modules, such as PathAuto (recommended), Domain Access, Path Redirect, Global Redirect and similar. Let us know if it doesn't!
The functionality described in the first three bullet points in the introduction will work as soon as you enable this module. However, if you want to go over and beyond what Sub-path URL Aliases & Sub-pathauto do and also include the feature mentioned in the 4th bullet point, then you have to do one more thing. Either:
- insert a statement in file include/path.inc or
- install the PECL runkit library, compiled for your OS
Both options are described in detail in the as described in detail in the README file included with the module,
The approach of the first bullet point is simple and reliable. However it means that when you install a new version of Drupal core in the future, you'll have to remember to insert that line again, as the install will clobber your change.
The second bullet point is slightly more elaborate, but is a one-off, as future core installs will have no adverse effect. We're appealing to developers to share their OS-specific compilations of PECL runkit libraries. If not present already, please attach your copy to this issue, , so that more people in the community can enjoy the proper runkit for their system without having to compile it first.
Note for D6 only: in D6 you may run into trouble when trying to enable this module in combination with the one or two modules out in Drupal-land that also implement
custom_url_rewrite_inbound(). An example is Drupal for Facebook. Workarounds may be possible -- happy to discuss. Or switch to D7.
Q: My extended aliases for system paths of the form /user/123 don't seem to be generated. How come?
A: Are you sure a base alias exists for user/123? Check at the admin/config/search/path page (D7). Then either create user aliases by hand or have them bulk-generated for all your user accounts. The latter requires Pathauto. After enabling that module visit the Automated alias settings (D6) or Bulk update (D7) tab on the URL aliases admin page.
Q: After I created an alias such as "MyAccount" for the system path "user" I noticed that a logged-in user's "My account" tabs/links do not show their user id or name, i.e. when user 456 is logged in, the Edit tab (user/456/edit) displays as "MyAccount/edit".
A: Yes, nice isn't it? In D7 you can switch this feature on/off at the module's configuration page, admin/config/system/path_alias_xt.