Thoughts on multi-hierarchy

[mindplay.dk]

Just thought I'd share an idea that has popped into my head a few times by now, while working with PW.

The purity of the central tree data-structure that powers the ProcessWire data-model, is very elegant, and for the most part works really well for me.

One instance where it does not always work well, is in terms of optimizing URLs. Most of the time, simply having items grouped under other items works quite well, but at other times, you can end up with URLs that are littered with keywords that aren't really relevant. Not great for SEO, and not always great for URLs you intend to share via various channels. (Twitter, printed material, etc.)

This happens with deeply nested menu structures in particular. On one site, I ended up with a URL like this: "/articles/some-topic/some-page/" - the keyword "articles" has no particular relevance here, it's just a logical grouping, not something you expect people to search for. And "some-topic", in this particular case, was unwanted. The client was asking for a short, user-friendly URL, e.g. "/some-page", and in order to do that, he would have to place the actual page in the root of the site, which was not appropriate in this case.

So this brings me back to an idea I've been kicking around (for my own CMS) for some years - the idea of having more than one hierarchy. Actually, an arbitrary number of user-defined hierarchies - with the ability for the user to place a given page in either one or more of these hierarchies.

I've had various versions of this idea over the years, but in the simplest version, one of these hierarchies is the designated URL hierarchy - so this would be the hierarchy ProcessWire has now.

Other hierarchies are just logical (taxonomic) hierarchies that could be used for whatever purposes you like. So as an example, "product categories" might be a dedicated arbitrary hierarchy, in which "product" pages can be organized logically, independently of the hierarchy that drives the URLs. If somebody is selling iPads, for example, you can place the product in the "product categories" hierarchy, e.g. "tablets/apple/ipad/32gb", which might determine where the product appears on a menu, but does not affect it's URL. This particular product might be placed in the URL hierarchy as simply "/apple-ipad-32gb", for example.

(maybe not the best example, as in this particular case, it might make sense to include all the keywords from the category - it's just an example.)

This problem could also be addressed, apparently, by allowing a page to be referenced more than once in the tree, or by introducing an "alias" template, so that you can "optimize" URLs by creating "aliases" for pages in the tree. Mathematically, this solution doesn't speak to me - in a real tree, a node should have precisely one parent, otherwise you introduce the potential for things like circular references or circular queries, e.g. traversals like A->B->C->A->B->C->... Or, in the case of aliases (as opposed to references), you introduce "dead" nodes from which you cannot traverse or find subpages, because the "alias" node is a leaf-node, even if the page it references has children. (otherwise, mathematically, it would be a reference and not an alias.)

Another possible solution would be to simply allow a custom URL alias for any page. This would probably be relatively simpler to implement, perhaps as simple as adding a "URL alias" text-field to templates that need it, adding a very simple module that does a query for the exact value of that text-field prior to PW doing it's normal traversal and dispatch. (This might not be great for SEO though, as you end up with two URLs for the same page.)

Clearly that's a much simpler solution than introducing multiple hierarchies, but for other reasons, the idea of multiple, user-defined hierarchies has always appealed to me. For one, it's not uncommon for the same page to appear under two different menus. As an example, on a site I'm building right now, some blog-posts double as articles that also appear organized somewhere in a category on the main menu. It's the same logical page, and it should have the same URL, regardless of whether you found it in the blog-roll or on the main menu. But because the logical and URL hierarchies are one and the same, there is no simple way to accomplish that.

Perhaps the best real-world example I can give, is a product catalog - for one company we worked with, their products were organized by two entirely different hierarchies, because their products are used in two entirely different industries. So you have two independent logical hierarchies, but the pages (and URLs) are the same.

I could provide more examples, but I think I've made my point, so I'll leave it at that.

Is multiple hierarchies a good solution, or is there another, simpler, more direct solution to these issues?

[apeisa]

This blog post and comments there might be an interest for you: http://gadgetopia.com/post/7242

My personal opinion is that 99% of times it is excellent feature to have single hierarchy (with additional metadata and relations, that allow exceptions to navigation etc). But there should be always clear understanding where the page/content actually lives.

[Adam Kiss]

I think that people spend entirely too much energy on optimizing URLs. It almost doesn't matter, after all - I feel that there is virtually no chance somebody will enter the URL manually (except the index page, maybe).

My opinion is that multiple hierarchies = bad. Simple as that.

But you have valid use-cases (or problems), so I can try to give you my opinion.

[simpler URLs (for blogposts)]

I see two options here: I'd either code the root page as a router of sorts (with rules given in case of collision), or didn't simplify the URL up to the root: domain/articles/this-is-article, or domain/topic/this-is-article, or even domain/a/this-is-article would work for me; I'd probably go with articles, because it's most logical - therefore articles will be both article router AND content holder.

[simple URLs (eshops)]

This is practically the same situtation

[Different menus]

If somebody wants to build menus manually (and I doubt that), then PW probably might not be ideal tool, but having some 'Custom-menu' tools page seems like a good solution here. And if you want your menus automatic, then I see no problem having millions of menus: if the menu is automatic, there must be a way to describe which content goes there, and then it's a simple problem of coming up with the right query.

[Example: catalog]

This is precisely the thing I'd build with one catalog and two router pages with using URL segments on (or, if it was simpler, just one 'router' page, and the other industry would have the 'real' tree), and possibly on module for generating the menus (again, there must be a way to tell the computer how you want the tree to be created and/or modified)

Generally speaking, I think it's less about the hierarchy and more about the context; and there are almost always ways to give user more context other than multiple hierarchies.

---

Edit: Reading through Antti's link, it seems that I echo Antti's and Ryan's opinion

[ryan]

Another possible solution would be to simply allow a custom URL alias for any page. This would probably be relatively simpler to implement, perhaps as simple as adding a "URL alias" text-field to templates that need it, adding a very simple module that does a query for the exact value of that text-field prior to PW doing it's normal traversal and dispatch. (This might not be great for SEO though, as you end up with two URLs for the same page.)

While I'm not in the camp that wants my URLs to go outside my site structure, I can see that it's a need some may have. And you've brought up a very good solution here--we could accomplish this pretty easily. SEO would not be a problem because the module that would implement the solution would hook into the Page::path function to ensure that it's reflecting the alias rather than the original. It would also not be a stretch to have the module perform a 301 to the alias when the page is accessed at the original URL.