On 11/21/05, Larry Garfield <larry@garfieldtech.com> wrote:
Actually, I'd suggest something even easier. In 4.7, there's a menu settings fieldset for every node. First, expand that to tie to just ONE menu instead of all of them, for size reasons. Call that menu "Site Structure" (or "Navigation" <g>). Then any page that gets put into that menu automagically gets a dynamic alias (read: not stored in path_alias) of that menu location. So a node with ID 47 called "stuff" that is placed in the menu with parent:
Site Menu > mysection > mysubsection
will be accessible via both node/47 AND mysection/mysubsection/stuff.
I've played around with this idea of "dynamically constructed URLs" quite a bit in Drupal, and my conclusion, at the end of the day, is that they're more trouble than it's worth. The biggest problem is performance: the URL is parsed IN easily, because only the part after the last slash ('/') needs to be processed; but when the URL gets printed OUT (i.e. through the url() or l() function), the system has to crawl up the menu tree, from the current page through all its parents, and find the URL for each ancestor before joining them all together with slashes. This is how my own site's URL handling system works - I developed it just before pathauto came out (almost a year ago!) - you can read all about it in my article: http://www.greenash.net.au/posts/thoughts/hierarchical_url_aliasing The above URL is an example that shows the performance problems I was just talking about. Another problem is unique URLs: with constructed URLs, every part of the URL (where a 'part' is the bit between each slash) has to be unique for every URL on the site - this problem can be avoided, but only with even more sacrifice in performance. Basically, I consider my approach of constructing URLs by walking up the menu tree to be the wrong approach, particularly if performance is critical and the site has many nodes. Despite seeming 'less right' (IMO), the pathauto approach of static aliases is simpler and scales better. It also fits in with the current core system, whereas my approach requires patching the core in order to work. Although I'm a huge fan of pathauto, and of Drupal's support for configurable URLs in general, I don't think that pathauto belongs in core. I also don't agree with the idea that users should never see a node ID: this is like saying that book readers should never see an ISBN, or that people who buy electronics should never see the model number. Like these things, a node ID is sometimes useful, even for an end user; but also like these things, a node ID should be made as inconspicuous as possible, and it should still be there for users that look for it. Rather than moving pathauto to core, I'd like to keep in the spirit of Adrian's "API fever", and suggest that a "path API" would be a better alternative for core. This would allow more advanced features, such as overriding path aliases, bringing back the conf_url_rewrite() type functionality (or has it never left?), etc. Jaza.