News-Feeds:
baseURL is dead - long live absRefPrefix
In a world where CI and flexibility is the new new, I think it's time to wave goodbye to a dear old friend!
When I first started working with TYPO3 in 2003, one of the first settings to set in my TypoScript template was
config.baseURL = whatever.local
This was really great, then all my links was prepended with the correct url.
But, when I moved it to a new installation - and a different domain - my urls was wrong :-(
Not a big deal, I can just add it as a constant and change the value... Well, yes... But how cool is it to do manual changes when ever you deploy your installation to a new platform.
Imagine having to create test environments for a team of developers, then this change will have to be made every time - uncool if you ask me.
But how can I work around this?
Instead of prefixing your URI with a specific hostname, you can rely on the hostname requesting your installation.
If you are having a multisite tree, it's important to create a domain record on each page level - but you most likely done that all ready :-)
You can do this by writing the following in your TypoScript setup
config.absRefPrefix = /
and of course, remove any instances of config.baseURL!
in this way, we tell TYPO3 to prefix all links with a "/" and don't really care about a baseURL!
And by this, you are able to move your installation around, with out caring about the baseURL - all paths are correctly written and you have removed yet another dependency on your local environment.
What if I develop/deploy in a subfolder?
Then you can add whatever the folder name is, to the end of the value ex.:
config.absRefPrefix = /foldername/
and then of course expect the same folder name on the production server.
What do I actually benefit from this?
In a automatic deploy process, imagine having to replace all instances of "config.baseURL = ###" with a value of the new server environment?
I'm not a regex guru - but I've tried in once and it wasn't nice and some not wanted changes was made - plus it was hardcoded on searching for a specific hostname.
In this way, your deployment can run, without having to worry about the hostname changes.
comments
April 4, 2013
20:42
This also works on our CI server
April 4, 2013
20:51
The issue here, IMHO, is that you hardcode the url + you have to add a new condition each time you create a new domain name.
And, IIRC, conditions also affects caching
http://lists.typo3.org/pipermail/typo3-english/2011-August/076279.html
Thanks for your feedback!
April 5, 2013
08:13
'FE' => 'additionalAbsRefPrefixDirectories' => 'YourNewStorageFolder1/,YourNewStorageFolder2/',
April 5, 2013
08:23
However, there are numerous extensions out there, which do not add the absRefPrefix (that's a bit a misconception that it has to be added when generating links).
Conditions have an effect on caching. But for this purpose, it shouldn't cause too much trouble, as you will still get only one cached version - compared to e.g. a UA-based condition, where you get cache entries for IE6, IE7, Firefox, Chrome etc.. (if you would split it up that much).
April 5, 2013
10:56
yes, that's right. In generell on our projects, we have only four environments:
- local dev
- testing
- stage
- live
So, we have only four conditions, each for one server / environment.
August 22, 2013
22:48
my thoughts on the matter:
Since multiple topics are covered I will try to somewhat organise them.
a) to my knowledge baseURL adds a tag, it does not prefix links. The browser does. Thus it has to be evaluated only once during rendering.
b) absRefPrefix is evaluated per link by design and thus adds a performance impact to the rendering of your website. So the solution is sub-par.
c) Having to change your TS during deployment is an indicator something is wrong with your rollout strategy. Here's how it works fine:
Have your TS in textfiles on the disk (I think you do this already).
Have the LIVE (!) baseURL in the file.
Have each dev set their respective baseURLs in the sys_template record (it is loaded after include_from_extension, so it will override URLs on your DEV system).
This works great for everything DEV like Formhandler recipients, API credentials and such and is highly unlikely to be "forgotten" during rollout.
d) Having a condition in your TS is fine as well.
Although you might think "oh, damn, multiple caches" if you think it through you will notice that the caches will only be generated if your condition returns true and if your DEV URLs condition returns true on a live machine you are in deeper trouble than having multiple caches.
So in this case... close, but no cigar.
e) absRefPrefix adds up to HTML code. While this might seem irrelevant with the "/" solution you propose it still is one character more per link/asset loaded.
Fight for every byte, there are a LOT of countries where 128kBit is considered "broadband".
And anyways... has a client ever complained about his website loading too fast? :)
f) It adds a vector for a misconfigured webserver, since a website could be made available under http://domain and http://www.domain.
Adding a simple "/" will and not taking care of your webserver to do the appropriate redirects will result in duplicate content, resulting in a sub-par SEO ranking of your site.
Related to this you might mess up realURL and/or proxy caches in the process.
cheers
Mathias
August 23, 2013
00:55
let me answer some of your points:
- absRefPrefix is applied to any link, no matter if it's used or not. If it's not used, an empty string is prefixed, so you won't notice it. However, the functionality does not add any overhead.
- However, there are a few str_replace() calls which are run once to prefix any static references (not links, but e.g. typo3temp/) with the absRefPrefix. The result is cached on pages without INT objects, otherwise it is called at every request. Besides this, I don't think that str_replace() affects performance in a notable way.
- If you set multiple baseUrls using conditions, keep in mind that every condition is evaluated for every request. So in this case, you could even safe performance by using absRefPrefix, because the condition is not needed then! (You mention a way which works without conditions too, but I suppose that most people still use them for setting the baseUrl...)
- Your last point is already a problem when you try to solve it using baseUrl. The site can be opened with and without "www.", only subsequent links contain the corrected host name. Instead of this, I prefer to redirect to the main host name using a rewrite rule even before TYPO3 is involved...
So in summary, I don't think that any of these points speak against using absRefPrefix. But certainly, you can still use it if the one byte that can be safed is important to you... ;-)
Greetings, Michael
Buzz is the official blog resource of the TYPO3 project. You can be part of Buzz too. If you want to blog about the achievements of your team or your personal involvement please check out our HELP section.
config.baseURL = http://www.project1.de/
[globalString = IENV:HTTP_HOST=project1.local]
config.baseURL = http://project1.local/
[global]
[globalString = IENV:HTTP_HOST=stage.project1.de]
config.baseURL = http://stage,project1.de/
[global]
...