Une fenêtre de terminal stylisée affiche la commande « ./WP-CLI » en grand texte blanc, indiquant un audit de profil WordPress pour les problèmes de performances. À droite, un bonhomme allumette rouge s'exécute. La fenêtre comporte une barre de titre bleue et une icône de fermeture.

Auditer les problèmes de performance WordPress avec wp profile

La commande wp profile est un peu comme une alternative à New Relic, capable d’identifier précisément quels composants ralentissent votre site WordPress. Initialement disponible en tant que package premium via runcommand, il est désormais gratuit sur GitHub.

Si vous cherchez un hébergeur compatible avec l’installation de wp profile, jetez un œil à Kinsta et FastNyx.

J’utilise régulièrement wp profile pour diagnostiquer les problèmes de performance chez mes clients sur Codeable. Tous les développeurs WordPress devraient s’en servir ! Après avoir suivi ce guide, vous serez plus proche de la résolution de la lenteur de votre site WordPress.

Un site WordPress lent peut avoir mille causes : plugin trop lourd, thème bavard, requêtes SQL répétées, cache objet absent, option autoloadée énorme, appel HTTP externe, hook mal placé, ou simple hébergement à bout de souffle.

La mauvaise méthode consiste à désactiver des plugins au hasard et à espérer que le site accélère. La bonne méthode consiste à mesurer. C’est précisément là que wp profile devient très utile.

wp profile est une commande WP-CLI qui mesure les grandes étapes du chargement WordPress. Elle permet de repérer les stages, hooks, plugins et thèmes qui consomment le plus de temps. Ce n’est pas un profiler aussi profond que Blackfire, Xdebug ou New Relic, mais c’est souvent suffisant pour trouver où commencer.

Lire la suite

Une fenêtre de terminal stylisée affiche la commande « ./WP-CLI » en grand texte blanc. À côté, une flèche bleue pointant vers le bas pointe vers une barre horizontale verte, suggérant un téléchargement ou une installation via SSH. L'arrière-plan est gris foncé.

Installer WP-CLI sans accès root ni sudo

WP-CLI est l’un des meilleurs outils pour administrer WordPress proprement. Il permet de mettre à jour le core, gérer les extensions, exporter la base, vider le cache, chercher-remplacer des URLs, diagnostiquer un site cassé et automatiser des tâches sans passer par l’administration WordPress.

Le problème : sur un hébergement mutualisé ou un serveur client verrouillé, vous n’avez pas toujours accès à sudo. Impossible donc de placer wp dans /usr/local/bin. Bonne nouvelle : ce n’est pas bloquant.

Dans ce guide, nous allons installer WP-CLI sans accès root, directement dans votre compte utilisateur, avec un dossier ~/bin, un PATH propre, une vérification du téléchargement et quelques commandes de test. Le tout sans sudo, sans magie noire, et sans supplier l’hébergeur.

Dans quels cas installer WP-CLI sans root ?

Cette méthode est utile lorsque vous avez un accès SSH, mais pas les privilèges administrateur.

  • hébergement mutualisé avec SSH ;
  • compte client limité ;
  • serveur où sudo est interdit ;
  • environnement de staging isolé ;
  • compte utilisateur dédié par site ;
  • serveur cPanel, Plesk ou panel maison ;
  • besoin d’une version WP-CLI différente de celle du système.

L’installation locale a aussi un avantage : elle ne touche pas au système global. Vous pouvez mettre à jour WP-CLI pour votre compte sans impacter les autres utilisateurs. C’est propre, isolé, et généralement accepté par les hébergeurs qui fournissent SSH.

Pré-requis

Avant de commencer, vérifiez que vous avez :

  • un accès SSH ;
  • PHP disponible en ligne de commande ;
  • curl ou wget ;
  • un dossier personnel accessible en écriture ;
  • un site WordPress existant pour tester.

WP-CLI demande PHP 7.2.24 ou plus récent. En pratique, utilisez une version PHP maintenue par votre hébergeur, idéalement la même branche que celle utilisée par votre site WordPress. :contentReference[oaicite:1]{index=1}

