Bug #59204
Shortcut's itemState in menu should be »STATE_ACTIVE« if subpage is selected.
| Status: | Resolved | Start date: | 2014-05-29 | |
|---|---|---|---|---|
| Priority: | Must have | Due date: | ||
| Assigned To: | Marc Neuhaus | % Done: | 100% |
|
| Category: | - | |||
| Target version: | Base Distribution - 1.x | Estimated time: | 0.25 hour |
Description
In my page tree I have a shortcut with subpages that links to the first subpage like this:
- 1. page
- 2. page
- shortcut to first subpage
- 1. subpage
- 2. subpage
- 3. subpage
If the first subpage is selected, the shortcut AND the subpage gain the state »STATE_CURRENT«. If the second subpage is selected, the shortcut is »STATE_NORMAL«. In both cases the shortcut should have the state »STATE_ACTIVE«.
This is due to a mistake in the »MenuImplementation«. Line 266 is:
$item['state'] = $this->calculateItemState($possibleFinalNode);
should be:
$item['state'] = $this->calculateItemState($currentNode);
History
#1 Updated by Christian Müller about 1 year ago
- Status changed from New to Needs Feedback
Hi Björn, I would like to discuss the behavior with you.
Actually this is made on purpose. If you have a footer menu consisting only of shortcuts that link to some other pages those footer links can never be STATE_CURRENT, which is also bad. What would you suggest to solve both cases?
I will bring this also up in our technical discussion meetings. Feel free to join in http://wiki.typo3.org/TYPO3_Neos-DiscussionMeetings
IMHO both are valid cases, maybe we need to make that selectable for every shortcut?
#2 Updated by Björn Klusekemper about 1 year ago
Hi Christian,
thanks for your answer. I was able to discuss this with Marc today on a long car ride ;-) My first thought about this was: "Why not decide which use case we have by determining whether or not the shortcut is in the page root of the target page?" But this is thought short because in a project we did together a few years ago we had a use case in a very content heavy website where we used content related shortcuts to "jump" between parts of the page tree. There it would have been fatal if the shortcuts itself would have gained the state STATE_CURRENT.
After then discussing what the term "shortcut" means to us, we both came to the conclusion that to us a shortcut is more likely to be used in the use case I described in the issue and that your described use case is more like an "alias" or "mount point". So maybe an additional note type "alias" that describes your use case is necessary?!
Feel free to discuss this on your next Discussion Meeting. Unfortunately I can not attend because I'll be on vacation.
#3 Updated by Bastian Waidelich about 1 year ago
- Only one (document) node can be CURRENT at a time, it's the one that is being rendered
- All parent nodes of the current one are ACTIVE independently from it's type (e.g. including shortcuts, no matter where they point to)
- All other nodes have a state NORMAL
That means, we can probably remove some logic from \TYPO3\Neos\TypoScript\MenuImplementation.
For marking a a node active that is not in the current "rootline" we'd need to be able to create "alias nodes" (or reference nodes) via the UI.
#4 Updated by Aske Ertmann about 1 year ago
- Status changed from Needs Feedback to Resolved
- % Done changed from 0 to 100
Should have been solved with https://review.typo3.org/#/c/30857/