Actions
Bug #101195
openDataProcessing MenuProcessor can't handle Link to External URL without connection to a route page
Status:
New
Priority:
Should have
Assignee:
-
Category:
TypoScript
Target version:
-
Start date:
2023-06-29
Due date:
% Done:
0%
Estimated time:
TYPO3 Version:
11
PHP Version:
8.1
Tags:
Complexity:
Is Regression:
Yes
Sprint Focus:
Description
Setup¶
- TYPO3 v11.5.28
- multi page setup
- within the page tree a directory "MetaNavi" for the meta navigation besides the route pages, which holds the meta links for all websites
- Dataprocessor in TypoScript:
20 = TYPO3\CMS\Frontend\DataProcessing\MenuProcessor 20 { special = directory special.value := getEnv(GLOBAL_META_NAVI_PID) levels = 1 as = metaNavi expandAll = 1 titleField = nav_title // title }
- Simple template in Fluid:
<f:for each="{metaNavi}" as="metaNaviItem"> <a class="meta-link" href="{metaNaviItem.link}">{metaNaviItem.title}</a> </f:for>
Expectation¶
Links to internal and external URLs are resolved:
<a class="meta-link" href="/">Unternehmen</a>
<a class="meta-link" href="https://karriere.example.de/">Karriere</a>
<a class="meta-link" href="https://test.example.de/">Test</a>
<a class="meta-link" href="https://www.duckduckgo.com">External 1</a>
<a class="meta-link" href="https://www.google.com">External 2</a>
What happens¶
The external links are missing:
<a class="meta-link" href="/">Unternehmen</a>
<a class="meta-link" href="https://karriere.example.de/">Karriere</a>
<a class="meta-link" href="https://test.example.de/">Test</a>
<a class="meta-link" href="">External 1</a>
<a class="meta-link" href="">External 2</a>
What we know so far¶
- In TYPO3 v10 the described setup worked. After upgrading to v11 the meta navigation got broken.
- When debugging "{metaNavi.0}" within Fluid, the "link" property is empty, while within the {metaNavi.0.data.url} the external URL is available.
- When moving the directory "MetaNavi" into one of the available root pages, the external links are resolved correctly.
- I expect a bug within TypoScript, which is hard to debug for me. in d
Files
Updated by Torben Hansen 8 months ago
I can confirm the issue after updating from v10 to v11. Debugged this down to PageLinkBuilder::build()
function, where an exception is thown when the $siteOfTargetPage
can not be resolved. For pages, which link to pages in sites (e.g. through shourtcut), the target page is resolved, so those links are rendered ok. IMO, the whole $siteOfTargetPage == null
check should be surrounded by a condition which checks, that the current page is not an external link.
if ((int)$page['doktype'] === PageRepository::DOKTYPE_LINK) { if ($siteOfTargetPage == null) { throw new UnableToLinkException('Could not link to page with ID: ' . $page['uid'], 1546887172, null, $linkText); } ... } $treatAsExternalLink = true;
I however think it is better to just move such shared link folders into one site, so the PageLinkBuilder
can always resolve a valid $siteOfTargetPage
object.
Actions