Since version 9 TYPO3 comes with routing out of the box. Routing means, that “speaking urls” are created automatically by TYPO3. It is available for pages, languages and even extensions.
In this post I show you, the routing regarding the TYPO3 core. In the next blog post I will dig into the routing for extensions.
Getting started with routing for TYPO3 is very easy, because you can configure it via the backend. The result is saved to yaml files. In composer based installations, you will find the file under
<project-root>/config/sites/<site-identifier>. In non-composer based installations the
sites directory will be located under
typo3conf. You should / must add these files to your source code management system.
You can add a site configuration for each page, which has the
is_site_root flag set. An overview of all such pages is available in the
Site Management ->
Sites module. A blue button behind the page title and the uid, indicates that you can add a configuration for this page.
A new site configuration needs at least three settings:
- site identifier
- an entry point and
- a default language
The site identifier is a unique string within the TYPO3 installation. On the one hand it is used in the config directory to save the site configurations to different paths. On the other hand it is used in TypoScript, conditions and the php api.
The entry point is about the domain, for which the configuration is valid. As it is very likely, that there is not only one entry, but different ones for different environments. With entry point variants, it is possible to define alternatives depending on the application context or an environment variable.
The third setting is the default language. It is set on the second tab of the form. Necessary values are the title, the locale values and the flag icon. The only field from the locale values, which must be set, is the
Locale field, but for consistency reasons, you should also set the
Language key for xlf files and the
Two letter iso code.
After saving the basic settings, you can add an arbitrary number of additional languages. The languages must be available as a website language on the root page. There are at least two cool thins about the new language handling.
First, it is easily possible to use different default languages on different sites. Until version 8, this was nearly impossible, it was not setup properly right from the beginning.
Second, it is now also possible to use a language specific domain, and not just a path segment like
fr for the french version. Same here: It was possible with some effort in the prior versions, but now this is just some typing and mouse clicks away.
Static routes are urls to “files”, that fulfill a certain purpose. A very common example is the robots.txt. Each search engine looks in that path for instructions how to handle this site. Other use cases are the site verifications of Google and other services or manually created sitemaps.
There are two types of static routes: “Static Text” and “Page, File or URL”. With static text it is possible to add some simple lines of text, that are delivered under the set url. The second type provides a link picker, with the options to link a page in the page tree, a file or even an external url.
Per default, the urls are build from the titles within the page tree prepending the language segment for the current language. Additionally a new field was introduced in the page settings: the url segment. Other content management systems call it a slug.
The url segment is a (unique) string on a site, which identifies a page. If a slug is present, this is used for the url and not the page path. The resulting full url is displayed right below the url segment field. If there is a duplicate, TYPO3 will append it by a dash and an integer.
The last feature / tab has not really to do something with routing, but is also part of the site configuration.
Until version 8 it was only possible to define the error handling for the complete instance via the settings in the
LocalConfiguration.php. Now this is also part of the site configuration. It is possible to configure the error handling for each site independently by combining a http error status code and an action. Basically any http status code can be used. TYPO3 provides four of them as a preset. Possible actions are to show a fluid template, to call a php class (implementing the PageErrorHandlerInterface) or to show a page using the well known TYPO3 link picker offering pages and external urls.
These features are a really great step forward for TYPO3: Speaking URLs (aka routes) right out of the box. And I am really looking forward to use it in production. A full documentation about all the bells and whistles, is available at https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/SiteHandling/Index.html.
What’s missing in this post, is the routing for extensions. This is also already implemented in core and the topic of my next blogpost. So stay tuned and come back next week.
Last but not least, I want to thank Dmitry Dulepov, who maintained EXT:realurl since “ages”, for all his time and dedication. I remember times, when there was very much criticism around and he kept up the support and bugfixing of the extension. Thank you, Dmitry!
I want to thank my supporters via patreon.com, who make this blog post possible. This week, I want to highlight Thomas Deuling and his extension “TYPO3 Advent Calendar”. If you need an advent calendar extension, please get in contact with him. He supports me the next two and a half months as a platinum patron. Thank you, Thomas!
If you appreciate my blog and want to support me, you can say “Thank You!”. Find out the possiblities here: