WP cli --path nu pare să funcționeze
WP-cli nu pare să funcționeze când adaugi parametrul --path
me@host:~$ wp plugin status --path=`/home/me/domains/example.com/public_html`
-bash: /home/me/domains/example.com/public_html: este un director
Eroare: Acesta nu pare a fi o instalare WordPress.
Transmite --path=`calea/catre/wordpress` sau rulează `wp core download`.
Dacă intru cu cd
în director și apoi rulez comanda fără cale, funcționează.
Am wp-cli 0.25
Actualizare
Informații suplimentare când adaug steagul --debug
Debug (bootstrap): Nu s-a găsit nicio configurare globală citibilă (0.031s)
Debug (bootstrap): Nu s-a găsit nicio configurare de proiect (0.032s)
Debug (bootstrap): Nu s-a găsit niciun autoload de pachet de încărcat. (0.39s)
Debug (bootstrap): ABSPATH definit: /home/me/domains/example.com/public_html/ (0.39s)
Are cineva vreo idee ce fac greșit?

Este ca și cum ai încerca să rulezi:
wp plugin status --path=$(/home/me/domains/example.com/public_html)
deoarece ceea ce se află între backtick-uri este evaluat.
Aici este o lectură bună despre utilizarea backtick-urilor în linia de comandă.
Permiteți-mi să citesc @rozcietrzewiacz:
Backtick-ul nu este un semn de citare, are o semnificație foarte specială. Tot ceea ce scrieți între backtick-uri este evaluat (executat) de shell înainte de comanda principală [...]
Alternative:
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'
Când folosesc configurația wp-skeleton, trebuie să indic folderul de bază wp/
, nu folderul superior care conține fișierul wp-config.php
.
Actualizare:
În clasa Runner avem:
/**
* Există fișierele de bază WordPress?
*
* @return bool
*/
private function wp_exists() {
return is_readable( ABSPATH . 'wp-includes/version.php' );
}
iar când setăm ABSPATH
cu
--path=/home/me/domains/example.com/public_html/
se pare că folosim:
/**
* Setează root-ul WordPress ca o cale specificată.
*
* @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 );
}
și apoi:
is_readable( '/home/me/domains/example.com/public_html/wp-includes/version.php' )
devine fals deoarece în configurația wp-skeleton, directorul de bază este:
/home/me/domains/example.com/public_html/wp/
Acest test este necesar dar nu suficient. Există și alte teste, de exemplu metoda Runner::find_wp_root()
.
Motivul pentru care funcționează când OP este localizat în:
/home/me/domains/example.com/public_html/
ar putea fi datorat metodei Runner::extract_subdir_path()
care scanează conținutul fișierului index.php
cu:
$index_code = file_get_contents( $index_path );
if ( !preg_match(
'|^\s*require\s*\(?\s*(.+?)/wp-blog-header\.php([\'"])|m',
$index_code,
$matches
)
) {
return false;
}
pentru a obține subdirectorul unde se află fișierul wp-blog-header.php
și a-l seta ca $wp_path
.

Foarte enervant atunci că wp-cli sugerează asta în eroare. Dar nici una dintre variante nu funcționează :(

Da, este ciudat. Primești exact aceleași erori când încerci alternativele? @janw

Este la fel dar fără linia -bash: /home/me/domains/example.com/public_html/: is a directory
.

da, mă așteptam ca eroarea -bash să dispară acolo. Când folosesc configurația wp-skeleton, trebuie să indic folderul wp/core, nu folderul de deasupra care conține fișierul wp-config.php. Nu sunt sigur dacă folosești vreo configurație specială @janw

Da, folosesc un schelet. Adăugarea ...mple.com/public_html/wp
funcționează. Dacă vei adăuga această parte, voi accepta răspunsul
