[development] One core, many distributions

[Jeremy Epstein]

On 11/21/05, Larry Garfield <larry at 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.