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.

Hello to everybody and especially all the contributors!

I can happily announce that the first pull request has been created: https://github.com/joomla/joomla-cms/pull/3759

This PR introduces a large chunk of tests to document the current behavior of the core router classes and is the foundation to rewrite the system in a backwards compatible way.

In the future, I will keep you all posted on the progress of this effort here on this site. Considering the timetable: I'm lacking a bit behind, but all major roadblocks should be gone now and I should be able to devote most of my time to this project.

While my updates were sparse, I haven't been idle in the last few weeks. The current situation is that the new routing classes are done and the old behavior has been put into rule classes, however this code is not backwards compatible yet.

JRouter has been reduced from 29 methods to 10 (those 19 methods have been left in but deprecated), and JRouterSite has been reduced to 2 methods from formerly 12. While the interface has been kept backwards compatible, the behavior has changed and this is where the problems set in. Is it still backwards compatible when the methods don't have the same effect as before? Right now, when you set the mode of the router between SEF and RAW, it changes the URLs. With the proposed changes, there is no mode anymore. It is just a changing set of rules that is applied to URLs. So I'm struggling on if and how this is B/C.

There is also the issue of the interface of rules. In the past, build-rules did not have a return-value while parse-rules did and in the new system, this has been unified so that both don't have a return-value. I think I have a sufficient solution for that, but it needs more testing.

Despite these issues, I'd like to give you a little insight on how this works right now. JRouterSite still extends JRouter, but it does not really override any methods anymore. Instead JRouterSite defines a set of rules that are added when the router is instantiated. It also takes an app- and menu-object that it provides to the rules, so that URLs for the frontend could be build both in front- and backend, depending on if you are able to get proper app- and menu-objects. JRouter then only provides a build() and parse() interface, which executes the different rules on the URLs. So JRouterSite is mostly empty and JRouter itself is pretty lean, too.

For the rules, there are two ways to add them to the system. Solution #1 would be a callback, that you can hand over to the router. Solution #2 is simply a rule-name, like "sef", which gets expanded into "JRouterRulesSef". That class should implement the JRouterRulesInterface and up till now, all those rules are autoloadable. Each rule provides a build() and a parse() method, which take the router and the URI object as parameters and can then modify them to their liking. Both objects are handed over as reference, so that the methods don't need a return value. While I could implement the rules as abstract classes, I decided to work with instantiated objects here, since this allows you to do some preliminary work like caching the menu or similar stuff.

I will try to keep you posted more often and as soon as the code is presentable, I will push it into my cloned Joomla-github repository. Thank you all for your patience, I definitely have not forgotten you.

This is an alphabetically ordered list of all the contributors to this little project. Let me say "Thank you!" to all of them. If you want to have other information displayed here instead of only the nickname, please mail me at info@joomlager.de. I will publish your name, company name, link to a website and a mailadress if you ask me to.

  • 2in1-online
  • 4Web Inc.
  • a.sedelnikov
  • alexred
  • Andreas Ruttkamp
  • AndreD
  • babelfish
  • chmst.de
  • Claudia
  • d.grammatiko
  • Dan Knauss
  • David Jardin
  • Digital Peak
  • digitalcomputer2142
  • Dmitry Averin
  • Dmitry Rekun
  • Doxadigital
  • DrVolt
  • dumitru05
  • Gary Barclay
  • hechtnetz
  • HikaShop
  • Inge
  • ivangretsky
  • Ivo Apostolov
  • javier.gomez.corio
  • joomla-agentur.de
  • Joomlapolis .com
  • Kim Hjortholm
  • kroener
  • Marko Dedovic
  • Matt Thomas
  • Matthew Philogene
  • mbabker
  • mblass
  • mitchlowther
  • mpetrushkov
  • Octopoos Editor of SEBLOD
  • OSTraining .com
  • Papillon
  • Paul van Jaarsveld
  • Paulo Griiettner
  • Peguschwein
  • Pulsar Informatique
  • ralf.longwitz
  • ranelkobi
  • redCOMPONENT.com
  • Robert Went
  • Roberto Segura
  • rowbyrowby
  • Signum Product Solutions
  • Simone Bussoni
  • smz11
  • SoftForge Ltd
  • SOHO Prospecting
  • stas.ivashkin
  • Tobs Bobs
  • Valentin Despa
  • Valentín García
  • Viktor Vogel
  • VoIPBilled.org
  • Webworker Berlin
  • Wicked-Chick.de
  • Yireo
  • zikkuratvk