Feature #80113
closed
f:link.page option for shortcuts
Added by Stephan Bauer over 7 years ago.
Updated about 2 years ago.
Description
f:link.page does not resolve shortcuts.
VHS menu viewhelper has a solution for this:
useShortcutData: Shortcut to set useShortcutTarget and useShortcutData simultaneously
useShortcutTarget: Optional param for using shortcut target instead of shortcut itself for current link
useShortcutUid: If TRUE, substitutes the link UID of a shortcut with the target page UID (and thus avoiding redirects) but does not change other data - which is done by using useShortcutData.
[[https://fluidtypo3.org/viewhelpers/vhs/master/Page/MenuViewHelper.html]]
Would it be possible to add an option like this to f:link.page also?
- Status changed from New to Needs Feedback
Is this issue still present on 9.5.x? I tried this short test:
1) Create a page "Test shortcut" (UID=4)
2) Create a page "Test target" (UID=5)
3) Edit the page created at point 1), change the type to "shortcut" and set the shortcut target to the page created at point 2)
4) On a Fluid Template / Partial use:
<f:link.page pageUid="4">page link </f:link.page>
Test Results:¶
the generated link is:
<a href="/test-target">page link</a>
Is this sufficient? Or a different test is required?
Riccardo De Contardi wrote:
Is this issue still present on 9.5.x? I tried this short test:
1) Create a page "Test shortcut" (UID=4)
2) Create a page "Test target" (UID=5)
3) Edit the page created at point 1), change the type to "shortcut" and set the shortcut target to the page created at point 2)
4) On a Fluid Template / Partial use:
[...]
Test Results:¶
the generated link is:
[...]
Is this sufficient? Or a different test is required?
Did a similar test here and the generated link is not the expected one.
1) page 10 of doktype 1 with slug "foo"
2) page 20 of doktype 4 with slug "bar" and shortcut_mode=0 and shortcut=10
<f:link.page pageUid="20">Hallo</f:link.page>
Desired result:
<a href="/foo">Hallo</a>
Actual result:
<a href="/bar">Hallo</a>
TYPO3 9.5.13
In single-tree at least a 301 is done. But with multi-tree it leads to a 404.
- Status changed from Needs Feedback to New
- Status changed from New to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Related to Bug #96078: Shortcut Info-Message incorrect when page refers to frontend-restricted page added
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by Anonymous 
Updated by 
Updated by