My latest thing to do is switching my TYPO3 installations from baseURL to absRefPrefix. Ever since this awesome extension realURL was written, there was the need to define the URLs that should be relative to the TYPO3 main directory. Imagine having a TYPO3 installation running under a domain called www.b13.de. Without realURL your TYPO3 generated URLs looked like:

http://www.b13.de/index.php?id=25

Well, we all know that search engines don’t like it and visitors don’t find it as convenient as having a real URL, that looks like that

http://www.b13.de/en/about/downloads/
http://www.b13.de/en/products/saviour-v1/

Great! Let’s do this. RealURL does everything for you. Very simple and good (and bug-free — I love the latest version, thanks Dmitry!). However, if you’re on the downloads page and want to link to the products detail page, then the link will look like

http://www.b13.de/en/about/downloads/en/products/saviour-v1/

The reason is that realURL (or let’s say, your browser) does not know where the root of your installation is. realURL suggests using the <base href=”http://www.b13.de/”> tag to let the browser know that all relative links are relative not to the current page but to the specified base href. You can configure this in TypoScript with config.baseURL = http://www.b13.de/ and then there you go.

This all works fine — and if you have multiple domains, you just need to use TypoScript conditions, but this is all doable. However, in the recent past a few of my clients (NOTE: only the ones with 404 pages managed through TYPO3) ran into problems with strange floods of their log files with zillion 404 calls. The reason was that there are some bots that don’t interpret the baseURL tag, and then call the non-existent URLs (e.g. images), which redirect to the 404 which also includes the 404 path. Yes, quite annoying.

So, I was searching for an alternative. Dmitry posted some information on his blog about this error as well. The htaccess redirect he mentioned worked just fine, but I really wanted to avoid this in general, asking a simple question: “Can’t I just set a slash (/) in front of every URL and file reference of my generated HTML?”. This was something I actually wanted before I used this baseURL configuration option (yes, a long time ago). And, in fact, there was this option “config.absRefPrefix” lying around the whole time, and I never used it. As you can see there are so many things you find every time in TYPO3. With the absRefPrefix option I don’t even need to bother with the domains if I just use

config.absRefPrefix = /

or

config.absRefPrefix = /path/to/my/t3installation/

depending on the location of the TYPO3 mainsite directory. But it looked like it’s not that easy, because I ran into some issues (after switching 4 or 5 sites from baseURL to absRefPrefix).

• You need to have the latest realURL version and set the “reapplyAbsRefPrefix = true” in your realURL configuration array to keep the prefix.
• Linking between domains is not as smooth anymore as with the latest realURL and 4.2
• If you have references to typo3conf/ext/, they won’t be prefixed. I ran into this by having: <link rel=”stylesheet” type=”text/css” href=”typo3conf/ext/rgmedialinks/res/mediabox.css” />. I noticed that this is a bug in the TYPO3 core, so I fixed it.
• There are still some errors if you use custom extensions. You need to make sure that these work. I had trouble with mailforms and some custom scripts that alter the “img” tag, because the URL wasn’t typo3temp/ anymore but http://www.b13.de/typo3temp, so some default replacements didn’t work anymore. Nothing serious, but just something to keep in mind.
• The latest issue that the Magic images I added during the baseURL times with the htmlarea RTE didn’t work anymore. A simple htaccess redirect (RewriteRule ^(.+)uploads/(.*?)$ /uploads/$2 [R,L]
  ) worked just in this case.

In my eyes, the real and true solution would be to

1. get rid of all baseURL tags (in my eyes, it was and will always be just a dirty workaround).
2. have realURL add the part of the mainsite directory to every relative path when rendering the HTML. There could be an option for multisites to dynamically add the domain to all links, using the domain records.