[mastacontrola]

This is the fix that was supposed to be in #1544 and wasn't. The merge queue snapshotted that branch before the second commit reached it, so #1544 merged only the getClass() gate repair and left this behind. working-1.6 is currently a blank 500 on every page for anyone who installs it.

The bug

class Config is generated by the installer into commons/config.class.php. It is the one .class.php file left anywhere in a deployed tree — the only class in FOG that is neither PSR-4 under src/ nor inside a plugin — so it was being reached by the autoloader's recursive *.class.php scan of BASEPATH. #1540 retired that scan, and this was the single thing it was still carrying:

Uncaught Error: Class "Config" not found in commons/init.php:1383

on every page. A blank white page in a browser, and installfog.sh's own "Checking web server serves FOG" step failing with curl exit 22, 0 bytes of body.

Required by name now, the same way fogpaths.php already is in _loadPaths() — a generated file at a fixed path gets pulled in, not found. A missing one names itself and says to re-run the installer, rather than dying three lines later on a class nobody can locate.

config.class.php was the only casualty: find over an installed webroot returns exactly one .class.php outside lib/plugins, and it has exactly one reference in the tree.

Why nothing caught it

Every PHP test in the suite constructs Initiator — which only registers the autoloader — and stops before startInit(), because startInit() wants a database. The whole boot tail had no coverage at all.

tests/generated-config-is-loaded.test.sh closes that without a database, by driving commons/base.inc.php in a tree whose config.class.php is a stub and asserting on which error comes back: the guard fires and names the file when it is absent, and the boot reaches PDODB when it is present — which is the proof that Config resolved.

It boots through base.inc.php rather than management/index.php deliberately. index.php reaches its includes as ../commons/..., which PHP resolves against the real path, so a fixture that symlinks management/ runs against the repository's own commons/ and never sees the stub. My first cut did exactly that and passed for the wrong reason.

Mutation-verified four ways, all red: require deleted; require pointed at a misspelled filename; require moved after the use; is_readable guard inverted. The last three are what a textual check for "require_once near new Config()" would have waved through.

Verified on top of current working-1.6 (c812eb352): suite 246/0, phpstan clean.