The readme generation workflow fails because the autoloader loads old framework classes from package vendor directories instead of from the WP-CLI phar.

Root Cause

When WP-CLI runs from a phar and loads packages (e.g., scaffold-package-command), those packages may have their own vendor/wp-cli/wp-cli directory with old framework code. The autoloader registration order causes the issue:

1. Framework autoloader is registered (appended to end of queue)
2. Package Composer autoloader is registered (appended to end of queue, now has priority)

This results in old framework classes from package vendor directories being loaded instead of from the phar, leading to errors like "Call to undefined method WP_CLI\Dispatcher\RootCommand::get_hook()".

Changes

Autoloader Priority Fix (Primary)

• Modified Autoloader::register(): Added optional $prepend parameter to support prepending the autoloader to the queue
• Updated IncludeFrameworkAutoloader: Now calls $autoloader->register(true) to prepend the framework autoloader

This ensures framework classes from the phar are always loaded first, even when packages have old wp-cli/wp-cli versions in their vendor directories.

// In Autoloader.php
public function register( $prepend = false ) {
    spl_autoload_register( [ $this, 'autoload' ], true, $prepend );
}

// In IncludeFrameworkAutoloader.php
$autoloader->register( true );  // Prepend to give priority

Backward Compatibility Fix

• Initialize $hook = '' in RootCommand::__construct(): Ensures backward compatibility for any code that might instantiate RootCommand directly or when older framework versions are temporarily loaded

Test Coverage

• Added features/autoloader-priority.feature: Comprehensive Behat tests with 3 scenarios to verify the fix:
  1. Verify framework autoloader is prepended - Checks that WP_CLI\Autoloader is registered in the autoloader queue
  2. Old framework class should not break cmd-dump - Simulates a package with an old RootCommand class (without get_hook()) in its vendor directory and verifies the framework version from the phar is loaded instead
  3. Framework classes work correctly with get_hook() method - Verifies RootCommand has get_hook() and returns the correct empty string value

Testing

• ✅ All linting, code style, and static analysis checks pass
• ✅ All unit tests pass (52 CommandFactory tests)
• ✅ All CLI feature tests pass (4 scenarios, 20 steps)
• ✅ All autoloader priority tests pass (3 scenarios, 18 steps)
• ✅ Manual verification confirms wp cli cmd-dump works correctly
• ✅ Code review found no issues
• ✅ Security scan found no issues

The fix properly addresses the autoloader conflict, ensuring that framework classes from the phar are always loaded first, regardless of what packages have in their vendor directories. The new tests prevent regressions by simulating real-world scenarios where packages might have outdated wp-cli/wp-cli dependencies.

PHP Fatal error:  Uncaught Error: Call to undefined method WP_CLI\Dispatcher\RootCommand::get_hook() in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/commands/src/CLI_Command.php:42

OS:	Darwin 22.6.0 Darwin Kernel Version 22.6.0: Mon Apr 22 20:54:28 PDT 2024; root:xnu-8796.141.3.705.2~1/RELEASE_X86_64 x86_64
Shell:	/bin/zsh
PHP binary:	/usr/local/bin/php
PHP version:	8.2.19
php.ini used:	/usr/local/etc/php/8.2/php.ini
MySQL binary:	/usr/local/mysql-8.0.36-macos14-x86_64/bin/mysql
MySQL version:	mysql  Ver 8.0.36 for macos14 on x86_64 (MySQL Community Server - GPL)
SQL modes:	
WP-CLI root dir:	/Users/nilambarsharma/Code/wp-cli-dev/wp-cli
WP-CLI vendor dir:	/Users/nilambarsharma/Code/wp-cli-dev/wp-cli/vendor
WP_CLI phar path:	
WP-CLI packages dir:	/Users/nilambarsharma/.wp-cli/packages/
WP-CLI cache dir:	/Users/nilambarsharma/.wp-cli/cache
WP-CLI global config:	
WP-CLI project config:	/Users/nilambarsharma/Sites/staging/wp-cli.local.yml
WP-CLI version:	2.11.0-alpha

PHP Fatal error:  Uncaught Error: Call to undefined method WP_CLI\Dispatcher\RootCommand::get_hook() in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/commands/src/CLI_Command.php:42
Stack trace:
wp-cli/wp-cli#0 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/commands/src/CLI_Command.php(555): CLI_Command->command_to_array()
wp-cli/language-command#1 [internal function]: CLI_Command->cmd_dump()
wp-cli/language-command#2 /home/runner/work/language-command/language-command/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/CommandFactory.php(100): call_user_func()
wp-cli/language-command#3 [internal function]: WP_CLI\Dispatcher\CommandFactory::WP_CLI\Dispatcher\{closure}()
wp-cli/language-command#4 /home/runner/work/language-command/language-command/vendor/wp-cli/wp-cli/php/WP_CLI/Dispatcher/Subcommand.php(497): call_user_func()
wp-cli/language-command#5 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(441): WP_CLI\Dispatcher\Subcommand->invoke()
wp-cli/language-command#6 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/class-wp-cli.php(1394): WP_CLI\Runner->run_command()
wp-cli/language-command#7 /home/runner/.wp-cli/packages/vendor/wp-cli/scaffold-package-command/src/ScaffoldPacka in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/commands/src/CLI_Command.php on line 42

• Fixes Error in readme generation workflow #5968

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.