Menu manager error

[wiewied]

After updating to version 2.37, I get an HTTP ERROR 500 when trying to use the menu manager.

[e107help[bot]]

Welcome in, @wiewied.

One thing to check first, because I had almost this exact report four days ago (#5863): open your FTP client and look at the size of e107_handlers/menumanager_class.php. If it reads 0 bytes, that's your 500 right there.

Why that file and no other: a zero-length file still satisfies require_once, so PHP carries straight on and dies a couple of lines later on something that looks entirely unrelated. It only takes down the menu manager because that's the one admin page that loads the handler.

If it isn't zero, the next thing is the actual error message. An HTTP 500 is the web server hiding a PHP fatal, and the text of it is in your host's error log (on cPanel, Metrics → Errors, or an error_log file in your site root). One line from there and I can usually point at the file straight off.

One more thing so I'm not guessing: is it v2.3.7 you updated to?

[wiewied]

e107_handlers/menumanager_class.php thats right 0 byte, What steps should I take now?
One more thing so I'm not guessing: is it v2.3.7 you updated to? <----- yes after im update this version(v2.3.7)

[e107help[bot]]

That settles it, @wiewied. Same cause as #5863, and you're the second person it's caught, so this is getting fixed in core rather than left for people to patch by hand. More on that at the bottom.

Three steps, in this order:

1. Look at what else got hit, before you restore anything. Admin → Tools → File Inspector. It checksums every core file against the ones shipped with your version. If menumanager_class.php is the only thing flagged, this is a scanner false positive and step 3 sorts it. If a batch of files come back altered instead, stop there and say so here, because that's a different conversation.

2. Restore the file. Upload a fresh e107_handlers/menumanager_class.php from the v2.3.7 release over the empty one.

3. Allowlist it, or it will go again. This is the step that actually matters. Your host's malware scanner emptied that file because core code in it looks like a webshell, an eval() sitting near a base64_decode() of something off the query string. The scanner runs on a schedule, so it will empty your restored copy too. On cPanel it's usually Imunify360: find the file in its history and add it to the ignore list. If you can't see it, ask your host to whitelist that one path.

Something that'd help me confirm you're on the same trail: which scanner does your host run, and what reason did it log? @BillyBoy0823 on #5863 got SMW-INJ-CLOUDAV-php.webshell.eval-PHPTRP2-4, status "Content removed".

On the core side, Deltik has decided to fix this properly and it's intended for v2.3.11. The work is up as #5874: it rewrites the two bits of core the scanners object to, so the file stops looking dangerous in the first place. Once you're on that release the allowlist entry shouldn't be needed, though there's no harm leaving it.