Bug #17730
closedoptionSplit for nested / recursive HMENU
0%
Description
Any optionSplit applied to a nested (i.e. recursive) HMENU menu object will not be evaluated at right scope but on scope of outermost HMENU.
Could be solved in class.t3lib_tstemplate.php
What is a nested/recursive HMENU and how do I create one?
Image you have a TMENU and some configuration (not functional, just a scheme) like
TMENU {
NO {
stdWrap.cObject = HMENU
stdWrap.cObject {
1 = TMENU
1 {
wrapItemAndSub = |*|<li class="odd">|</li> || <li class="even">|</li> |*|
}
}
}
}
Meaning that you want to create a TMENUITEM as another HMENU and within this (nested) HMENU you want to perform an optionSplit into even and odd items.
You soon will recognize that this doesn't work as expected, since the optionSplit is resolved based on the items at outermost HMENU.
This is because t3lib_tstemplate->splitConfArray resolves optionSplits recursively as soon as an array with such splits is passed to it (which is the case at the outermost HMENU).
The attached patch stops recurisve replacement of optionSplits, if they are within a HMENU configuration array. These arrays represent a nested HMENU and should be evaluated later when building this nested menu.
(issue imported from #M6605)
Files