Bug #15717
closed
t3lib_pageSelect::getMenu() needs more database columns than it specifies
0%
Description
In the past I only specified the actual fields I needed to the $fields parameter of getMenu, and hadn't had any issues. Testing some of my extensions against 4.0.0b3 has caused getMenu() to only return a single top-level sysfolder when I specify pid 0, rather than the entire visible root level tree.
I discovered by passing it '*' instead of a limited set of fields I got the correct result again, and noticed the comment:
// $row MUST have "uid", "pid", "doktype", "mount_pid", "mount_pid_ol" fields in it
In this particular case $fields = uid,doktype,title so I added mount_pid and mount_pid_ol, but I still only got the single sysfolder.
I believe it's an issue with mountpoints (I have none on this site), and that getMenu() actually requires more fields than it specifies. This is actually really annoying, because I'd like to be able to just select the fields I need, especially since my plugin is feeding the tree out as XML and therefore I want to minimise the fields being transferred.
I suggest that getMenu() automatically adds any additional fields that it needs internally to the SELECT query, but unsets them from the result row that gets returned.
Code that returned the wrong result:
$branch = $sysPageObj->getMenu(0, 'uid,title,doktype');
Code that returned the right result:
$branch = $sysPageObj->getMenu(0, '*');
reset($branch);
while (list($key) = each($branch)) {
$branch[$key] = array('uid' => $branch[$key]['uid'], 'doktype' => $branch[$key]['doktype'], 'title' => $branch[$key]['title']);
}
(issue imported from #M2688)
Updated by Wolfgang Klinger over 18 years ago
I had no problems with this little test script here and the latest source from CVS:
--------
class user_scripts {
function test($content, $conf) {
$branch = $GLOBALS['TSFE']->sys_page->getMenu(0, 'uid,title,doktype');
print_r($branch);
}
}
--------
includeLibs.test = fileadmin/user_scripts.php
page.30 = USER
page.30.userFunc = user_scripts->test
--------
I got the first page of the tree (as expected), I don't know what the problem is?
This method never returns a "tree" but only subpages of the specified page (first parameter) and you don't need to specify any additional fields either (if you don't use mount pages).
Updated by Neil Bertram over 18 years ago
I think I tracked down the problem now. There's a difference between using $GLOBALS['TSFE']->sys_page and using
$sysPageObj = t3lib_div::makeInstance('t3lib_pageSelect');
$sysPageObj->init(true);
Interestingly $GLOBALS['TSFE']->sys_page->getMenu(0, 'uid,doktype,title'); actually returns an empty array, but if I add 'shortcut' to the field list, I get my site root (which is a shortcut). I still think this behaviour is peculiar. For my purposes I think I'll switch to querying the site tree with manual SELECT statements, getMenu() is a bit too quirky for me, and I need an exact representation of the tree without resolving shortcuts and applying overlays.
This behaviour has changed since 3.8.0 though.