Bug #97037
open
Shortcut in menu to root page is always active
Added by extremo74 no-lastname-given about 2 years ago. Updated 4 months ago.
0%
Description
In version 11.5.6 and 11.5.7 the shortcut in the menu to the root page is always marked as active. (I use the MenuProcessor).
Also testet with a fresh installation of 11.5.7 with the Introduction Package. See my screenshot:
Customize is the real current page, and Home is marked as active too.
Files
| Bildschirmfoto 2022-02-25 um 11.17.04.png (545 KB) Bildschirmfoto 2022-02-25 um 11.17.04.png | extremo74 no-lastname-given, 2022-02-25 10:20 | ||
| pagetree.png (8.97 KB) pagetree.png | Sebastian Klein, 2022-08-18 18:16 |
Updated by extremo74 no-lastname-given about 2 years ago
- Category changed from Pagetree to Frontend
Updated by Larry Garfield about 2 years ago
I am seeing the exact same issue. In my case we're using bootstrap_package for the theme. Are you? (Trying to narrow down where the issue might be.)
Updated by Marcel Macasso about 2 years ago
- Related to Bug #97186: Menuprocessor shortcut active subpage wrong link state added
Updated by Larry Garfield about 2 years ago
Some results from spelunking through the code...
The active flag seems to be set in my case from AbstractMenuContextObject::isActive(). When processing the menu items, the Home item shows up in the $this->rL_uidRegister array. (Line 1450 in that file.) That then calls $typoScriptService->explodeConfigurationForOptionsSplit(), the result of which includes
$customConfiguration[0]['stdWrap']['cOobject.'][30] == ['value' => "1", wrap=","active":|"
That then overrides the entire item in $NOconf. I think that's where the extra active flag is coming from.
According to the docblock, $rL_uidRegister is the current rootLine, aka, the ancestors of the current page.
So that confirms this is the same issue as #97186. However, it seems from Benni's comments there to be "by design." So this is a knock-on effect of that design.
I am unclear how best to fix this, as it seems the behavior is both desired and not. Probably the ideal answer is to not use "active" at all for the ancestor links but some other class that can be styled or not, but that's a breaking change at this point.
Deferring to the maintainers here.
Updated by Marco Kuprat almost 2 years ago
I can confirm this bug is still present in TYPO3 11.5.13 and it occurs since TYPO3 11.5.5.
Tested it with MenuProcessor as well as plain TypoScript menu.
IMO this is a bug and a breaking change from 11.5.4 to 11.5.5; after all there are lots if webs out there which rely on the active state of a page in order to give them a different styling in the navigation.
Updated by Sebastian Klein over 1 year ago
- File pagetree.png pagetree.png added
I also consider the new behaviour a bug.
It is pretty common to have a shortcut that links to the rootpage, such as:
Home
- Home Shortcut
- a page below the shortcut
- Products
- About
– …
Former/old behaviour¶
- Shortcuts never had a
CURstate. - Shortcuts had an
ACTstate if a given child page was the currently viewed page. - You were able to add conditions to Fluid and TypoScript to get the
CURstate for shortcuts, e.g. with{f:if(condition: '({item.data.doktype} 4 && {item.data.shortcut} {data.uid})', then: 'current')}
New behaviour¶
- Shortcuts to Home always have an
ACTstate, regardless which page you are on. - Shortcuts to Home has a
CURstate if the rootpage is the current page.
Expected behaviour¶
- If on rootpage, a shortcut to this page should get the
CURstate. - If on any subpage below the shortcut, this shortcut should get the
ACTstate along the rootline. - If on any other page, the shortcut should neither get the
ACTnorCURstate.
Updated by Dmitry Dulepov over 1 year ago
Simply reverting a6593bd949 solves the issue.
Updated by Christian Welzel over 1 year ago
Is there any progress for fixing this?
Its very annoying and should not be changed in a minor release.
Updated by swanage no-lastname-given over 1 year ago
Christian Welzel wrote in #note-8:
Is there any progress for fixing this?
Its very annoying and should not be changed in a minor release.
I totally agree!!
Updated by Sybille Peters about 1 year ago
Link to previous change: https://github.com/TYPO3/typo3/commit/a6593bd949
Updated by Janosch Skrobek about 1 year ago
This is still a problem in 11.5.25 ... Will there be a fix?
Updated by Stefan Maischner 10 months ago
Still in 11.5.30.
Had to build some TS magic to workaround this issue. A bit frustrating why the behaviour was changed in the first place and why there is no signal to fix this.
Updated by Alex Nowak 5 months ago
Stefan Maischner wrote in #note-12:
Still in 11.5.30.
Had to build some TS magic to workaround this issue. A bit frustrating why the behaviour was changed in the first place and why there is no signal to fix this.
And HOW did you fix this?
Updated by Arne Bracht 4 months ago
Alex Nowak wrote in #note-13:
Stefan Maischner wrote in #note-12:
Still in 11.5.30.
Had to build some TS magic to workaround this issue. A bit frustrating why the behaviour was changed in the first place and why there is no signal to fix this.And HOW did you fix this?
I'm very interested in a solution or maybe a workarround Thx a lot