web-dev-qa-db-fra.com

WP cli --path ne semble pas fonctionner

WP-cli ne semble pas fonctionner lors de l'ajout d'un --path param

me@Host:~$ wp plugin status --path=`/home/me/domains/example.com/public_html`
-bash: /home/me/domains/example.com/public_html: is a directory
Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.

Si je cd dans le répertoire puis lance la commande sans le chemin, cela fonctionne.
J'ai wp-cli 0,25

Mettre à jour
Information supplémentaire lors de l'ajout d'un drapeau --debug

Debug (bootstrap): No readable global config found (0.031s)
Debug (bootstrap): No project config found (0.032s)
Debug (bootstrap): No package autoload found to load. (0.39s)
Debug (bootstrap): ABSPATH defined: /home/me/domains/example.com/public_html/ (0.39s)

Quelqu'un a une idée de ce que je fais mal?

wp-cli
4
janw

C'est comme si tu essayais de courir:

wp plugin status --path=$(/home/me/domains/example.com/public_html)

parce que ce qui est à l'intérieur des backticks est évalué.

Voici une bonne lecture sur l'utilisation de backticks dans la ligne de commande.

Permettez-moi de citer @rozcietrzewiacz :

Backtick n'est pas un signe de citation , il a une signification très spéciale. Tout ce que vous tapez entre les backticks est évalué (exécuté) par le shell avant la commande principale [...]

Alternatives:

wp plugin status --path=/home/me/domains/example.com/public_html
wp plugin status --path="/home/me/domains/example.com/public_html"
wp plugin status --path='/home/me/domains/example.com/public_html'

Lorsque j'utilise le fichier wp-skeleton setup, je dois pointer sur le dossier principal wp/, et non sur le dossier situé au-dessus, contenant le fichier wp-config.php.

Mettre à jour:

Dans la classe Runner , nous avons:

/**
 * Do WordPress core files exist?
 *
 * @return bool
 */
private function wp_exists() {
    return is_readable( ABSPATH . 'wp-includes/version.php' );
}

et quand on met ABSPATH avec

--path=/home/me/domains/example.com/public_html/

on dirait que nous utilisons:

/**
 * Set WordPress root as a given path.
 *
 * @param string $path
 */
private static function set_wp_root( $path ) {
    define( 'ABSPATH', rtrim( $path, '/' ) . '/' );
    WP_CLI::debug( 'ABSPATH defined: ' . ABSPATH, 'bootstrap' );
    $_SERVER['DOCUMENT_ROOT'] = realpath( $path );
}

et alors:

 is_readable( '/home/me/domains/example.com/public_html/wp-includes/version.php' )

devient faux car avec le wp-skeleton setup, le répertoire principal est:

/home/me/domains/example.com/public_html/wp/

Ce test est nécessaire mais non suffisant. Il existe d'autres tests, par exemple la méthode Runner::find_wp_root() .

La raison pour laquelle cela fonctionne quand OP est situé dans:

/home/me/domains/example.com/public_html/

cela peut être dû à la méthode Runner::extract_subdir_path() qui analyse le contenu du fichier index.php avec:

$index_code = file_get_contents( $index_path );

if ( !preg_match( 
         '|^\s*require\s*\(?\s*(.+?)/wp-blog-header\.php([\'"])|m', 
         $index_code, 
         $matches 
     ) 
) {
        return false;
}

pour obtenir le sous-répertoire où se trouve le fichier wp-blog-header.php et le définir comme $wp_path.

5
birgire