What would cause menumanager_class.php to become 0 length? It's happened twice now.

[BillyBoy0823]

I am on 2.37 Been running well, but I went to edit menu's and I got an error. And the menu.php page would not load. I look in the error log and get a message;

[01-Aug-2026 14:39:57 America/New_York] PHP Fatal error:  Uncaught Error: Class "form" not found in /home/vitalog1/gameplayas.com/e107_admin/menus.php:685
Stack trace:
#0 {main}
  thrown in /home/vitalog1/gameplayas.com/e107_admin/menus.php on line 685

That leads me to menumanager_class.php which turned out to be ZERO length.

It's happened twice now, and can't figure out what is making it Zero. Once I restore it, things work fine, for a while.

Any Ideas?

[e107help[bot]]

@BillyBoy0823, I think I can tell you why it's that file and no other.

Nothing in core writes to e107_handlers/menumanager_class.php. I went through the file-writing calls across the handlers and the admin pages, and every one of them lands in the log, cache, system, media or language folders. So e107 isn't emptying it. Something outside e107 is.

Now, why that file. It's the only core handler that contains all of this at once:

• base64_decode($_GET['enc']) fed straight into parse_str()
• eval() on the contents of a file, twice

Base64-decoded input off the query string, plus eval(), in one file, is the textbook fingerprint of a PHP backdoor. Shared-host malware scanners (Imunify360/ImunifyAV, cxs, ClamAV's PHP-shell signatures) match on exactly that shape. Some quarantine the file; others "clean" it, and a clean that strips everything it matched leaves you with zero bytes. Then the scanner runs again on its schedule, finds the copy you restored, and does it a second time. That fits "restore it, things work fine, for a while" better than anything else I can come up with.

Three things to do, cheapest first.

1. Ask your host to check the malware scanner's history and quarantine log for that file, around 1 August and around whenever the first one happened. One line back from them settles it.
2. Run Admin → Tools → File Inspector before you restore anything else. It md5s every core file against the checksums shipped with your version, so it will tell you whether this file is the only thing that's off. If it is, a scanner false positive on core code is the likely story and your host can whitelist it. If a batch of core files come back altered instead, don't shrug that one off, bring it back here and we'll work through it properly.
3. Check the Last Modified timestamp on the empty file in cPanel's File Manager next time it goes. Overnight or on the hour points at something scheduled (scanner, backup). During one of your own uploads points at a transfer that opened the file and then dropped, which also leaves exactly 0 bytes, and would rhyme with the part-copied e107_web/ from I need help - issue with my move from local to my host #5762.

On the error message itself, so it doesn't send you the wrong way next time. Class "form" not found is a red herring. That legacy form class lives at the bottom of form_handler.php, and menus.php never loads that file. What loads it is the very first line of code inside menumanager_class.php, an e107::getForm() call at line 13. Empty the handler and require_once still succeeds, quietly, so two lines later new form is what falls over and it names a file with nothing to do with the problem. Zero-length include, misleading fatal.

I'm passing three items to Deltik as possible core work: a class_exists() guard so that error names the real culprit, whether the enc= base64 wrapper needs to exist at all (it's only hiding lay=...&vis=...&iframe=1), and whether the legacy theme.php layout parser still needs eval(). Core looking like a webshell to a scanner is something we can fix on our side. All three are his call.

Let me know what the host comes back with.

[BillyBoy0823]

There is a LOT on the hosts I never use. I have “Imunify360” via cPanel. Here's what it gave me for a reason and status on e107_handlers/menumanager_class.php

Reason: SMW-INJ-CLOUDAV-php.webshell.eval-PHPTRP2-4

Status: Content removed

[Deltik]

#5865 should solve this by making e107_handlers/menumanager_class.php look less dangerous to virus scanners.

Note that I am not planning to backport this to e107 v2.3, and it is intended to land in e107 v2.4. I recommend allowlisting the file in Imunify360 while you're on e107 v2.3.

[Deltik]

Now that there's a second report of the same problem and I don't want to play Whac-A-Mole with Imunify360, I am tasking @e107help to backport #5865 to the e107 v2.3 track. I now intend to land a fix in e107 v2.3.11.

[BillyBoy0823]

Thanks! It did happen to 4 of my sites. SO I Have whitelisted menumanager_class.php