Bug #16026

special=directory does not include submenu entries

Added by old_blueyed over 10 years ago. Updated about 8 years ago.

Status:Closed Start date:2006-04-10
Priority:Should have Due date:
Assigned To:- % Done:

0%

Category:Communication Spent time: -
Target version:-
TYPO3 Version:4.0 Complexity:
PHP Version:5 Is Regression:
Tags: Sprint Focus:

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)
  1. 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
  2. DEBUG SYSTEM INFORMATION - END ###
    (issue imported from #M3224)

directory_special_no_submenus.png (3.4 kB) Administrator Admin, 2006-04-10 17:26


Related issues

related to Core - Bug #20208: 00633 not fixed in latest versions of Typo3 Closed 2009-03-19
duplicated by Core - Feature #14463: Menu doesn't expand if ".special" is set Closed 2004-12-21

History

#1 Updated by Axel Jindra over 10 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 ~:-(

#3 Updated by old_blueyed over 10 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).

#4 Updated by Marc Bastian Heinrichs over 10 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.

#5 Updated by Axel Jindra over 10 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.

#6 Updated by old_blueyed over 10 years ago

Axel, I cannot confirm c) here: it also does not display entries "below" those listed in special.value for menuObj>1..

#7 Updated by Axel Jindra over 10 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....

#8 Updated by Franz Koch almost 10 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]

#9 Updated by Batomo almost 10 years ago

100% ACK with Franz-Xaver Koch.

#10 Updated by Martin Ficzel almost 10 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".

#11 Updated by Noel Bossart over 9 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!

#12 Updated by Nils Clark-Bernhard about 9 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.

#13 Updated by Ulrich Fischer about 9 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".

#14 Updated by Georg Ringer about 9 years ago

so could this be changed? there is really a need to show level 2 menues with special = directory!

#16 Updated by Oliver Hader about 8 years ago

This issue was fixed in TYPO3 4.1.2.
Closed during Bug Day 07/2008

Also available in: Atom PDF