Cet article a été réactualisé il y a 4 ans jours. Il n'est pas nécessairement obsolète, mais gardez son ancienneté en tête lors de sa lecture.
Pour se familiariser avec les commandes WP-CLI, on peut le faire dans une installation de site WordPress qu’on a mis en place dans Local by Flywheel (LBFW)
Accéder au Docker contenant son site local en SSH
Dans l’interface LBFW
- Lancer le site voulu : Start site
- Clic droit sur le nom du site et choisir : Open Site SSH
- Une interface en ligne de commande s’ouvre
Dans la CLI
Où se situe le site ?
Un site dans LBFW est toujours présent dans : /app/public
Exemple d’un site sur lequel je travaille : (ls
pour lister le contenu des dossiers, cd
pour s’y rendre)
root@b439d0d00bc6:/# ls
app conf home media proc run sys var
bin dev lib mnt redis-stable.tar.gz sbin tmp wp-cli.yml
boot etc lib64 opt root srv usr
root@b439d0d00bc6:/# cd app
root@b439d0d00bc6:/app# ls
public sql
root@b439d0d00bc6:/app# cd public
root@b439d0d00bc6:/app/public# ls
Makefile wp-activate.php wp-cron.php wp-signup.php
humans.txt wp-admin wp-includes wp-snapshots
index.php wp-blog-header.php wp-links-opml.php wp-trackback.php
license.txt wp-comments-post.php wp-load.php xmlrpc.php
local-adminer-ryAzMMBAb.php wp-config-sample.php wp-login.php
eadme.html wp-config.php wp-mail.php
robots.txt wp-content wp-settings.php
Voir la version de WP-CLI préinstallée dans LBFW
Au niveau de l’instance du site, utiliser la commande simplifiée qui est disponible pas besoin de faire mais juste php wp-cli.phar --info
wp --info
root@b439d0d00bc6:/app/public# wp --info
PHP binary: /opt/php/7.0.3/bin/php
PHP version: 7.0.3
php.ini used: /conf/php/7.0.3/php.ini
WP-CLI root dir: phar://wp-cli.phar
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /app/public
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config: //wp-cli.yml
WP-CLI version: 1.4.1
On a à disposition la version WP-CLI 1.4.1 , comme elle est un peu ancienne on peut la mettre à jour pour la version stable plus récente.
Faire une MAJ de la version WP-CLI
Choisir la dernière version stable : wp cli update --stable
root@b439d0d00bc6:/app/public# wp cli update --stable
You have version 1.4.1. Would you like to update to the latest stable release? [y/n] y
Downloading from https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar...
md5 hash verified: 07b2ebef5d8b944e50e71896593f94a4
New version works. Proceeding to replace.
Success: Updated WP-CLI to the latest stable release
Vérifier la nouvelle version à disposition :
root@b439d0d00bc6:/app/public# wp --info
OS: Linux 4.9.93-boot2docker #1 SMP Thu May 10 16:27:54 UTC 2018 x86_64
Shell:
PHP binary: /opt/php/7.0.3/bin/php
PHP version: 7.0.3
php.ini used: /conf/php/7.0.3/php.ini
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: /app/public
WP-CLI packages dir:
WP-CLI global config:
WP-CLI project config //wp-cli.yml
WP-CLI version: 2.0.1
On est passé à la version WP-CLI 2.0.1
Expérimenter !
Il suffit maintenant de se faire la main en consultant la documentation WP-CLI.
Petite précision à noter
Quand on développe ses sites sous LBFW, chaque site se trouve dans un container Docker. L’utilisateur du container est forcément root par défaut. Ceci implique que tous les fichiers de sites ont des permissions à 777 ( rwxrwxrwx). Les processus sont éxécutés en tant que root et sans avoir besoin de spécifier de mot de passe. Il n’y a pas de user.
Pour autant les commandes WP-Cli fonctionnent très bien sans l’affichage de l’alerte : « Error: YIKES! It looks like you’re running this as root. »
Pourquoi WP-Cli nous affiche normalement une alerte quand on l’éxécute en tant que root ? Tout simplement à cause des permissions trop élevées. Si on utilise WP-Cli dans ces conditions tout ce qui sera généré, que ce soit les plugins, thèmes etc … auront tous les privilèges. Dans un container Docker c’est un fonctionnement normal. Sur un serveur d’hébergement c’est forcément une faille de sécurité majeure. Si du code malveillant est présent dans l’instance de WordPress, et qu’on modifie les fichiers en tant que root, on rendra un fichier malicieux potentiellement présent éxécutable …
Message complet de l’alerte WP-Cli :
Error: YIKES! It looks like you're running this as root. You probably meant to run this as the user that your WordPress install exists under.
If you REALLY mean to run this as root, we won't stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.
If you'd like to continue as root, please run this again, adding this flag: --allow-root
If you'd like to run it as the user that this site is under, you can run the following to become the respective user:
sudo -u USER -i -- wp <command>
Dans un container LBFW un alias est d’emblée ajouté au niveau de /root/.bashrc. Si vous l’éditez vous aurez un contenu tel que celui ci :
# ~/.bashrc: executed by bash(1) for non-login shells.
# Note: PS1 and umask are already set in /etc/profile. You should not
# need this unless you want different defaults for root.
# PS1='${debian_chroot:+($debian_chroot)}\h:\w\$ '
# umask 022
# You may uncomment the following lines if you want `ls' to be colorized:
# export LS_OPTIONS='--color=auto'
# eval "`dircolors`"
# alias ls='ls $LS_OPTIONS'
# alias ll='ls $LS_OPTIONS -l'
# alias l='ls $LS_OPTIONS -lA'
#
# Some more alias to avoid making mistakes:
# alias rm='rm -i'
# alias cp='cp -i'
# alias mv='mv -i'
alias wp="wp --allow-root"
Avec LBFW, les commandes wp
sont toutes lancées en autorisant root, CQFD.