Fix phar path resolution when WP_CLI_PHAR_PATH includes phar:// prefix#6242
Draft
Fix phar path resolution when WP_CLI_PHAR_PATH includes phar:// prefix#6242
Conversation
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
Copilot
AI
changed the title
[WIP] Fix wp-config.mustache is not a file in phar
Fix phar path resolution when WP_CLI_PHAR_PATH is undefined
Feb 14, 2026
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Copilot
AI
changed the title
Fix phar path resolution when WP_CLI_PHAR_PATH is undefined
Fix phar path resolution when WP_CLI_PHAR_PATH includes phar:// prefix
Feb 15, 2026
Copilot AI
added a commit
to wp-cli/wp-cli-bundle
that referenced
this pull request
Feb 19, 2026
Created php/utils-override.php with fixed phar_safe_path() that replaces full paths with alias 'phar://wp-cli.phar/' instead of bare 'phar://'. Include this override in boot-phar.php after wp-cli.php is loaded. This is a temporary fix until wp-cli/wp-cli#6242 is merged. Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
10 tasks
…defined This fixes the issue where wp config create --path=subfolder would fail when the phar file is not named wp-cli.phar. The function now properly uses Phar::running() to determine the phar file path instead of relying on the potentially undefined WP_CLI_PHAR_PATH constant. Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
…refix WP_CLI_PHAR_PATH is set to Phar::running(true) in wp-cli-bundle which includes the phar:// prefix. The function now strips this prefix before using it in the path replacement to avoid double-prefixing. Co-authored-by: swissspidy <841956+swissspidy@users.noreply.github.com>
5b3d2f4 to
0ffeaea
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
phar_safe_path()function fails when the phar is renamed (e.g.,wp-cli.phar→wp) because it incorrectly handles theWP_CLI_PHAR_PATHconstant. This constant is always defined in wp-cli-bundle asPhar::running(true), which includes thephar://prefix. The original code didn't account for this prefix, causing it to be prepended twice and creating malformed paths like:This causes
wp config create --path=subfolderto fail.Changes
phar_safe_path()to strip thephar://prefix fromWP_CLI_PHAR_PATHbefore using it in path replacementThe function now correctly extracts internal phar paths regardless of the phar filename:
See wp-cli/config-command#141
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
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
However, with just a cd to the subfolder, it works just fine:
Also, if I rename wp to wp-cli.phar, it works:
Describe what you would expect as the correct outcome
Let us know what environment you are running this on