Its been 2 months since my last update and I have to apologize for not updating more often. While I'd like to keep you in the loop as much as possible, I also have to have something to report and that unfortunately has not been much lately. I'm still struggling with the application router and its backwards compatibility. So much in fact, that I have to change plans.

I've made a "mistake" during this development and that is that I first wrote the unittests for the current router and then implemented my code. In the meantime those unittests have been accepted and thus the current core router code is completely covered with unittests and future code improvements will benefit from that. At the same time this means that I can't weasel my own code in there if it doesn't pass those tests and that unfortunately is still the case.

The current router has a pretty erratic behavior. It takes a JUri object and you can modify it, while at the same time it expects some variables to be returned as associative array. At the end, some of the data that it extracted from the URI is in the JUri object and some is in the associative array that is returned. I tried to make this behavior consistent by having the router-rules not return anything and instead transform the JUri object step by step.

Consider something similar to an assembly line on a conveyor belt. At the first step of parsing a URL, the JUri object arrives and special characters are decoded, the domain and folder of Joomla are stripped out, etc. All this data is written back into the JUri object. At the next step, the menu item is decoded, again storing the Itemid in the original object and removing the decoded information. And so the object moves along that assembly line until the human readable URL is decoded into something that Joomla can understand. This will not be possible in a truely backwards compatible way in Joomla 3.x.

A break in backwards compatibility will maybe affect 1% of all installations, but that would still mean several tens of thousands of Joomla systems, which makes this a no-go. I know, I promised full backwards compatibility, but this will not be possible for the application router and I'm sorry for promising too much.

The good news is, that this does not affect the component routers side of things. Since component routers have been based on two magic functions and only rudimentary class support has been implemented by me in Joomla 3.3, we can improve those without much regard to backwards compatibility. This means that we can have shorter, simpler and proven routers in the next release of Joomla. I will provide PRs for this in the next few days.

You might ask yourself, why I haven't done the component routers in the first place and you are right. I have to apologize for wasting to much time on the application router and not working on the component router more. I approached this a bit too linear and first wanted to fix the application router before approaching the component router, which is invoked by the application router. I got a little carried away.

So to summarize all of this: Unfortunately the application router can't be implemented in Joomla 3.x without breaking backwards compatibility and thus breaking the rules of the project. We will have to wait for Joomla 4.0 to fix that part of Joomla. I might be able to provide an interim solution until then. The component routers (which you might find more interesting anyway ;-) ) will be able to be implemented in the next Joomla release if the project accepts.

As a sidenote, we also got 4 other bugfixes out of this project so far.