config.absRefPrefix on by default?

Discussion Topic

We improved config.absRefPrefix in the recent versions, so config.baseUrl could be replaced in the future. What I propose for the future is that we use config.absRefPrefix = auto by default, if not overridden or emptied (config.absRefPrefix =) in frontend by custom typoscript. This ensures that new installations do not have to worry about that option anymore - it just works.

I would like to gather feedback in which cases config.baseUrl would be superior to config.absRefPrefix - because we (again) have multiple approaches to solve a common issue - and I’d like to show a best practice for Core.

Personal remark: We used config.baseUrl in the past due to some websites 100% with flash (that was back then), but had problems with IE6 back then, and absRefPrefix was not supported everywhere. This changed sometime in 4.x when we switched all our installations to absRefPrefix = / (or auto) to generate absolute URLs, which works fine for around 100 projects we used this functionality back then. It might make sense for some static pages like newsletters, but then we use config.absRefPrefix = http://email.mydomain.com.

4 Likes

We have a few projects where we use config.baseURL for multi-tree setups. But as I read now in the docs, config.absRefPrefix = auto achieves the same, if I understood it correctly. If that’s the case, I’m totally in for removing config.baseURL.

Thanks for your feedback!

Removing baseUrl is not necessarily something on the first prio list, but more going with a “de-facto standard”, so the integrator does not need to set anything anymore (similar to config.metaCharset = utf-8).

However, there is one issue I remember what is not working: If there are folders / paths that are not within uploads, typo3temp, typo3conf/ext/ or any of the local FAL storages, this needs to be configured via $TYPO3_CONF_VARS[FE][additionalAbsRefPrefix] paths.

Yes less settings you need to set on every project!

In addition to set a practical default value it would be important to add some introduction documentation for all the people who don’t know the benefits of don’t using baseUrl

Something like
https://buzz.typo3.org/people/soeren-malling/article/baseurl-is-dead-long-live-absrefprefix/ should make it’s way in some official documentation I guess.

I’m all in favor for sane defaults, so let’s use auto as default for absRefPrefix.

3 Likes

Yee-haw!!! :heart_eyes_cat:

I’m also in fawor of making it a default value.

I am against a default value for config.absRefPrefix.
“All relative links in TypoScript are prepended with this string” means that many characters will be append to HTML by default instead of using simply a <base href"..." />

Most of the time websites have only root domains and some have particular configuration.

I know this is meant as a discussion and not a poll, but I can only give my +1 on having good defaults making the life easier for newcomers.

We have absRefprefix = auto by default in all our sitesetups. Works without any issues also for multi-site instances and also in dev-setups, where an instance usually is in a subfolder.

baseUrl back in the days caused severe issues everywhere, it can leave this world without much cry.

A note on setting absRefPrefix to an absolute URL including a domain. I consider that actually a dirty dirty hack. We would rather need an option like “only use absolute urls everywhere on this page”.

1 Like

But that would be limited to a single page, right? I currently don’t see a usecase where this could be required. Am I missing something?

Newsletters mostly. Or content that is afterwards exported somewhere else, where the BE servers as the editor for composing that content.

We have by default config.absRefPrefix = / in our installations and don’t use the config.baseUrl option. Although it is not our default now, I can totally live with setting the auto value as default.

I just want to add to the discussion that I’ve discovered this article: https://yoast.com/dev-blog/relative-urls-issues/

1 Like

I think by using the config.absRefPrefix will even fix problems like spider traps because no link will be to a …/pagename. The canonicals are out of scope in this part (canonical urls should always be absolute url’s).

If people want fully qualified domainnames they can always do their configuration, but I don’t think having the auto option set as default, will cause issues.

If we like, I can ask Joost to give his opinion in this.

1 Like

I still think that prepending absolute urls everywhere has some drawbacks (for example during migration between environments)

That’s actually what the value will be after auto has evaluated the environment. If you are in docroot, / is the value.

IMO we should only make an URL absolute, if there is no other way. So for the newsletter example that’s one use case.
Other than that absRefPrefix = / works like 99.99% of the time.

2 Likes

Really??? We’re talking about some little bytes caused by this change? There are many, many other changes which could reduce the count of characters in the generated HTML code.

As Soeren has already written 4 years ago: baseUrl is dead! Using absRefPrefix is currently best practise and is working fine. So why not using this as default. +1

1 Like