Joomla 3.8 New Routing System

Joomla! 3.8 has introduced a brand new routing system. This feature which vastly improves Joomla’s out of the box SEO capabilities, and has been long awaited by users.

In order to understand this feature in greater detail and its implications on existing and new websites as well as 3rd party extensions, the Marketing Team spoke to Hannes Papenberg - the lead developer of this feature.

What are the changes for existing Joomla installations (3.x)? Is the new router active by default when you reinstall Joomla! 3.8? Is the new router optional?

The new router is not enabled by default, even on new installations, so upon upgrading, nothing will change directly for you. Instead you can choose to enable it for each core component (that supports it) to enable it or to use the old, legacy router. You can also select on a global level how incorrect URLs should be treated. Joomla right now is pretty liberal with existing URLs and often enough returns a (wrong) page instead of throwing a 404 error. To stay backwards compatible, you can still use this old behaviour, but when all your extensions support this, you can switch the 404 error handling to the strict mode and benefit from better 404 detection.

Do the extensions have to be adapted now or do they still work?

Existing components should not need any changes in 3.8. However I would advise to look into rewriting the components router to either use the new routing code or at least to utilise the class based routers that were introduced in Joomla! 3.3.

What are the advantages of the new router for developers?

The new routing system provides several improvements for developers. Component developers should be able to write consistent and good routers more easily by having to write less and especially less complex code. Advanced components should be able to write better routers by structuring them better with the class based routers. Integration developers are now able to modify existing routers and adding custom behaviour without core-hacking and in an update-safe way.

Is there any documentation on how to use the new router as a developer?

Not yet. For now, you can look at the existing core component routers.
EDITED: We have updated our Documentation on the support of SEF URLs in components.

What does the new URL structure look like?

URLs should not change between using the legacy or new routers, with one exception: if you have a very deep category tree, your URLs will change. Specifically, if you have a category with a menu item and in there a child category, which again has a child category, none of which are linked via another menu item, the last category and its content will have a different URL.

For example:

  • /linked-category/18-unliked-subcategory/23-unlinked-article (old router)
  • /linked-category/unliked-subcategory/unlinked-article (new router)

What about Duplicate Content - is it still available with the new routers? What are the advantages of the new router for users? Is there an effect on performance?

The new router will provide a better experience for the end users. URLs will now behave more consistently and more like a filesystem path. Also duplicate content will be mostly prevented. (If an admin misconfigured their site, we can't do much in that case.) The new router can also more reliably detect wrong URLs and properly throw 404 errors instead. Last but not least, the code should slightly improve performance.

What happens with Joomla! 4, is the old router switched off there?

Joomla! 4.0 will not have to be backwards compatible and thus we will be doing some major cleanup here. The goal is to rewrite the code to follow a good solid concept and that means removing among other things the legacy routers.

What else is planned in the router area for Joomla in the future?

With the cleanup of the routing in Joomla! 4.0, we will finally be able to make real advancements in this area. The routing in Joomla! 4.0 will only be made up from rules which are nicely encapsulated. This means that we can add very well tested features and make them optional, allowing you to enable or disable them at will. This will allow us to create completely different URL structures or for example implement a REST interface in the future.