Bug #63486
closedTypolink checks only against one domainname
0%
Description
Typolink now checks only against the cached domainrecord when comparing $currentDomain with $targetDomain. In version 4.5 typolinks checked against all domainrecords in rootline. This is a problem, because it is not possible to change the domain e.g. for changing language purposes. When changing domainname and set config.baseUrl to this domainname (over TS-Condition) there should be only relative links, but typolink now do not recognize, that the changed domainname is in rootline too, and generates absolute links to the first domainrecord.
This is made now in class TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer.php in line 6033 > $GLOBALS['TSFE']>getDomainNameForPid() and afterwards the comparing. Before (in v4.5) here was compared against domainname-array with all domainrecord in rootline (class.tslib_content.php, line 5794).
Updated by Bas van Beek almost 10 years ago
I also want to confirm this issue. It is a roadblocker to me, because I can't deliver the project like it should work.
We have a multidomain page-tree with also some shared sys_domain records on the same tree.
I.e.:
Company site (main company site), sys_domain record: www.company.com
--[ Product site 1 (product site), sys_domain record: www.productname.com, www.productname.nl, resellername.productname.com, resellername.productname.nl
--[ Product site 2 (product site), sys_domain record: www.productname2.com, www.productname2.nl, resellername.productname2.com, resellername.productname2.nl
When we open the Product site 1 we need to link back to the Company site domain through a tmenu. This works great when activate the setting:
config.typolinkCheckRootline=1
But then a new issue pops up. Now if we open the domain www.productname.nl all the tmenu items that are belonging to that site are having absolute links that are pointing to the domain www.productname.com. The method should not only grab the first sys_domain that is on the tree, it supposed to grab all sys_domains and then verify them agains the http_host.
Updated by Bas van Beek almost 10 years ago
To bypass the problem I have adjusted the following file:
C:\Users\Bas\PhpstormProjects\TYPO3.CMS\typo3\sysext\frontend\Classes\Controller\TypoScriptFrontendController.php
Line: 5032
if (isset($sysDomainData[$row['pid']]) && $row['domainName']) {
Change it to:
if (isset($sysDomainData[$row['pid']]) && $row['domainName'] != GeneralUtility::getIndpEnv('HTTP_HOST')) {
I hope it's helpful for you too.
Updated by Marcello Pabst almost 10 years ago
We currently experience the same problem.
The method getSysDomainCache from the TypoScriptFrontendController causes this misbehaviour.
(Line 5015)
// there is already a "forced" entry, which must not be overwritten if ($sysDomainData[$row['pid']]['forced']) { continue; } // there is alread a NOT-forced entry and the current one is also NOT-forced, thus keep the old if (!$sysDomainData[$row['pid']]['forced'] && !$row['forced']) { continue; }
So more than one sys_domain record never make it into the cache.
I think this should work like it was in 4.5 before and a check for the current HTTP_HOST should be added to getDomainDataForPid (Line 5047).
Manually patching the core is not an option for us.
Updated by Stig Kjeldsen over 9 years ago
We have the same problem with a multidomain page-tree. We are using 6.2.9. Very annoying problem
I tried the solution described by Bas van Beek, but I cant fine the code line (5032)
if (isset($sysDomainData[$row['pid']]) && $row['domainName']) {
in the file TypoScriptFrontendController.php
Anyone who has a solution or can fix it? I think our customer would be happy to pay for a solution.
Updated by Bas van Beek over 9 years ago
Are you using the latest GIT?
I have quickly pulled the latest changes and noticed the code has been changed.
Now it is line: 5017:
// if there is already an entry for this pid, check if we should overwrite it
if (isset($sysDomainData[$row['pid']])) {
Change it to:
// if there is already an entry for this pid, check if we should overwrite it
if (isset($sysDomainData[$row['pid']]) && $row['domainName'] != GeneralUtility::getIndpEnv('HTTP_HOST')) {
Updated by Stig Kjeldsen over 9 years ago
I tried to change the code, and it seems to work.
I will let the changes be and follow the error log the next few days.
Thanks to Bas van Beek
Updated by Riccardo De Contardi almost 9 years ago
I report here the discussion on the issue #71559 to keep track of it:
[issue description]:¶
When we have a page:
- SiteThat has two domains:
- www.domain1.nl
- www.domain2.nlNow if we open the domain www.domain2.nl and check the deeplinks they are all pointing to the domain www.domain1.nl instead of www.domain2.nl.
In other words TYPO3 uses the first sys_domain in the list and ignores the one that we are on right now (it is not matching on HTTP_HOST).
This issue is fixed and patched before, but is coming back again.
[answer for the question "Did you set an absRefPrefix or baseUrl?"]:¶
I have found the cause:
www.domain1.nl had this option checked:
[X] Always prepend this domain in links:www.domain2.nl
[ ] Always prepend this domain in links:So when you open www.domain2.nl then it forces to prepend the typolink with the www.domain1.nl because that checkbox in the sys_domain is checked.
I still believe this is a bug, because it should only prepend www.domain1.nl when we really have that domain opened.
Yes I set it to this:
config.baseURL=http://www.domain2.nl/
Updated by Benni Mack over 6 years ago
- Status changed from New to Needs Feedback
- Assignee set to Benni Mack
Can you explain what your expectation is on that?
- Having two sys_domain records?
- TYPO3 is choosing the first one although you are on the second one?
If we'd allow the second one to be used as well, we'd have one page available under multiple domains, which should be avoided in terms of SEO.
Updated by Alexander Opitz over 6 years ago
- Status changed from Needs Feedback to Closed
- Assignee deleted (
Benni Mack)
No feedback within the last 90 days => closing this issue.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.
Thank you and best regards