Bug #16026
closed
special=directory does not include submenu entries
0%
Description
With a "special=directory" HMENU and a TMENU for menu.1 and menu.2, only the TMENU for menu.1 gets displayed, though documentation (TSref) says:
"NOTE: Don't set .entryLevel for a HMENU when using this option! Also be aware that this selects pages for the first level in the menu. Submenus by menuPbjects 2+ will be created as usual."
I've experienced the problem with Typo3 3.81, but just tested it with 4.0.
I've used the following template setup for the test with 4.0, which is simplified from the original template:
page = PAGE
page {
10 = HMENU
10 {
special = directory
special.value = 1
1 = TMENU
1{
NO {
allWrap = <li>|</li>
}
wrap = <ul>|</ul>
}2 = TMENU
2{
NO {
allWrap = <li> Second level:|</li>
}
wrap = <ul>|</ul>
}wrap = <div class="menu1">|</div>
}
}Attached is a screenshot of the pages in the backend.
"1.1" is ID 1, but if "1.1.1" is selected in the displayed menu, the subpages (1.1.1.1 and 1.1.1.2) get not shown.
We've tried to work around this, by setting "entryLevel = 2" (which is forbidden in the TSref), but though it initially worked, it produced totally empty content for this part of the page later.
"DEBUG information" (of the local 4.0 machine)- DEBUG SYSTEM INFORMATION - START ###
HTTP_HOST : t3.local
TYPO3_HOST_ONLY : t3.local
TYPO3_PORT :
PATH_INFO :
QUERY_STRING : TYPO3_INSTALL[type]=phpinfo
REQUEST_URI : /typo3/install/index.php?TYPO3_INSTALL[type]=phpinfo
HTTP_REFERER : http://t3.local/typo3/install/index.php?
TYPO3_REQUEST_HOST : http://t3.local
TYPO3_REQUEST_URL : http://t3.local/typo3/install/index.php?TYPO3_INSTALL[type]=phpinfo
TYPO3_REQUEST_SCRIPT: http://t3.local/typo3/install/index.php
TYPO3_REQUEST_DIR : http://t3.local/typo3/install/
TYPO3_SITE_URL : http://t3.local/
TYPO3_SITE_SCRIPT : typo3/install/index.php?TYPO3_INSTALL[type]=phpinfo
TYPO3_SSL :
SCRIPT_NAME : /typo3/install/index.php
TYPO3_DOCUMENT_ROOT : C:/usr/www/typo3
SCRIPT_FILENAME : C:/usr/www/typo3/typo3/install/index.php
REMOTE_ADDR : 127.0.0.1
REMOTE_HOST :
HTTP_USER_AGENT : Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
HTTP_ACCEPT_LANGUAGE: en,en-us;q=0.8,de-de;q=0.5,de;q=0.3
CONST: PHP_OS : WINNT
CONST: TYPO3_OS : WIN
CONST: PATH_thisScri: C:/usr/www/typo3/typo3/install/index.php
CONST: php_sapi_name: apache2handler
OTHER: TYPO3_VERSION: 4.0
OTHER: PHP_VERSION : 5.1.2
imagecreatefromgif(): 1
imagecreatefrompng(): 1
imagecreatefromjpeg(: 1
imagegif() : 1
imagepng() : 1
imagejpeg() : 1
imagettftext() : 1
OTHER: IMAGE_TYPES : 15
OTHER: memory_limit :
SERVER: SERVER_PORT : 80
SERVER: SERVER_SOFTW: Apache/2.0.55 (Win32) PHP/5.1.2
SERVER: GATEWAY_INTE: CGI/1.1
SERVER: SCRIPT_NAME : /typo3/install/index.php
SERVER: PATH_TRANSLA:
T3CV_GFX: image_proc: 1
T3CV_GFX: gdlib : 1
T3CV_GFX: gdlib_png : 0
T3CV_GFX: gdlib_2 : 0
T3CV_GFX: im : 1
T3CV_GFX: im_path : /usr/X11R6/bin/
T3CV_GFX: im_path_lz: /usr/bin/
T3CV_GFX: im_version:
T3CV_GFX: im_negate_: 0
T3CV_GFX: im_imvMask: 0
T3CV_GFX: im_combine: combine - DEBUG SYSTEM INFORMATION - END ###
(issue imported from #M3224)
Files
Updated by Axel Jindra about 18 years ago
This problem seems to depend on the entryLevel of the special=directory type. I've had the same problem as long as the special.value was a page in the 2nd level of the rootline. If I moved the pages one level up, the special.directory worked again.
As a workaround I used special=list and set the first level to doNotShowLink=1 ~:-(
Updated by Marc Bastian Heinrichs about 18 years ago
It's not a bug, it's a feature.
greets,
MB
Updated by old_blueyed about 18 years ago
Sorry for re-opening, but if this really is a feature and not a bug, then at least the documentation is misleading (which you've linked):
"Submenus by menuPbjects 2+ will be created as usual"
Nevertheless, I don't see why it should be a feature to limit the special=directory menu type to just one level, and only under certain conditions (see Axel's note).
Updated by Marc Bastian Heinrichs about 18 years ago
As usual means without any special option.
special=directory is the feature that you get only the level where pid = value and not more. Please ask on the mailinglist, if you have questions with this feature.
Updated by Axel Jindra about 18 years ago
I still do not agree because
a) it works for nested levels if for special=directory the special.value is a page on the first level of the tree
b) it worked at least in v. 3.7.1 (just checked) and the TSRef did not change at this point since then
c) special=list DOES work with nested levels from starting points deeper in the rootline, but according to your interpretation of TSRef shouldn't do,
so it IS worth a bug report.
Updated by old_blueyed about 18 years ago
Axel, I cannot confirm c) here: it also does not display entries "below" those listed in special.value for menuObj>1..
Updated by Axel Jindra about 18 years ago
well, I'm having c) up and running here, but maybe it works because the page on treeLevel 2 ($uid_menustart) has the "is root of website" attribute set?
lib.menuLeft {
special = list
special.value = {$uid_menustart}
1 = TMENU
1.NO.doNotShowLink = 1
2 = TMENU
2....
Updated by Franz Koch over 17 years ago
I don't understand for what reason the sublevels are limited in the core - besides it is nonsense in my eyes. If I don't need the sublevels I simply don't add them to my HMENU. This is really not the expected behaviour and I call it a bug. And it is a bug, because if I add "expAll = 1" to the first menu level the submenus are shown as expected.
Yes - the documentation says it fetches ONLY the pages with the given PID - but that means for the first level of the menu. It doesn't say that any sublevels are not fetched.
As workaround you can use conditions:
[PIDupinRootline = "pid of directory"]
lib.myMenu.special >
lib.myMenu.entryLevel = "corresponding level"
[/global]
Updated by 
Updated by Martin Ficzel over 17 years ago
i currently solved this problem with for me an a similar hack as described above
10 = HMENU
10.special = directory
10.special.value = 20
10.1 = TMENU
......
[PIDinRootline = 20]
10.special >
10.entryLevel = 1
[END]
it works but i have to say that i also expected the same behavior like alex. a directory is for me a tree structure. i would describe the current behavior as "special.subpages" not als "special.directory".
Updated by Noel Bossart almost 17 years ago
Hy there, I fully acknowledge with those, calling this a bug! And I don't understand why one would call this a feature (if one can achieve the same result with just leaving HMENU Level 2 and up empty, but no chance to the thing the other way around) and discussing it, instead of fixing this asap... Caus it's still present in Typo3 4.1.1 and it makes special = directory really useless!!!
Tank you Martin and Franz for the reported workarounds (and for reporting this bug too!). It was a gerat help to me!
Updated by Nils Clark-Bernhard almost 17 years ago
I would call this a bug, too. The param special=directory should indeed show the page structure below the entrypoint.
I recently set up a page with two different menu structures, both contained underneath two different pages (or directories). With the entrylevel set to 1, both menus worked fine, but did not show up on the home page. With the entrylevel set to 0, they showed up at home, but did not unfold their structure. So, this I would say is very well a bug.
How should a customer otherwise be able to dynamically create pages in one of those structures, without editing TypoScript menus. And content management is all about adding pages dynamically, right?
@martin ficzel : your hack works very well, thanks.for that.
So, if this IS a feature, and not a bug, I'd like to suggest adding a param to control the structure depth of that directory to be displayed, something like 'depth'.
Default value is '1', that is the current situation, integers greater then 1 for deeper level rendering, 0 for unlimeted.
Updated by Ulrich Fischer almost 17 years ago
100% ACK with Nils Clark-Bernhard.
Most people do not know this feature and wonder why they do not get submenues with "special = directory".
Updated by Georg Ringer over 16 years ago
so could this be changed? there is really a need to show level 2 menues with special = directory!
Updated by Georg Ringer over 16 years ago
ok just seen http://bugs.typo3.org/view.php?id=633
Updated by Oliver Hader almost 16 years ago
This issue was fixed in TYPO3 4.1.2.
Closed during Bug Day 07/2008