Fix autoloader priority to prevent loading old framework classes from packages by Copilot · Pull Request #6243 · wp-cli/wp-cli

Copilot · 2026-02-14T22:30:37Z

Fix Error in readme generation workflow

The issue is caused by the autoloader loading 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. When PHP's autoloader tries to load a class:

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

Result: Old framework classes from package vendor directories are loaded instead of from the phar.

Solution:

Prepend the framework autoloader to the autoloader queue so it has priority over subsequently registered package autoloaders. This ensures framework classes from the phar are always loaded first, even if packages have old wp-cli/wp-cli versions in their vendor directories.

Changes:

Add $prepend parameter to Autoloader::register() method
Call $autoloader->register(true) in IncludeFrameworkAutoloader to prepend it
Add comprehensive Behat tests to verify the fix works correctly
Improve test to verify autoloader is in early queue position (0-2)
Run linting, code style and static analysis checks - all pass
Run autoloader priority tests - all 2 scenarios pass

Test Coverage:

The features/autoloader-priority.feature file includes 2 scenarios:

Verify framework autoloader is prepended - Checks that WP_CLI\Autoloader is registered in an early position (0-2) in the autoloader queue, ensuring it has priority over subsequently loaded package autoloaders
Old framework class should not break cmd-dump - Simulates a package with old RootCommand class and verifies it doesn't get loaded

All tests pass, confirming that the framework autoloader takes priority over package autoloaders.

Original prompt

This section details on the original issue you should resolve

<issue_title>Error in readme generation workflow</issue_title>
<issue_description>## Bug Report

Yes, I reviewed the contribution guidelines.
Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

https://github.com/wp-cli/language-command/actions/runs/9379802233/job/25825470872#step:12:114

Error:

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

Describe what you would expect as the correct outcome

Generate readme correctly

Let us know what environment you are running this on

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

</issue_description>

Comments on the Issue (you are @copilot in this section)

@swissspidy Previous lengthy discussion about this:

Update readme entity-command#501

It's not isolated to this package alone. Basically all packages are affected.

It seemed like an autoloader issue to me.

The readme generation workflow basically does this:

Install WP-CLI nightly phar
Run wp package install "wp-cli/scaffold-package-command:^2"
Regenerate readme

Now, scaffold-package-command requires framework version 2.11.x, which was done in wp-cli/scaffold-package-command#243. And the WP-CLI nightly phar also requires framework version 2.11.x

However, this particular command here does not.

So while in theory you would think the WP-CLI Phar loads the correct framework version, for some reason it loads classes from language-command/vendor/wp-cli/wp-cli/..., which is the old version.

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

That doesn't really make sense to me. Why is the Phar loading stuff from the current directory?

@schlessera Could you please enlighten us?</comment_new>
<comment_new>@BrianHenryIE
Is this happening only on GitHub or is it reproducible locally?

I had a very similar problem recently and came across others with also very similar problems: InterNACHI/modular#92 (comment)

I wouldn't be surprised if this is a Composer / GitHub Actions issue that will be fixed without changes on our end.</comment_new>

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.

codecov · 2026-02-14T22:32:45Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
php/WP_CLI/Autoloader.php	0.00%	2 Missing ⚠️
...hp/WP_CLI/Bootstrap/IncludeFrameworkAutoloader.php	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

…ages Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

Initial plan

c1cc903

Copilot AI assigned Copilot and swissspidy Feb 14, 2026

Copilot started work on behalf of swissspidy February 14, 2026 22:30 View session

github-actions bot added bug command:cli Related to 'cli' command command:cli-cmd-dump Related to 'cli cmd-dump' command command:cli-utils labels Feb 14, 2026

Initialize $hook property in RootCommand constructor

331063a

Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Fix error in readme generation workflow~~ Initialize $hook property in RootCommand constructor Feb 14, 2026

Copilot AI requested a review from swissspidy February 14, 2026 22:38

Copilot finished work on behalf of swissspidy February 14, 2026 22:38