Fix phar path resolution when renamed from wp-cli.phar

[Copilot]

Note

EDIT (2026-07-21): Reworked and rebased onto the current main. This PR now contains only the Bootstrap regression test: it copies the freshly built Phar to a name without an extension and runs config create --path=subfolder against a separate install, reproducing the reported failure.

Dropped from the earlier approach:

• The php/boot-phar.php change (Phar::running( true ) → false). The fix now lives entirely in Fix phar path resolution when WP_CLI_PHAR_PATH includes phar:// prefix wp-cli#6242's Path::phar_safe(), which handles WP_CLI_PHAR_PATH whether it is a bare path or a phar:// URL, so no bundle code change is needed. Keeping Phar::running( true ) also avoids changing the value wp cli info reports.
• The cweagans/composer-patches plugin and patch file, and the temporary wp-cli/wp-cli branch pin plus the resulting composer.lock churn. This PR carries no dependency changes.

Merge sequencing: the fix ships in wp-cli/wp-cli#6242. Once that is merged and the framework is bumped in this repo (the usual update-framework flow), this scenario goes green. It may be red until then, which is expected for a companion test.

Original description (now outdated)

Fix phar path resolution when phar file is not named "wp-cli.phar"

Problem

When running wp config create --path=subfolder ... with a phar file named something other than "wp-cli.phar" (e.g., "wp"), the path resolution fails with a malformed path error. Additionally, template loading fails with "Couldn't find plugin-status.mustache" errors.

Root Cause

Two issues were present:

1. WP_CLI_PHAR_PATH was set using Phar::running(true) which returns "phar:///path/to/file.phar", causing phar_safe_path() to search for the malformed string "phar://phar:///path/to/file.phar/"
2. phar_safe_path() in wp-cli/wp-cli was replacing full paths with bare "phar://" instead of the alias "phar://wp-cli.phar/", causing template paths like "phar://vendor/..." which don't resolve without an archive name

Solution

1. Changed WP_CLI_PHAR_PATH in boot-phar.php to use Phar::running(false) which returns the filesystem path without phar:// protocol (e.g., "/path/to/file.phar")
2. Added cweagans/composer-patches plugin to apply a patch to wp-cli/wp-cli's phar_safe_path() function
3. Created patches/wp-cli-phar-safe-path.patch that fixes the replacement to use 'phar://wp-cli.phar/' instead of bare 'phar://'

This ensures:

• phar_safe_path() correctly converts "phar:///tmp/some.phar/vendor/..." to "phar://wp-cli.phar/vendor/..."
• Template paths resolve correctly via the alias regardless of the actual phar filename
• Both the original bug (malformed paths with --path flag) and template loading errors are fixed

Changes Made

• Fix WP_CLI_PHAR_PATH to use Phar::running(false) in boot-phar.php
• Add cweagans/composer-patches plugin to composer.json
• Create patches/wp-cli-phar-safe-path.patch to fix phar_safe_path()
• Update composer.lock to apply patch during install
• Keep WP_CLI_ROOT using phar alias for template resolution
• Pass linting and code style checks
• Build and test phar with renamed file
• Verify template paths resolve correctly

Note

The patch will be removed once the fix in wp-cli/wp-cli#6242 is merged and the dependency is updated. The patch is automatically applied during composer install and modifies the vendored wp-cli/wp-cli code at build time.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>wp-config.mustache is not a file in phar</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

When wp-cli.phar is renamed to wp and moved into a path location, --path option seems to have conflict with wp create command. This has been reported before (#31)

Describe how other contributors can replicate this bug

• a list of
• steps to replicate
• the error condition

$ curl -Lso ~/.local/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
$ chmod +x ~/.local/bin/wp
$ wp core download --path=subfolder
Downloading WordPress 5.9 (en_US)...
md5 hash verified: b2ed7e1e6cf834564273f5b4581afd29
Success: WordPress downloaded.
$ wp config create --path=subfolder --dbname=mydb --dbuser=myuser --dbpass=mypass --skip-check --force
PHP Warning:  file_get_contents(phar://wp-cli.phar/vendor/wp-cli/wp-cli/templates/phar://.local/bin/wp/vendor/wp-cli/config-command/templates/wp-config.mustache): failed to open stream: phar error: "vendor/wp-cli/wp-cli/templates/phar:/.local/bin/wp/vendor/wp-cli/config-command/templates/wp-config.mustache" is not a file in phar "wp-cli.phar" in phar:///home/interface/.local/bin/wp/vendor/wp-cli/wp-cli/php/utils.php on line 577
Error: Could not create new 'wp-config.php' file.

However, with just a cd to the subfolder, it works just fine:

$ cd subfolder
$ wp config create --dbname=mydb --dbuser=myuser --dbpass=mypass --skip-check --force
Success: Generated 'wp-config.php' file.

Also, if I rename wp to wp-cli.phar, it works:

$ mv ~/.local/bin/wp ~/.local/bin/wp-cli.phar
$ wp-cli.phar config create --path=subfolder --dbname=mydb --dbuser=myuser --dbpass=mypass --skip-check --force
Success: Generated 'wp-config.php' file.

Describe what you would expect as the correct outcome

Success: Generated 'wp-config.php' file.

Let us know what environment you are running this on

OS:	Linux 3.10.0-1160.53.1.el7.x86_64 wp-cli/config-command#1 SMP Fri Jan 14 13:59:45 UTC 2022 x86_64
Shell:	/bin/bash
PHP binary:	/opt/rh/rh-php73/root/usr/bin/php
PHP version:	7.3.29
php.ini used:	/etc/opt/rh/rh-php73/php.ini
MySQL binary:	/opt/rh/rh-mariadb10...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

- Fixes wp-cli/config-command#141

<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for you](https://github.com/wp-cli/wp-cli-bundle/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo.


</details>


<!-- This is an auto-generated comment: release notes by coderabbit.ai -->

## Summary by CodeRabbit

* **Bug Fixes**
  * Added coverage for using a renamed PHAR without a file extension.
  * Verified that configuration creation succeeds in a specified subdirectory and produces no unexpected error output.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: acdc0d8e-d3b5-41e4-841d-db6b380cf300

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• ✅ Review completed - (🔄 Check again to review again)

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch copilot/fix-wp-config-mustache-file

---

_{Comment @coderabbitai help to get the list of available commands.}

[swissspidy]

Closing as per latest update on wp-cli/wp-cli#6242

[swissspidy]

Actually, still needed because of the test.