Bug #22542
closed
Problem regarding sys_domain records handling in typolinks
100%
Description
If there are multiple sys_domain records used in one page-tree (same Folder/Pid) every link rendered within the page will be forced to use the first sys_domain record (=1st domain given) for all links (Typolinks).
This situation may be worse if there is for example a "One-Tree" concept for f.e. different customer-domains or different languages (domain.de / domain.com).
In my opinion it would make sense to leave all links on that domain the page has been opened with (even if there are multiple records for that tree within the same page). The behaviour that is given now could and should in my opinion be switched by the "force-prefix" checkbox listed for sys_domains records. The normal handling should be that there is no domain-prefix in the page even if there are multiple sys_domains so that the page-admin can decide what should happen. A check if the current domain exists as sys_domain record (for that tree) should be enough to check against any security issues.
I noticed this behaving is switched in "tslib/class.tslib_content.php" within the function "typoLink".
I would like to know if there any reason to force the first domain to be the default without letting any choise by Typoscript (f.e. config.baseURL). It would make sense to give any chance for site-admins to choose this as any class extension or hard php-hack would not be a clean solution.
has patch: not yet
I would like to know if this feature request has any chance to become a core feature before investing time and money into making a patch.
(issue imported from #M14242)
Files
Updated by Chris topher almost 14 years ago
If you are not sure if you want to write a patch for this, you should ask in the dev mailing list.
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev
There you will get answers much more quickly than here.
It would be great, if you could report the result of such discussion or link the thread here.
Updated by Gabriel Kaufmann almost 14 years ago
@Christopher
Thanks for your reply. Since I am under time pressure for my current project I have not followed your tip to report and discuss yet.
Patch is provided by myself (see below).
---
After some more investigation I became more and more to the conclusion that the "usual" handling of sys_domains is not a feature, but a bug. The Checkbox "force" to prefix as default domain doesn't make any sense in my mind if there is no way to have any other domain except the first match in sys_domains for a PID.
This handling was essential to avoid a lot of time-wasting (for workarounds), so I decided to write a patch for it.
The patch will make changes to class.tslib_content.php within the function "typoLink". If there is more than one domain for a PID and the current domain is found in that PID this becomes the default domain if there is no "FORCE" parameter set for any other sys_domain record.
I hope this will help someone and it would be great to make this become part of the community edition for new TYPO3 releases! If this patch will not be taken for any reason to come into future versions there must be provided any other handy solution making this possible.
Best regards
Gabriel Kaufmann <info@typoworx.de>
Updated by Chris topher almost 14 years ago
If you want to have a fix like this included in TYPO3, please send your code changes to the core list.
Check out http://typo3.org/teams/core/core-mailinglist-rules/
Updated by Gabriel Kaufmann over 13 years ago
@Christoper
Thank you for the link regarding submitting the patch to the core-team. I will give it a try and submit a patch after reading the instructions given by the web-link.
Updated by Peter Niederlag over 12 years ago
- Target version deleted (
0)
Is this still an open issue?
Updated by Gabriel Kaufmann / Typoworx NewMedia over 12 years ago
Peter Niederlag wrote:
Is this still an open issue?
Hello,
yes it is. I just had a project with a actual TYPO3 4.5.x release that still has the issue. As I am very busy and don't have much know how on submitting/creating such patches. Would it help to submit the code that I changes to resolve the issue?
Updated by Alexander Opitz almost 11 years ago
Yes it would help. But it may take longer time to get solved.
Updated by Alexander Opitz over 10 years ago
- Status changed from Needs Feedback to Closed
- Is Regression set to No
No feedback for over 90 days.
Updated by Gerrit Code Review about 9 years ago
- Status changed from Closed to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38478
Updated by Gerrit Code Review about 9 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38478
Updated by Simon Schaufelberger about 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset d9d36bb2f0cba6f5da7ffc07bd01df9acf606c35.
Updated by Gerrit Code Review about 9 years ago
- Status changed from Resolved to Under Review
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38519
Updated by Gerrit Code Review almost 9 years ago
Patch set 2 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/38519
Updated by Riccardo De Contardi almost 9 years ago
- Status changed from Under Review to Closed