TYPO3 Core

Edit to above in 7.6 the method where the absRefPrefix is set was PageGenerator::pagegenInit();
However, otherwise the issue is the same.

For everybody coming here because of a flooded typo3.log by realurl:

You can deactivate the logging of warnings from the class with

$GLOBALS['TYPO3_CONF_VARS']['LOG']['DmitryDulepov']['Realurl']['Encoder']['writerConfiguration'] = [
        \TYPO3\CMS\Core\Log\LogLevel::WARNING => []
];

Same here.

Sure it is a bug (a bug is not only a bug if it breaks something). The warning message appears but the config option is set. This leads to flooding log messages. And the flooding just took my website down because the log was not rotated and had 30 GB and then the partition was full -> site broken. Deactivating the log messages is a good workaround but not a solution.

@Bernhard Eckl: I think that is actually an issue with realurl that it does log every single instance here. Especially, if you don't set absRefPrefix it will log every link occurence and not just per request.

Regarding the bug itself:
It is a bug because why do we allow the user to set absRefPrefix otherwise?
For instance, the absRefPrefix could be a different domain - probably not very likely to happen but it could happen.

Also: At this point - meaning when

\TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::checkPageForShortcutRedirect

$this->config['config']['absRefPrefix']

I am not sure which page it is initialized for but I think for the page that does the redirect which I think should be enough in 99% of the cases?

However, it is true that we won't have the absRefPrefix of the shortcut page but
I checked with Xdebug.

@Eckl:

IMO you are mixing causalities here. Only because realurl reports some "missing configuration" it does not mean this is a bug in the core. Maybe it's intended that TS is not evaluated at this point?

I'm sorry for you that your site went down due to logging, but honestly, this is a matter of wrong server setup (missing rotation, missing monitoring, not checking logs after updating extensions).

The warning by realurl is for sure a thing that is meant to hint the integrator towards a possible wrong configuration of the system. It does not mean that this is always true.

As I said, from my first glimpse at the code I can say that changing the core to deliver fully parsed TS at this point during request handling might (or rather will) have quite a performance impact and is (unfortunately) horrible to test.
I therefore kindly ask for a concrete use case, where this actually breaks functionality. Because if nothing is broken then the log message probably is wrong - which my current point of view is.

Note: Anybody is of course welcome to provide a core fix!

@Markus: The template seems to be parsed at that point and the config option is available.
I think it is parsed for the page with the ID that does the redirect but I think that is OK.
After all by default URLs are generated for the page that creates them.

A use case would be to modify the domain to redirect to, it should probably be done by domain entries before that but... I think in general since the "auto" option the reason for being able to set absRefPrefix is quite limited.

I think it is parsed for the page with the ID that does the redirect but I think that is OK.

Interesting finding and yet hard to decide whether this is correct or not. But it should be okay to assume it is correct due to lack of better knowledge.

Can you provide a patch Andreas?

I can. Will probably do so tomorrow or over the weekend.
One thing: Just above the shortcut redirect it does a similar thing for mountpoints.
Probably best to initialize it before that one as well?

Mountpoints do not redirect, I guess this is not needed there?

Ah. The method is actually afterward. Not sure regarding redirect but the method is called: checkPageForMountpointRedirect. I think if one accesses the mountpoint page itself it redirect automatically to add the relevant MP parameters?

Hm... I would need to give this a try. Haven't used mount points for a very long time.

Just as information: I wasn't able to look at this during the weekend. And I am not sure when I will find the time to do this now. I will try next weekend but no guarantees.

I met the same problem and reported it here: https://github.com/dmitryd/typo3-realurl/issues/570

I quote here my suggestion:
"I can't find a way to let Realurl to know that the encode link request comes from a shortcut page. Maybe is the core that should set absRefPrefix to NULL as default instead of '' until its value is really set later."

Could it be a solution to default absRefPrefix to NULL?

I can confirm that this happens in our TYPO3 CMS 7.6.23 installation when calling a shorcut page even if config.absRefPrefix is set. In our case config.absRefPrefix is set to "/".

I would like to notify you that the discussion about this continues here: https://github.com/dmitryd/typo3-realurl/issues/577#issuecomment-355924387
The extension author (Dimitry Dulepov) asks here if the fix should take place in the core.