typo3-realurl icon indicating copy to clipboard operation
typo3-realurl copied to clipboard

Bad URL for start page of TYPO3 website when not installed in web document root

Open stweil opened this issue 8 years ago • 13 comments

A TYPO3 installation with bootstrap_package and realurl (both latest versions from GitHub) which is not installed in the document root of the web server but in a subdirectory does not produce correct links.

Example 1: TYPO3 installed in /var/www/html/mysite and accessed by http://www.example.org/mysite/. Then realurl produces URLs like http://www.example.org/mysite/page1/, http://www.example.org/mysite/page2/, and so on. So far so good. But the URL which should point to the start page http://www.example.org/mysite/ is generated as http://www.example.org/mysite/mysite/ (which does not work).

Example 2: TYPO3 installed in /var/www/html/nested/site and accessed by http://www.example.org/nested/site/. Then the start page (index=1) gets the non-working URL http://www.example.org/nested/site/nested/site/.

I don't know whether the problem is in bootstrap_package or in realurl.

stweil avatar May 02 '16 11:05 stweil

I had the exact same Problem and I am not using the Bootstrap - Package Realurl 2.0.14 TYPO3 7.6.6

I recently upgraded from "baseUrl" to "absRefPrefix = auto". Changing the "emptyUrlReturnValue" form "/subdir/" to "/" and deleting RealUrl and TYPO3 Cache fixed the problem.

nothdurfterf avatar May 04 '16 07:05 nothdurfterf

I already tried setting emptyUrlReturnValue to "/". This fixed the link to the start page, but then all other page links no longer worked but showed the start page, too.

stweil avatar May 04 '16 07:05 stweil

Addendum to my last report: As long as I am logged on to TYPO3, everything seems to work perfectly. As soon as I log off, all TYPO3 links only show the start page. When I access the same URL of a sub page on different computers, one where I am logged on to TYPO3, both will show different contents. That's really strange!

stweil avatar May 04 '16 07:05 stweil

@stweil Clear realurl caches.

dmitryd avatar May 04 '16 09:05 dmitryd

I did so of course, also cleared all TYPO3 caches and the PHP cache in the TYPO3 install tool.

stweil avatar May 04 '16 09:05 stweil

I could reproduce this issue (against RealUrl 2.1.9/TYPO3 7.6.16) with a minimal test case at https://github.com/mblaschke/TYPO3-metaseo/issues/370

The entry for the root page regenerates in an inconsistent manner, even after caches cleared and manually deleting the entry from realurl's tables:

auswahl_171

$linkConf = array(
    'parameter' => $GLOBALS['TSFE']->id,
);
$GLOBALS['TSFE']->cObj->typoLink_URL($linkConf);

returns

/customdir/customdir/

The whole issue can be worked around in SQL:

update tx_realurl_urldata set speaking_url = '/' where page_id = rootpage_id;

thomaszbz avatar Apr 07 '17 04:04 thomaszbz

I cannot tell when it will be fixed (and even if it will be fixed at all). TYPO3's main use case is to run in the site root. I am not willing to spend time making a different installation for non-standard and rare use cases. Sorry...

dmitryd avatar Apr 08 '17 11:04 dmitryd

A simple workaround is creating an empty TYPO3 page which redirects to the correct page, like it is done in this example.

Then the wrong link http://www.example.org/nested/site/nested/site/ which was generated by RealURL will be redirected to the correct URL http://www.example.org/nested/site/.

stweil avatar Apr 08 '17 11:04 stweil

@dmitryd, for users with only a single domain who want to work with different versions of TYPO3, using subdirectories is the only possible solution as far as I know.

stweil avatar Apr 08 '17 11:04 stweil

What about just storing / in case of page_id = rootpage_id and L=0? Not sure how that plays out, but if it does not cause issues, it could be a quick win.

thomaszbz avatar Apr 08 '17 15:04 thomaszbz

Now that RealUrl is more or less a blackbox for me, I assume that RealUrl does not remove the absRefPrefix either for root pages in general or in case the resulting string is empty. In both cases / should be returned and stored in the tx_realurl_urldata.

A candidate for the fix (only occurence of absRefPrefix in the code) could be https://github.com/dmitryd/typo3-realurl/blob/d50ac90c67012736b4acc2f4071f1e6a16aa5acc/Classes/Encoder/UrlEncoder.php#L163

I guess the matching does not happen here for root pages. Which also could be the cause of another issue I stumbled upon earlier: #350, leaving a hard coded /1 for no reason (and btw: even when not installing TYPO3 in a subdirectory, thereby even not using absRefPrefix). Even solved it with the same workaround.

Some while ago, there already was a fix, intended to solve encoding root pages: https://github.com/dmitryd/typo3-realurl/commit/6ae860428e5914dbce86259e052ef4598ef3ec07

Another place to look at is a section dealing with more or less empty path (which should be the case for root pages):

https://github.com/dmitryd/typo3-realurl/blob/d50ac90c67012736b4acc2f4071f1e6a16aa5acc/Classes/Encoder/UrlEncoder.php#L1207

At least, this issue should be classified as a bug, because it clearly breaks a feature of TYPO3 (which is: to be installed in a subdirectory), no matter if the feature is widely used or not (personally, I never use it, but users do...). Wether the bug gets fixed and who does that, should be a separate question. In doubt, the bug is left open for years. So be it.

thomaszbz avatar Apr 08 '17 17:04 thomaszbz

TYPO3's main use case is to run in the site root.

Sorry Dmitry but that is simply NOT true. This is the default usecase during dev for us!

I can confirm the issue with 2.2.1

liayn avatar May 12 '17 09:05 liayn

--TYPO3's main use case is to run in the site root. I'm afraid that is not correct, many sites use the pattern: somedomain.com/cms/ somedomain.com/api/ somedomain.com/blog/

ivanoj avatar Apr 07 '18 21:04 ivanoj