Vérifiez la version PHP CLI :

php -v

Vérifiez aussi que PHP sait lancer un fichier PHAR :

php -m | grep -i phar

Si rien ne sort, l’extension PHAR peut être désactivée. Dans ce cas, il faudra choisir une autre version PHP CLI ou demander à l’hébergeur de l’activer.

Créer un dossier ~/bin pour vos commandes utilisateur

Le dossier ~/bin est un emplacement classique pour installer des commandes accessibles uniquement à votre utilisateur.

mkdir -p ~/bin

Vérifiez si ce dossier est déjà dans votre PATH :

echo "$PATH" | tr ':' '\n' | grep "$HOME/bin"Langage du code : PHP (php)

Si la commande ne retourne rien, ajoutez ~/bin à votre PATH.

Pour Bash :

echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrcLangage du code : PHP (php)

Pour Zsh :

echo 'export PATH="$HOME/bin:$PATH"' >> ~/.zshrc
source ~/.zshrcLangage du code : PHP (php)

Si vous ne savez pas quel shell vous utilisez :

echo "$SHELL"Langage du code : PHP (php)

Sur certains hébergements, le shell charge plutôt ~/.profile. Dans ce cas :

echo 'export PATH="$HOME/bin:$PATH"' >> ~/.profile
. ~/.profileLangage du code : PHP (php)

Télécharger WP-CLI dans ~/bin

Téléchargez le PHAR officiel :

curl -fsSL -o ~/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.pharLangage du code : JavaScript (javascript)

Rendez-le exécutable :

chmod 755 ~/bin/wpLangage du code : JavaScript (javascript)

Testez :

wp --info

Si tout fonctionne, vous devriez voir les informations WP-CLI, PHP, MySQL, le shell utilisé et le chemin du fichier wp.

La documentation officielle recommande exactement cette logique : télécharger wp-cli.phar, vérifier qu’il fonctionne avec PHP, le rendre exécutable, puis le placer dans un dossier du PATH. :contentReference[oaicite:2]{index=2}

Vérifier le téléchargement de WP-CLI

Pour une installation rapide, le téléchargement direct suffit souvent. Pour une installation plus rigoureuse, vérifiez l’intégrité ou la signature du fichier.

WP-CLI documente deux méthodes : la vérification GPG, plus forte, et la vérification par checksum SHA-512 ou SHA-256. La vérification GPG confirme l’intégrité et l’authenticité, tandis qu’un checksum confirme seulement que le fichier correspond au hash publié. :contentReference[oaicite:3]{index=3}

Option 1 : vérification GPG

Téléchargez le PHAR et sa signature dans un dossier temporaire :

mkdir -p ~/tmp/wp-cli-verify
cd ~/tmp/wp-cli-verify

curl -fsSLO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
curl -fsSLO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar.ascLangage du code : JavaScript (javascript)

Importez la clé publique WP-CLI :

curl -fsSL https://raw.githubusercontent.com/wp-cli/builds/gh-pages/wp-cli.pgp | gpg --importLangage du code : JavaScript (javascript)

Vérifiez la signature :

gpg --verify wp-cli.phar.asc wp-cli.pharLangage du code : CSS (css)

Si la signature est bonne, installez le fichier :

cp wp-cli.phar ~/bin/wp
chmod 755 ~/bin/wp
wp --infoLangage du code : JavaScript (javascript)

Un avertissement indiquant que la clé n’est pas certifiée localement peut apparaître. Le point important est la présence de Good signature. Pour une chaîne de confiance complète, il faut vérifier l’empreinte de la clé selon la procédure officielle.

Option 2 : vérification SHA-512

Si GPG n’est pas disponible sur l’hébergement, utilisez le checksum SHA-512 :

mkdir -p ~/tmp/wp-cli-verify
cd ~/tmp/wp-cli-verify

curl -fsSLO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
curl -fsSLO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar.sha512

