Hierarchical URL aliasing patch available

By Jaza on 15 Feb 2005 at 03:53 UTC

After hacking my own site to death, I have gathered together all the code and documentation needed to implement a hierarchical URL aliasing system. This patch parses a site's taxonomy hierarchy, and based on that, it automatically generates hierarchical aliases. For example, the ('q' part of the) URL of this page would be something like forum/general/discussion/hierarchical_aliasing_patch.

The patch works beautifully on my site, and should be able to be implemented on any 4.5.x system that has the taxonomy and taxonomy_context modules enabled. It does not support book hierarchies, but could easily be extended to do so (however I don't use them much myself, so I haven't made this extension).

I have discussed this idea in several other forum topics around here, and from what I can tell, this is something that quite a few Drupal webmasters have been waiting for. I know it's not the world's cleanest patch, but it's there, for those of you that need it.

I have actually written a three-part tutorial on my site (explaining my ideas on patching/hacking taxonomy), and part 3 of the series is where you'll find a detailed article on the hows and whys of this patch, and is also where you can download the patch itself (part 1 and part 2 have some other patches that the hierarchical aliasing system is somewhat dependent on).

This is only a very crude patch, with no front-end admin interface, and it probably should be a separate module. Do you guys think that this has the potential, or the demand, to become a proper contributed module? Is this something that should become part of taxonomy or taxonomy_context? (or path module? or core?) I'm open to ideas and suggestions.

Jeremy Epstein - GreenAsh

Comments

It's usually best to start

Boris Mann commented 15 February 2005 at 04:09

It's usually best to start off as a contrib module, as the coding requirements are a lot less strict. This will allow any bugs to be shaken out, and valuable feedback to be given. It also gives others a chance to check it out of CVS and potentially add to it as well.

If the module proves valuable and useful to a large number of users, it may become a core module or API.

You should start by applying for a CVS account, as well as joining the Drupal developer's list (you can ask for a project to be created once you are ready).

Hope that helps -- the module does sound interesting.

looks terrific...

ramdak5000@www.drupal.org commented 4 March 2005 at 15:58

..., although I am not a coder by any stretch of imagination. This, along with the autopath module seems a boon. Do you think there is a case for combining the functions of both these?

Is there any chance of this coming as a contrib module? Just curious.

Don't know about contrib

Jaza commented 5 March 2005 at 06:36

I would like to submit this functionality as a contrib module, but as you can see, what I've got now is not a module. As I explain in the article, my patch is implemented in the bootstrap.inc and common.inc files (which are the very heart of the Drupal core) - rather than as a module or a module patch - for technical reasons...

From my article:

When a page request is given to Drupal, the core system handles the conversion of aliases to system paths, before any modules are loaded. This means that not only are alias-to-path conversions (and vice versa) handled entirely by the Drupal core; but additionally, the architecture of Drupal makes it impossible for this functionality to be controlled from within a module! Upon inspecting path.module, I was able to verify that yes, indeed, this module only handles the administration of aliases, not the actual use of them. The code that's responsible for this lies within two files - bootstrap.inc and common.inc - that together contain a fair percentage of the fundamental code comprising the Drupal core.

So I don't even know if it's possible to convert what I've got now into a module. I would probably be able to move some of the functionality into a module, but I don't see how it could work without at least a few lines of patching at the core. If there are any core developers reading this, I'd be happy to hear what you've got to say, i.e. can it be done? Can this kind of functionality be implemented cleanly (or cleaner)?

Jeremy Epstein - GreenAsh

Can't promise right now, but

ramdak5000@www.drupal.org commented 5 March 2005 at 07:18

Can't promise right now, but we are developing a site and have a programmer who's familiar with Drupal. Let me try if we can get him to convert this into a module. But, it is going to take a while.

Perhaps you should appy for the CVS account as Boris suggested (hint: he doesn't suggest this for every new idea that people come up with)

:-)

P.S: Did you notice the new layout module? Between this, your patch and the pathauto, I feel the wishes of many for hierarchical structure support in Drupal is on the way to being answered.

http://drupal.org/node/18272

CVS account

Jaza commented 6 March 2005 at 04:00

I applied for a CVS account about a week ago, still haven't heard anything from the Drupal team. Bit slow, aren't they? I sent them a "what's going on hurry up" (in nicer words than that) email yesterday, hopefully they'll approve me soon. Maybe they're still busy with post-DrupalCon work.

I actually didn't mention my aliasing patch in my CVs application, I forgot about it! I just talked about a new module I've made called taxonomy_assoc, which lets you display a node as a taxonomy term's description (by 'associating' a node with a term). Maybe they think this module doesn't sound all that useful. Anyway, still waiting...

Jeremy Epstein - GreenAsh

I'm not sure

zaur1945 commented 9 May 2005 at 17:00

I think, no, this is not good Idea for this module.
I used it on my website http://www.pdesigner.net

Jeremy, Also interested in

Carl Ditzler commented 4 March 2005 at 21:12

Jeremy, Also interested in your patches, good work and your articles are excellent/in-depth, maybe contribute to cvs?

Nice article

oNyx commented 4 March 2005 at 22:31

Thanks heaps. That's exactly the kind of thing I was looking for.

