Summary
The v0.6.0 release ZIP contains Jetpack Autoloader classmap entries that point to files under tests/phpunit/, but the release ZIP excludes the tests/ directory.
This can cause fatal errors during normal WordPress web requests when another plugin checks for one of the mapped global classes.
Failure
For example, WPML calls:
class_exists( 'WP_CLI' );
The Jetpack Autoloader maps WP_CLI to:
$baseDir . '/tests/phpunit/Stubs/WpCliClasses.php'
That file is absent from the release ZIP, resulting in:
PHP Fatal error: Uncaught Error: Failed opening required
'.../mcp-adapter/tests/phpunit/Stubs/WpCliClasses.php'
in vendor/jetpack-autoloader/class-php-autoloader.php
This occurs during a regular web request; it does not require WP-CLI execution.
Reproduction
Download and extract the v0.6.0 release asset:
curl -L \
https://github.com/WordPress/mcp-adapter/releases/download/v0.6.0/mcp-adapter.zip \
-o mcp-adapter.zip
unzip mcp-adapter.zip
grep -n "WpCliClasses" \
mcp-adapter/vendor/composer/jetpack_autoload_classmap.php
test -e mcp-adapter/tests/phpunit/Stubs/WpCliClasses.php
The classmap contains entries for WP_CLI and WP_CLI_Command, while the final command confirms the referenced file is absent.
The generated classmap also contains many other entries referencing omitted tests/phpunit/ files.
Expected behavior
Production autoload metadata should not reference files excluded from the release artifact. On a web request, class_exists( 'WP_CLI' ) should return false when WP-CLI is unavailable instead of causing a fatal error.
Suspected cause
The root package defines:
"autoload-dev": {
"psr-4": {
"WP\\MCP\\Tests\\": ["tests/phpunit/"]
}
}
Jetpack Autoloader includes the root development autoload paths when generating its optimized classmap. The plugin ZIP then excludes tests/, leaving dangling classmap entries.
Suggested fix
Exclude tests from the production classmap:
"autoload": {
"psr-4": {
"WP\\MCP\\": "includes/"
},
"exclude-from-classmap": [
"/tests/"
]
}
Then regenerate the release artifact, ideally as v0.6.1.
It would also help to add a release check that verifies every path in vendor/composer/jetpack_autoload_classmap.php exists inside the completed ZIP.
Impact
We temporarily rolled back to v0.5.0 because activating v0.6.0 caused site-wide fatal errors on installations using WPML.
Summary
The v0.6.0 release ZIP contains Jetpack Autoloader classmap entries that point to files under
tests/phpunit/, but the release ZIP excludes thetests/directory.This can cause fatal errors during normal WordPress web requests when another plugin checks for one of the mapped global classes.
Failure
For example, WPML calls:
The Jetpack Autoloader maps
WP_CLIto:That file is absent from the release ZIP, resulting in:
This occurs during a regular web request; it does not require WP-CLI execution.
Reproduction
Download and extract the v0.6.0 release asset:
The classmap contains entries for
WP_CLIandWP_CLI_Command, while the final command confirms the referenced file is absent.The generated classmap also contains many other entries referencing omitted
tests/phpunit/files.Expected behavior
Production autoload metadata should not reference files excluded from the release artifact. On a web request,
class_exists( 'WP_CLI' )should returnfalsewhen WP-CLI is unavailable instead of causing a fatal error.Suspected cause
The root package defines:
Jetpack Autoloader includes the root development autoload paths when generating its optimized classmap. The plugin ZIP then excludes
tests/, leaving dangling classmap entries.Suggested fix
Exclude tests from the production classmap:
Then regenerate the release artifact, ideally as v0.6.1.
It would also help to add a release check that verifies every path in
vendor/composer/jetpack_autoload_classmap.phpexists inside the completed ZIP.Impact
We temporarily rolled back to v0.5.0 because activating v0.6.0 caused site-wide fatal errors on installations using WPML.