sha512sum wp-cli.phar
cat wp-cli.phar.sha512Langage du code : JavaScript (javascript)

Les deux empreintes doivent correspondre exactement. Ensuite :

cp wp-cli.phar ~/bin/wp
chmod 755 ~/bin/wpLangage du code : JavaScript (javascript)

Ne vous embêtez pas avec MD5 pour ce type de vérification. La documentation WP-CLI le publie encore pour compatibilité, mais indique que MD5 n’est pas recommandé pour la sécurité. :contentReference[oaicite:4]{index=4}

Tester WP-CLI sur un site WordPress

Placez-vous dans la racine du site WordPress :

cd ~/www/example.com/public_htmlLangage du code : JavaScript (javascript)

Adaptez le chemin à votre hébergement. Ensuite :

wp core version
wp option get home
wp option get siteurl
wp plugin listLangage du code : JavaScript (javascript)

Si WP-CLI répond, l’installation est bonne.

Vous pouvez aussi vérifier l’intégrité des fichiers WordPress officiels :

wp core verify-checksums

Cette commande compare les fichiers du core avec les checksums WordPress.org et s’exécute avant le chargement complet de WordPress, ce qui la rend utile pour diagnostiquer des fichiers modifiés ou corrompus. :contentReference[oaicite:5]{index=5}

Si wp n’est pas trouvé : corriger le PATH

Si cette commande échoue :

wp --info

avec :

wp: command not foundLangage du code : HTTP (http)

vérifiez que le fichier existe :

ls -l ~/bin/wpLangage du code : JavaScript (javascript)

Vérifiez le PATH :

echo "$PATH" | tr ':' '\n'Langage du code : PHP (php)

Testez avec le chemin complet :

~/bin/wp --infoLangage du code : JavaScript (javascript)

Si le chemin complet fonctionne, le problème vient seulement du PATH. Ajoutez ~/bin au bon fichier de profil : ~/.bashrc, ~/.zshrc, ~/.profile ou parfois ~/.bash_profile.

Si WP-CLI utilise la mauvaise version de PHP

Sur les hébergements mutualisés, la version PHP du terminal n’est pas toujours celle du site web. C’est un classique.

Vérifiez PHP en CLI :

php -v
which php

Si votre hébergeur fournit plusieurs binaires PHP, cherchez-les :

ls /usr/bin/php*
ls /opt/*/php*/bin/php 2>/dev/null
ls /usr/local/bin/php* 2>/dev/nullLangage du code : JavaScript (javascript)

Exemples fréquents selon l’hébergeur :

/usr/bin/php8.2
/usr/bin/php8.3
/opt/alt/php83/usr/bin/php
/usr/local/php83/bin/php

Vous pouvez créer un wrapper local qui force une version PHP précise.

Déplacez d’abord le PHAR :

mv ~/bin/wp ~/bin/wp-cli.pharLangage du code : JavaScript (javascript)

Créez le wrapper :

cat > ~/bin/wp <<'EOF'
#!/usr/bin/env bash
exec /usr/bin/php8.3 "$HOME/bin/wp-cli.phar" "$@"
EOF

chmod 755 ~/bin/wpLangage du code : JavaScript (javascript)

Adaptez /usr/bin/php8.3 au chemin réel de PHP sur votre hébergement.

Testez :

wp --info

Dans la sortie, vérifiez la ligne PHP binary et la version PHP.

Installer WP-CLI sous un nom alternatif

Certains hébergements fournissent déjà une commande wp, parfois ancienne ou cassée. Dans ce cas, installez votre version sous un autre nom, par exemple wp-local.

curl -fsSL -o ~/bin/wp-local https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod 755 ~/bin/wp-local
wp-local --infoLangage du code : JavaScript (javascript)

Ensuite, utilisez :

wp-local plugin list
wp-local core version
wp-local db export ~/backup.sqlLangage du code : JavaScript (javascript)

C’est parfois plus propre que d’écraser ou masquer un binaire fourni par l’hébergeur. Cela évite aussi les surprises après mise à jour du panel.

