Bug #18660
closed
Links to Mount Pages (Substitute Mount Point) that cross domains/sites are broken by Typolink
Added by Slite over 16 years ago.
Updated about 12 years ago.
Description
If you link to page which mount's a page in another site and the initial page has "Substitute Mount Point" set then the link is created with host information from the domain record(s) of the mounted page. Since the mount point information points to information in the original site you get an error as the original location can't be determined. Manually changing the host part of the URL to the correct one shows the page as expected.
The problem appears to be that the mounted page's domain takes priority in tslib_content::typolink if no host has already been added to the link (Line 5365 of class.tslib_content.php) However, the host is only set (by t3lib_tstemplate::linkData) if 'config.absRefPrefix' is set.
The work around is to set config.absRefPrefix.
This shows up in menus now that they use typolink, and also from links in pages.
(issue imported from #M8189)
Files
It looks like the problem is further back in the menu code. Typolink is being asked to work with the wrong information because it is being given the mount point, with the MP parameters being passed in. This prevents Typolink from doing it's job properly.
The workaround breaks non-mounted references to pages on other sites in the same tree as these always get the host of the referring site, rather than the host of the containing site.
I think that the attached file resolves with the problem without breaking anything further. Basically, the t3lib page code generates the menu as normal, but when it adds a mount point it also adds the original page UID to the row -- otherwise this information is only available in the key -- which is trashed by the menu code -- or by splitting the MP_Vars data. This extra field is then trapped by the link code at the menu generation level and used to do the typolink generation. However, everything else is done on the basis of the returned data (ie the mount point location)
The problem with least interference patches is they don't go far enough. The original version worked OK for substituted mounts, and once you were inside a mounted section, but failed to allow you to get there in the first place.
The -v2 patch means that the domain will not be overridden if the local page has MP vars being added by Typolink, or if someone tried to override things by passing them in as extra parameters (which the menu code does).
I have the same issue here after updating from 4.1.7 to 4.2.1. What used to be http://domain2/?id=1&MP=1-2 (when coming from domain2) is now http://domain1/?id=1&MP=1-2, which renders the feature useless for me.
The "cause" is the fix for #18229 (changed line 5339, which of course is in itself correct!), although that code should never be reached for mount points (see lines 5300-5302).
But the links that are to be generated have no $MPvarAcc content (line 5302), so the next block is used, which then replaces the domain (around line 5339). What worked for me as a (hot-)fix is adding a check for the doktype 1 to line 5306. This skips that block for mount points without $MPvarAcc.
(All line numbers are for tslib_content as in 4.2.1)
Disclaimer: an even better fix probably would be if links generated for mount points would have $MPvarAcc set.
Attached patch against 4.2 branch for the fix described in ~23654.
I checked the doktypes, and it seems my patch is broken. While it works for me, this seems to be more luck than anything else: doktype 7 denotes mount pages, not 1. It seems $page in the context used is the current page, not the page the link is pointing to.
Sometimes it is worth reading first - the attached v2 patch by Slite does it better. I changed it to fit against the 4.2 branch and added the check also for typolinkEnableLinksAcrossDomains being false. See new v3 patch.
Just patched my system with patch version 3, to repair a page full with broken links that remained unnoticed for months!
It works well, thank you very much.
Any plan to have the patch included in the next release of the core?
I overworked the patch to apply against recent versions (4.2.3).
Patch works for me!
Also available in: Atom
PDF