Project

General

Profile

Actions

Bug #77296

closed

TMENU - get the parentMenuArr in itemArrayProcFunc - broken

Added by Stefan Bürk over 7 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
Start date:
2016-07-28
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:
On Location Sprint

Description

Hi there,

after upgrading from 6.2.25 to 7.6.9/7.6.10 our TMENU itemArrayProcFunc stopped working probably.
Not the function itself, but in it we used the parentMenuArr from the parentObj to determine the ITEM_STATE of the parent menu item, which this TMENU and items belongs to.

Given following abstract Menu TS CONF


HMENU {

  1 = TMENU
  1 {}

  2 = TMENU
  2 {}

  3 = TMENU
  3 = {
     itemArrayProcFunc = myUserFunc
  }
}

For the 3rd level, we must do things based on the ITEM_STATE of the parentMenuItem from Level 2.
Not even that, also clearing the menuArr under some cirtumstances (flags in extension based fields) if parent state have specified flags etc.

To visualize this a little bit:

1.1                      
  1.1.2.1
  1.1.2.2
    1.1.2.2.3.1       NO
    1.1.2.2.3.2       NO
  1.1.2.3             
    1.1.2.3.3.1       IF(1.1.2.3 ITEMSTATE === ACTIVE/CURRENT) THEN USERDEF1, OTHERWISE USERDEF2    
    1.1.2.3.3.1       IF(1.1.2.3 ITEMSTATE === ACTIVE/CURRENT) THEN USERDEF1, OTHERWISE USERDEF2

Okay, if you have to just render all Level2/3 Menu's in the same way for each parentLeven, than no user func is needed really ..
but if you want to render items for level based on the direct parent menu item item state, what than ?

I found no other solutions for that, so reimplementing the parentMenuArr behaviour was the only situation for our case ... are we so special ?

In the past (Typo 6.2.25) we had the following pseudo code in the userFunc to get the ITEM_STATE of the parent menuItem.

function($menuArr, $conf) {

  $parentItem = NULL;
  if (is_array($conf['parentObj']->parentMenuArr) && count($conf['parentObj']->parentMenuArr) > 0) {
    foreach($conf['parentObj']->parentMenuArr AS $menuItem) {
      if ($menuItem['uid'] === $conf['parentObj']->id) {
        $parentItem = $menuItem;
        break; // end the loop, we have what we wanted.
      }
    }
  }

  if (is_array($parentItem) && isset($parentItem['ITEM_STATE'])) {

    // loop through menuArr and do some special settings to the ITEM_STATE's and override virtually the titles

  }
}

After debugging a lot, i'm ended up looking into the typo core and the functions for the menu rendering stuff.

See https://review.typo3.org/#/c/36584/5/typo3/sysext/frontend/Classes/ContentObject/Menu/AbstractMenuContentObject.php LINE 458-460 in the old code.

In Typo 7.6.9 source and in current master, there was a lot changed in that class.
I think that 3 liner was dropped, because that property was not defined and even more, not returning an array every time. Maybe it was also removed, because the core itselfs do not need this -- but for userland functions this could be a usefull information.

I'm calling this a bug .. because removing this "public" property was not mentioned anywhere and broke's userland code.

Instead of simply readding the code, it should be done in proper way:

- not providing an public accessible property
- using setter/getter and returning always an array, an empty one if no parent level exists ( menu level 1 ).
- adding a function to just get the direct menuItem to prevent the need to loop through the parentMenuArray for each sublevel itemArrayProcFunc call, to optimize performance

Any suggestions welcome ;) I'm going to provide an patch for this bug, with the stated "improvements" instead of simply readding this.


Files

tmenu_test_0.0.1.zip (7.19 KB) tmenu_test_0.0.1.zip Testextension for this issue Stefan Bürk, 2016-08-03 21:31
Actions

Also available in: Atom PDF