The link to the autopath module is dead btw. Did you mean pathauto?

Yes, pathauto seems to be

ramdak5000@www.drupal.org commented 5 March 2005 at 02:50

Yes, pathauto seems to be what he meant.

From pathauto's

oNyx commented 5 March 2005 at 10:02

From pathauto's readme:

This module combines the functionality of Mike Ryan's autopath with Tommy Sundstrom's path_automatic.

Well, got it all working (didn't do part2). So... pathauto seems to do pretty much the same thing.

The first function (edited in part 1) has another name now despite the fact that the download link was labeled with the same date as the one you used in your tutorial... that was a bit irritating. In part 1 you also mention that you need a second vocabulary, but it worked without a second one, too *shrug*.

In part 3 you could point out that $distantparent = FALSE; bit for those who didn't (want to) do part 2. (Just a "Note: blabla" thing).

Well, thanks again. Heh. It really helped me a lot :)

Great!

mhutch commented 14 March 2005 at 01:44

This looks fantastic, just what I've been looking for for well over a year now. However, I really wish it was a configurable module rather than a patch. Any chance of some of the 'core' people looking at this and integrating the necessary changes into core? This post seems to have had very few replies for something so interesting...

Ought to be in core...

lennart commented 14 March 2005 at 16:17

...In my opinion this ought to be core functionality. It would make drupal even stronger at the exact point were drupal already has an advantage compared to other php-based CMS'.

Plone, which is on the Zope platform, allready has this, and it gives a - well-deserved - sense of professionality.

Thanks for the great work Jeremy - also the tutorials are very well written!

Best regards,
Lennart

About Plone

Jaza commented 15 March 2005 at 12:13

I really should mention that I, too, am aware that Plone already has this functionality. In fact, Plone is the first and the only CMS on which I have seen hierarchical aliasing functionality implemented as part of the default system; although it wasn't Plone that gave me the idea, it was the legendary website A List Apart, which both uses hierarchical URLs and has an excellent article on how/why you should implement them.

Plone is great, but unfortunately for me (and for many others) it's not only way too complex, but also built upon a custom web server and framework using Python. As with many users, I need a CMS that follows the more common LAMP model. Drupal has the cleanest URLs of any LAMP CMS I've checked out, and I've checked out quite a few. Mambo offers some competition, but it only allows very basic clean URLs (they still have the page ID, etc), whereas Drupal offers totally user-defined aliasing.

I also feel I should explain why hierarchical aliasing works so well in Plone, and why it's so much harder to achieve in Drupal. Plone follows a totally different model for how content is stored and organised in the system. In Plone, content consists of 'pages', which are really quite similar to files on a PC, such as Word documents or static HTML pages. These pages can be organised into 'folders' (also like a PC file system), and are browsed hierarchically.

In Drupal, it's totally different. Instead of pages, we have nodes, which are stored independently of, and are independent to, the structure of one's site. Taxonomy terms can be applied to nodes, but as we know, one node can have many classifications. So whereas in Plone there is an inherent basic tree hierarchy in the site, in Drupal the site structure can be (and often is) not this simple. By the way, feel free to correct me if any of my Plone explanations are wrong: I have a fair level of expertise with Drupal, but none with Plone!

So this is why Drupal doesn't support hierarchical aliasing (without my complex patch): because it's not hierarchical in nature! And seeing that this is a strength and a key benefit of Drupal, I don't see this functionality getting into core any time soon (assuming that me or anyone else is able to get it up to core standards anyway, that is).

Jeremy Epstein - GreenAsh

Some of it should be in core...

mhutch commented 15 March 2005 at 20:57

And seeing that this is a strength and a key benefit of Drupal, I don't see this functionality getting into core any time soon (assuming that me or anyone else is able to get it up to core standards anyway, that is).

True, any front-end to this should be in a contrib module, possibly part of taxonomy_context, but it would be nice if the core did not have to be patched. If it's not possible do this without core patching, the API definately needs extending.

Any comment from the core team?

I agree

lennart commented 16 March 2005 at 02:43

The optimal solution, as far as I am concerned, would be an option in the administer settings where this could be choosen. Sort of like with the choice now present for enabling clean URL's

Best regards,
Lennart

nod nod

oNyx commented 16 March 2005 at 04:51

Enabling and disabling of custom blocks would be also much nicer then (that was actually my primary reason for using that patch).

Long term solution

Jaza commented 16 March 2005 at 11:41

An idea came to me just now, in the light of all the recent discussion on this thread regarding getting this patch into core. In my opinion, a huge stumbling block to making this a proper module (let alone part of core) is that the bulk of the code is concerned specifically with how to construct aliases to tailor-suit a whole lot of different node types. A lot of these node types aren't even part of core, they're from contributed modules (e.g. weblink, image) - and expecting users to have all these other modules is really the sign of an amateur patch.

What would be better, as a long-term solution, would be instead to have a hook (perhaps call it _alias?), that other node types could then implement, to define how their hierarchical aliases are to be constructed. This would make the actual code in the patch/module smaller and more maintainable, and would also make the whole system easier to extend. Feedback on this idea is, of course, welcome.

Jeremy Epstein - GreenAsh