Utiliser WP-CLI sans être dans la racine WordPress

Si vous lancez WP-CLI depuis un autre dossier, utilisez --path avec la racine WordPress :

wp --path="$HOME/www/example.com/public_html" core versionLangage du code : JavaScript (javascript)

Attention : --path doit pointer vers le dossier qui contient wp-config.php, wp-content, wp-admin et wp-includes. Pas vers wp-content/plugins, pas vers uploads, pas vers un dossier au hasard parce qu’il “avait l’air WordPress”.

Créer un fichier wp-cli.yml local

Pour éviter de retaper certains paramètres, vous pouvez créer un fichier wp-cli.yml à la racine du site.

cd ~/www/example.com/public_html
nano wp-cli.ymlLangage du code : JavaScript (javascript)

Exemple simple :

path: .
url: https://www.example.comLangage du code : HTTP (http)

Pour un multisite ou un environnement staging, ce fichier peut éviter des erreurs d’URL. Gardez-le toutefois lisible et ne stockez pas de secrets dedans.

Mettre à jour WP-CLI sans root

Si vous avez installé le PHAR dans ~/bin/wp, vous pouvez tenter :

wp cli update

Mais selon les permissions et l’emplacement, je préfère une mise à jour explicite :

curl -fsSL -o ~/bin/wp.new https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php ~/bin/wp.new --info
chmod 755 ~/bin/wp.new
mv ~/bin/wp.new ~/bin/wp
wp --infoLangage du code : JavaScript (javascript)

Si vous utilisez un wrapper PHP, mettez à jour ~/bin/wp-cli.phar au lieu de remplacer ~/bin/wp.

curl -fsSL -o ~/bin/wp-cli.phar.new https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php ~/bin/wp-cli.phar.new --info
mv ~/bin/wp-cli.phar.new ~/bin/wp-cli.phar
wp --infoLangage du code : JavaScript (javascript)

Dépannage : WP-CLI affiche une erreur PHP

Si WP-CLI affiche une erreur PHP, commencez par vérifier la version et le binaire utilisés :

wp --info
php -v
which php

Ensuite, testez WP-CLI sans charger WordPress :

wp cli version
wp --debug --info

Si l’erreur apparaît seulement dans un site précis :

wp plugin list --skip-plugins --skip-themes
wp core version --skip-plugins --skip-themesLangage du code : PHP (php)

Un plugin, un thème ou un mu-plugin peut casser le chargement en CLI. Les options --skip-plugins et --skip-themes permettent souvent de reprendre la main. Charmant, quand un plugin d’admin casse précisément l’outil qui sert à réparer l’admin.

Dépannage : mémoire PHP insuffisante

Si WP-CLI échoue avec une erreur de mémoire, essayez :

php -d memory_limit=512M ~/bin/wp plugin listLangage du code : JavaScript (javascript)

Si vous utilisez un wrapper, vous pouvez y ajouter une limite mémoire :

cat > ~/bin/wp <<'EOF'
#!/usr/bin/env bash
exec /usr/bin/php8.3 -d memory_limit=512M "$HOME/bin/wp-cli.phar" "$@"
EOF

chmod 755 ~/bin/wpLangage du code : JavaScript (javascript)

À utiliser comme rustine raisonnable, pas comme cache-misère éternel. Si une simple commande WP-CLI demande 1 Go de RAM, le site mérite probablement un audit.

Dépannage : permissions et ownership

WP-CLI doit être exécuté avec l’utilisateur qui possède les fichiers du site, ou au moins avec un utilisateur cohérent avec votre modèle d’hébergement.

Vérifiez :

whoami
pwd
ls -ld .
ls -l wp-config.php
ls -ld wp-contentLangage du code : CSS (css)

Si WP-CLI ne peut pas écrire dans wp-content, les mises à jour d’extensions, de thèmes ou de langues échoueront. Sur mutualisé, ne forcez pas les permissions en 777. Corrigez l’utilisateur, le groupe ou demandez à l’hébergeur d’ajuster le modèle. Le chmod 777, c’est comme enlever la porte parce que la serrure coince.

