Some were potentially wondering what the unlimited “sub-sections” thing was that I was so passionately babbling about on the twittersphere. The story goes something like this, paraphrasing my fabulous wording:

TXP + unlimited “sub-sections” for articles would be amazing, wouldn’t it? Oh, kinda took 5 minutes and 50 lines

I ended my tweet to a image of this — click the image to see the raw non-edited variation:

Have you noticed something strange when you came here? Look at this blog post’s URL. I can outright say that this blog or the website doesn’t use any aggressive permanent link plugins, categories or anything like that. This is what the thing I mentioned is about. A thing that I without a second thought called Joe the cat — I mean rah_pathway and put up to GitHub.

Deep and free path structure for articles

As you may notice the previous image shows a Firefox’s URL-bar, what is in it is the important part. The address; it’s long and nested — some in the Textpattern or the web scene might associate a term “sub-section” with it, whatever it really even means.

That same long address, excluding the site’s URL, is also visible in the page_url labeled field, visible on the Write panel. The field itself is nothing really special, it’s just a standard custom field. The custom field’s value is used to set the article’s published location, acting as an URL-title without restrictions.

When I used a term sub-section, I used it in it’s board sense, referring to the path structure. The thing doesn’t actually affect Textpattern’s content model in a way or the other, it just, for the most part, changes article’s purely visual URLs.

The whole thing monkeys a path structure, and has no relation to actual location of the content in the Textpattern’s content model. The idea is to allow the article’s author to decide the full path of the article, without the location being hindered by a section or any other potential relationship.

After setting the desired location, the plugin steps in and adds some extra “guidance” to Textpattern’s page routing, allowing these free-roaming URLs to point correct resources. How it technically works in the background is very simple; it just merely searches requested URL from the articles database and injects the article’s ID to the routing process if a match is found. After the routing is done, it clears the injected values to avoid any potential side-effects.

Coming as a plugin

Technically yes, it’s a Textpattern plugin. Experimental one, and isn’t likely highly usable — not sure if it never will be. Rah_pathway is a neat idea, but has drawbacks. Textpattern’s doesn’t have advanced page routing, not yet, at least. As such, the URL does nothing more than looks pretty. The article, the page and the context of the content is still the same. It’s ideally the same as rewriting an URL or doing an HTTP redirect.

Textpattern’s users have always tried to find ways over these limitations and to imitate the absent of sub-sections, but most of the solutions are cumbersome and cause side-effects, some in terms of performance, some as bugs. Some of the most featured plugins are borderline incompatible with the current Textpattern versions. If there is anything good about this particular solution, meaning rah_pathway, is that it doesn’t break much of anything. This is due to the plugin’s passiveness, which is where it falls short too. It doesn’t try to inject it’s own logic in there, or force things to go the other way.

There is a source available on GitHub. As of now it’s at the early development stages and is something that I would consider as an “unusable”. For instance, in these early stages it only works when installed at the root of a domain and the source makes some absurd expectations.