Power menu allows menu links to be fieldable by creating entities for them. The problem is entities can not be safely stored in $_SESSION. It will cause a nasty "Call to undefined function entity_get_info()" on every page. See http://drupal.stackexchange.com/questions/69824/session-breaks-entity-api .

I dunno if this is something to commit but I'll post a patch for anybody who needs to use this with power menu.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jmuzz’s picture

The patch.

jmuzz’s picture

FileSize
665 bytes

This one should be applied to power menu. It removes some functionality but the menu edit form can not be submitted without this change.

callinmullaney’s picture

FileSize
488 bytes

Thank you jmuzz for the patch. I know this is an old issue but this specific use case came up recently for a client. I've re-rolled the patch against the latest dev so we can apply via composer. This appears to resolve the incompatibility we were experiencing prior to the patch.

Also, the power menu patch attached in #2 is no longer necessary. That line is active in the latest beta release of that module.

micnap’s picture

Adding to Callin's patch:

When a new translation for a menu item's content gets saved, the ENTIRE link array was getting saved to the session and was causing a fatal error. Since only one small piece of the array - the created timestamp - gets used, there's no need to save the entire array. This patch changes what gets saved in the session to just the created timestamp.

generalredneck’s picture

This patch changes what gets saved in the session to just the created timestamp.

So your patch doesn't actually save to the session. This line

+    $$_SESSION['content_menu_inserted_links'][$link['mlid']]['created'] = $link['created'];

Actually saves to a variable that is the contents of $_SESSION since you are using the variable variable syntax of $$

That said, this should also fatal if the variable starts with a number, is null, or violates a number of other rules... In this case it's likely creating a variable named $Array

Additionally, if you DID mean to use variable variable, you have an issue with ambiguity here... Here's an excerpt from the PHP manual

In order to use variable variables with arrays, you have to resolve an ambiguity problem. That is, if you write $$a[1] then the parser needs to know if you meant to use $a[1] as a variable, or if you wanted $$a as the variable and then the [1] index from that variable. The syntax for resolving this ambiguity is: ${$a[1]} for the first case and ${$a}[1] for the second.

see https://www.php.net/manual/en/language.variables.variable.php

generalredneck’s picture

The whole point of the code we are changing is strictly to set a class on a row in a table. That said, we don't need to save anything about the Menu Link at all... so I simplified the code and fixed the variable variable typo as well.

We run across a problem that a translation entity was still linked to the menu item, so this isn't a "power menu" specific problem. $link was still being stored to the session for all patches before #4 which caused problems with the session being unserialized like indicated in the original description.

Since the $link isn't being used fro any other reason than to see if the created time was within the 60 second window to highlight the table row green, I just changed the code where we wouldn't have to even worry about the extraneous key or store any piece of $link to the session at all.. Just imply store the created time directly to the session to avoid any of the issues here.