Commandes utiles après installation

Une fois WP-CLI installé, voici les commandes de base à tester :

wp --info
wp core version
wp option get home
wp plugin list
wp theme list
wp user list --role=administratorLangage du code : PHP (php)

Pour les mises à jour :

wp core check-update
wp plugin list --update=available
wp theme list --update=availableLangage du code : PHP (php)

Pour la base :

mkdir -p ~/backups
wp db export ~/backups/wordpress-$(date +%F-%H%M%S).sql --add-drop-table
wp db check

Pour les caches et permaliens :

wp cache flush
wp rewrite flush

Pour vérifier les fichiers du core :

wp core verify-checksums

Installer WP-CLI sur plusieurs sites du même compte

Une seule installation dans ~/bin/wp peut servir à tous les sites du même utilisateur SSH.

Exemple :

wp --path="$HOME/www/site1/public_html" core version
wp --path="$HOME/www/site2/public_html" plugin list
wp --path="$HOME/www/site3/public_html" db export "$HOME/backups/site3.sql"Langage du code : JavaScript (javascript)

Vous pouvez aussi créer de petits alias dans ~/.bashrc ou ~/.zshrc :

alias wp-site1='wp --path="$HOME/www/site1/public_html"'
alias wp-site2='wp --path="$HOME/www/site2/public_html"'Langage du code : JavaScript (javascript)

Ensuite :

wp-site1 plugin list
wp-site2 core check-updateLangage du code : PHP (php)

Sécurité : ce qu’il faut éviter

Même sans root, WP-CLI donne beaucoup de pouvoir sur votre site WordPress. Il peut changer des options, créer des utilisateurs, installer du code et exporter la base.

  • Ne rendez pas ~/bin/wp modifiable par tout le monde.
  • Ne stockez pas de dumps SQL dans un dossier public.
  • Ne lancez pas des commandes copiées sans les lire.
  • Ne faites pas de chmod 777 pour “réparer” WP-CLI.
  • Ne gardez pas d’exports base dans public_html.
  • Ne partagez pas votre accès SSH avec plusieurs personnes.

Permissions recommandées :

chmod 755 ~/bin
chmod 755 ~/bin/wp

Si vous utilisez un PHAR séparé et un wrapper :

chmod 755 ~/bin/wp
chmod 644 ~/bin/wp-cli.pharLangage du code : JavaScript (javascript)

Checklist d’installation sans root

  • SSH fonctionne.
  • PHP CLI est disponible.
  • La version PHP est compatible avec WP-CLI.
  • Le dossier ~/bin existe.
  • ~/bin est dans le PATH.
  • Le PHAR WP-CLI officiel est téléchargé.
  • Le fichier est exécutable.
  • wp --info fonctionne.
  • WP-CLI utilise la bonne version PHP.
  • Les commandes fonctionnent dans la racine WordPress.
  • Les sauvegardes sont stockées hors du webroot.

Pour aller plus loin avec WP-CLI et la maintenance WordPress

Une fois WP-CLI installé sans root, ces guides complètent bien la maintenance, la migration, les sauvegardes et l’audit de vos sites WordPress.

Besoin de maintenir WordPress sans accès root ?

Je peux installer WP-CLI, auditer votre hébergement, automatiser vos sauvegardes et mettre en place une maintenance propre, même sur un serveur ou un mutualisé limité.

  • Installation WP-CLI sans root, configuration PHP CLI, PATH, alias et wrappers.
  • Maintenance WordPress : mises à jour, sauvegardes, exports SQL, caches et diagnostics.
  • Audit extensions, thèmes, fichiers core, permissions, sécurité et performances.
  • Migration WordPress avec WP-CLI, rsync, search-replace, staging et rollback.
  • Optimisation WooCommerce, base de données, autoload, cron et workflows serveur.

Pour administrer votre site proprement sans dépendre du panel, contactez-moi ici.

