[fabiankaegy]

Description of the Change

Module discovery tokenizes every PHP file in a directory on each request wherever the runtime cache can't be written. On WordPress VIP that's every request, because should_use_cache() returns false there.

This backports the read side of #35 to 1.x, without its breaking change:

• vendor/bin/tenup-framework-generate-class-cache <dir> [<dir> …] writes <dir>/class-loader-cache/class-loader-cache-v2.php. The command and generate_cache() are Make the class-loader cache build-time and add a loader debug page #35's, unchanged.
• get_classes() reads that file when it exists, on any host, VIP included, through Make the class-loader cache build-time and add a loader debug page #35's ReadOnlyFileDiscoverCacheDriver. It never writes it.
  • A file that fails to load (truncated deploy, not an array) fires tenup_framework_cache_load_failed and falls back to discovery, as in Make the class-loader cache build-time and add a loader debug page #35.
  • TENUP_FRAMEWORK_DISABLE_CLASS_CACHE ignores it.
• Without that file, nothing changes. should_use_cache() and the runtime cache are exactly as in 1.3.1. That's what keeps this out of 2.0.0: no site changes behaviour until it adds the build step.

The command name, cache directory, filename and cache ID match feature/2.0.0 (CACHE_DIR_NAME, CACHE_FILENAME, CACHE_ID). A project that adds the build step for 1.x keeps it unchanged through the 2.0.0 upgrade, and 2.0.0 then removes the runtime writes.

Not included from #35: the loader debug page, runtime-cache removal, the #30 fix and the upgrade docs. Those stay in 2.0.0.

Why now

The fueled.com 2026 build runs 19 framework-based plugin and theme directories on VIP. Measured locally against copies of those directories, with VIP_GO_APP_ENVIRONMENT defined:

	Time per request
Discovery (today on VIP)	264.6 ms
Reading the prebuilt cache	0.65 ms

Every directory returned the same class list either way. On fdc, plugin loading plus init is ~0.65 s of a ~1 s uncached request.

How to test the Change

1. composer test on PHP 8.4: 28 tests pass, including the new PrebuiltClassCacheTest. It covers:

   • a generate-then-read round trip;
   • reading with VIP_GO_APP_ENVIRONMENT defined;
   • no cache on VIP: discovery runs and nothing is written;
   • corrupt and non-array cache files falling back (and the action firing);
   • the disable constant;
   • the command end to end, including exit code 1 without arguments;
   • the read-only driver never creating its directory.

   The suite errors on PHP 8.5 before any test runs, inside antecedent/patchwork, unrelated to this change.

2. composer lint and composer static are clean. phpcs.xml gets Make the class-loader cache build-time and add a loader debug page #35's exclusion for direct filesystem calls in tests/.

3. In a project: run vendor/bin/tenup-framework-generate-class-cache path/to/src, define VIP_GO_APP_ENVIRONMENT, and check that get_classes() returns the cached list without discovering.

Changelog Entry

Added - vendor/bin/tenup-framework-generate-class-cache builds a class-loader cache at build time, and get_classes() reads it on any host, WordPress VIP included.

Credits

Props Daryll Doyle and Ryan Leeson: the driver, command and cache format are from #35/#36.

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests pass.