mirror of
https://ghproxy.net/https://github.com/wp-cli/wp-cli-bundle.git
synced 2026-07-26 12:36:57 +08:00
A Phar renamed away from `wp-cli.phar` used to build malformed template paths when generating a wp-config.php for an install in another directory via --path, failing with "wp-config.mustache is not a file in phar". Add a Bootstrap scenario that copies the freshly built Phar to a name without an extension and runs `config create --path=subfolder` against a separate install, so the fixed behavior is locked in and regressions are caught. The fix itself lives in wp-cli/wp-cli's Path::phar_safe(), which the bundled Phar picks up through the framework. See wp-cli/config-command#141.
100 lines
3.2 KiB
Gherkin
100 lines
3.2 KiB
Gherkin
Feature: Bootstrap WP-CLI
|
|
|
|
Scenario: Override command bundled with freshly built PHAR
|
|
|
|
Given an empty directory
|
|
And a new Phar with the same version
|
|
And a cli-override-command/cli.php file:
|
|
"""
|
|
<?php
|
|
if ( ! class_exists( 'WP_CLI' ) ) {
|
|
return;
|
|
}
|
|
$autoload = dirname( __FILE__ ) . '/vendor/autoload.php';
|
|
if ( file_exists( $autoload ) ) {
|
|
require_once $autoload;
|
|
}
|
|
WP_CLI::add_command( 'cli', 'CLI_Command', array( 'when' => 'before_wp_load' ) );
|
|
"""
|
|
And a cli-override-command/src/CLI_Command.php file:
|
|
"""
|
|
<?php
|
|
class CLI_Command extends WP_CLI_Command {
|
|
public function version() {
|
|
WP_CLI::success( "WP-Override-CLI" );
|
|
}
|
|
}
|
|
"""
|
|
And a cli-override-command/composer.json file:
|
|
"""
|
|
{
|
|
"name": "wp-cli/cli-override",
|
|
"description": "A command that overrides the bundled 'cli' command.",
|
|
"autoload": {
|
|
"psr-4": { "": "src/" },
|
|
"files": [ "cli.php" ]
|
|
},
|
|
"extra": {
|
|
"commands": [
|
|
"cli"
|
|
]
|
|
}
|
|
}
|
|
"""
|
|
And I run `composer install --working-dir={RUN_DIR}/cli-override-command --no-interaction 2>&1`
|
|
|
|
When I run `{PHAR_PATH} cli version`
|
|
Then STDOUT should contain:
|
|
"""
|
|
WP-CLI
|
|
"""
|
|
|
|
When I run `{PHAR_PATH} --require=cli-override-command/cli.php cli version`
|
|
Then STDOUT should contain:
|
|
"""
|
|
WP-Override-CLI
|
|
"""
|
|
|
|
Scenario: Template paths should be resolved correctly when PHAR is renamed
|
|
|
|
Given an empty directory
|
|
And a new Phar with the same version
|
|
And a WP installation
|
|
And I run `wp plugin install https://github.com/wp-cli-test/generic-example-plugin/releases/download/v0.1.1/generic-example-plugin.0.1.1.zip --activate`
|
|
And I run `wp plugin deactivate generic-example-plugin`
|
|
|
|
When I run `php {PHAR_PATH} plugin status generic-example-plugin`
|
|
Then STDOUT should contain:
|
|
"""
|
|
Plugin generic-example-plugin details:
|
|
Name: Example Plugin
|
|
Status: Inactive
|
|
"""
|
|
And STDERR should be empty
|
|
|
|
When I run `cp {PHAR_PATH} wp-renamed.phar`
|
|
And I try `php wp-renamed.phar plugin status generic-example-plugin`
|
|
Then STDOUT should contain:
|
|
"""
|
|
Plugin generic-example-plugin details:
|
|
Name: Example Plugin
|
|
Status: Inactive
|
|
"""
|
|
And STDERR should be empty
|
|
|
|
Scenario: Config template resolves when the PHAR is renamed and run against another path
|
|
|
|
# Reproduces the reported failure: a Phar renamed away from `wp-cli.phar`
|
|
# (here without an extension) generating a wp-config.php for an install in a
|
|
# different directory via --path. See https://github.com/wp-cli/config-command/issues/141
|
|
Given an empty directory
|
|
And a new Phar with the same version
|
|
|
|
When I run `cp {PHAR_PATH} wp-renamed`
|
|
And I run `php wp-renamed core download --path=subfolder`
|
|
And I run `php wp-renamed config create --path=subfolder --dbname=wordpress --dbuser=root --dbpass=password --skip-check`
|
|
Then STDOUT should contain:
|
|
"""
|
|
Success: Generated 'wp-config.php' file.
|
|
"""
|
|
And STDERR should be empty
|