FAQ

Peut-on installer WP-CLI sans sudo ?

Oui. Il suffit de placer le PHAR WP-CLI dans un dossier utilisateur comme ~/bin, de le rendre exécutable, puis d’ajouter ce dossier au PATH.

Où installer WP-CLI sans accès root ?

Le plus simple est ~/bin/wp. Ce dossier appartient à votre utilisateur et peut être ajouté facilement au PATH.

Pourquoi wp –info utilise une mauvaise version PHP ?

Sur mutualisé, PHP CLI peut différer du PHP web. Utilisez un wrapper local pour lancer WP-CLI avec le bon binaire PHP, par exemple /usr/bin/php8.3 ou le chemin fourni par votre hébergeur.

Puis-je utiliser WP-CLI sur plusieurs sites ?

Oui. Une seule installation dans ~/bin peut piloter plusieurs sites. Utilisez --path pour indiquer la racine WordPress de chaque site.

Faut-il vérifier le fichier wp-cli.phar ?

C’est recommandé. Utilisez la signature GPG si possible, ou au minimum un checksum SHA-512 ou SHA-256 publié par WP-CLI.

WP-CLI peut-il casser un site ?

WP-CLI exécute des actions puissantes. Une mauvaise commande peut modifier la base ou les fichiers. Exportez la base avant les opérations risquées, lisez les commandes, et évitez les sauvegardes dans le webroot.

Conclusion

Installer WP-CLI sans accès root est simple : créez ~/bin, téléchargez le PHAR officiel, rendez-le exécutable, ajoutez le dossier au PATH, puis testez avec wp --info.

Sur mutualisé, le point le plus important reste souvent la version PHP CLI. Si elle ne correspond pas au site, créez un wrapper local pour forcer le bon binaire PHP.

Une fois installé, WP-CLI transforme un accès SSH limité en vraie console d’administration WordPress. Pas besoin de root pour faire du travail propre. Juste d’un bon PATH, d’un PHP correct, et d’un peu de méthode.

Je vous recommande l’hébergeur WordPress FastNyx, chez qui WP-CLI est actif par défault.

Sources

Un logo carré rose avec la lettre « E » en blanc se trouve à gauche, symbolisant Elementor. À droite, une illustration simple d'un balai avec un manche marron signifie nettoyer complètement.

Supprimer complètement Elementor de WordPress et nettoyer sa base de données

Supprimer les extensions Elementor ne suffit pas à retirer toutes leurs données. Elementor conserve notamment les structures de pages, réglages, modèles, kits, caches et préférences dans la base WordPress. Pour les éliminer sans casser le site, il faut d’abord reconstruire les contenus, sauvegarder la base, inventorier les données restantes, puis procéder à un nettoyage ciblé.

Cette procédure s’adresse aux sites qui ont définitivement quitté Elementor au profit de Gutenberg, GenerateBlocks, GeneratePress ou d’un autre constructeur. Elle utilise WP-CLI afin de travailler proprement avec le préfixe réel des tables WordPress.

Pourquoi Elementor laisse-t-il des données dans WordPress ?

Elementor stocke la structure et les réglages de chaque page dans des champs personnalisés de la table postmeta. Le contenu est enregistré sous forme de données JSON associées aux publications WordPress.

L’extension utilise également plusieurs autres emplacements :

  • la table options pour ses réglages globaux, caches et tâches planifiées ;
  • la table usermeta pour les préférences des utilisateurs et notifications administratives ;
  • les tables posts et postmeta pour les modèles, kits, popups, formulaires et éléments Theme Builder ;
  • les tables de taxonomies pour classer certains modèles ;
  • le répertoire wp-content/uploads/elementor/ pour les CSS générées, polices, icônes et autres fichiers ;
  • les tâches WP-Cron et transients pour certains traitements temporaires.

La désinstallation classique conserve souvent ces données. Ce choix permet de réinstaller Elementor sans perdre immédiatement les mises en page.

Lire la suite