Les 10 commandes WP-CLI que tout administrateur WordPress devrait connaître

par Francis Rozange | Oct 1, 2026 | WordPress

Le 22 mai 2026, deux jours après la sortie de WordPress 7.0, un utilisateur signale sur GitHub un problème troublant : la commande wp core download annonce « Success », mais l’installation obtenue est incomplète. Une seconde commande, wp core verify-checksums, révèle que des fichiers du nouveau client d’IA de WordPress manquent à l’appel.

Cette histoire résume à elle seule ce qu’est WP-CLI, l’interface en ligne de commande de WordPress : un outil d’une puissance considérable, qui fait en une seconde ce que l’administration fait en dix clics, mais qui ne pardonne ni l’à-peu-près ni la confiance aveugle dans un message de réussite.

Voici les dix commandes que tout administrateur WordPress devrait connaître, avec pour chacune ce qu’elle fait, un exemple sûr et l’erreur dangereuse à éviter. Toutes les options ont été vérifiées dans la documentation officielle et dans le code de WP-CLI 2.12, la version stable en octobre 2026.

Comment nous les avons classées

Nous avons retenu les commandes les plus utilisées en maintenance courante, puis celles qui font le plus de dégâts quand on les utilise mal. L’ordre suit le déroulé d’une intervention typique : mettre à jour, sauvegarder, migrer, auditer, nettoyer, et enfin les outils de dernier recours.

Une précision importante avant de commencer : la version stable de WP-CLI est la 2.12.0, sortie le 7 mai 2025. La version 3.0 est en préparation mais n’est pas publiée, et plusieurs correctifs cités plus bas n’existent que dans la version de développement quotidienne. Vérifiez la vôtre avec wp cli version.

Avant de commencer : installer WP-CLI proprement

WP-CLI se présente sous la forme d’un seul fichier PHP exécutable, une archive phar. Le manuel officiel décrit l’installation en quatre temps : télécharger le fichier, vérifier qu’il fonctionne, le rendre exécutable, puis le déplacer dans un dossier du chemin système.

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

Le manuel propose aussi une signature GPG pour vérifier l’authenticité du fichier téléchargé. La commande wp cli update ne fonctionne qu’avec cette méthode d’installation. La version 2.12 accepte encore PHP 5.6, mais l’équipe a annoncé que la prochaine version exigera PHP 7.2.24 au minimum, ce que le manuel indique déjà.

Pour piloter plusieurs sites, trois options globales évitent de changer de dossier : --path désigne l’installation, --url le site visé sur un multisite, et --ssh exécute la commande sur un serveur distant. Combinées, elles permettent d’administrer un parc entier depuis un seul poste.

1. wp core update et verify-checksums : mettre à jour, puis prouver

Pourquoi c’est important

wp core update met WordPress à jour vers la dernière version, ou vers une version précise. Mais une mise à jour réussie ne prouve rien sur l’intégrité des fichiers. wp core verify-checksums télécharge depuis WordPress.org les empreintes de chaque fichier de la version installée et les compare aux fichiers présents, sans même charger WordPress, par sécurité.

Comment faire

La séquence sûre tient en cinq commandes : vérifier la mise à jour disponible, sauvegarder la base, mettre à jour, mettre à jour la base, puis contrôler les fichiers.

wp core check-update
wp db export /home/utilisateur/sauvegardes/avant-mise-a-jour.sql
wp core update
wp core update-db
wp core verify-checksums

La quatrième étape compte : lors d’une mise à jour, WordPress déclenche la mise à jour de la base par une requête interne vers son propre serveur. Si le serveur ne peut pas se joindre lui-même, cette requête peut échouer sans interrompre la commande. Lancer wp core update-db rend l’étape explicite. L’option --minor se limite aux versions de maintenance.

L’erreur à éviter

Ajouter --insecure pour contourner une erreur de certificat. La documentation prévient que la requête devient vulnérable à une interception. Autre piège : verify-checksums ignore tout le dossier wp-content. Il ne dit rien des plugins, des thèmes ni des fichiers envoyés : ce n’est pas un détecteur de logiciels malveillants.

Comment vérifier

wp core version confirme la version installée, et wp core update-db --dry-run compare la version de la base à celle des fichiers sans rien modifier. Si une mise à jour précédente a été interrompue, WordPress peut refuser d’en lancer une nouvelle en indiquant qu’une autre est en cours. La documentation conseille alors de supprimer le verrou avec wp option delete core_updater.lock, mais seulement après avoir vérifié qu’aucune mise à jour ne tourne réellement.

Le cas réel : « Success » sur une installation incomplète

L’histoire qui ouvre cet article est documentée de bout en bout sur GitHub. Elle montre pourquoi une commande de vérification vaut mieux que n’importe quel message de réussite.

Ce qui s’est passé

WordPress 7.0, sorti le 20 mai 2026, introduit un client d’IA dans le cœur, avec 146 nouveaux fichiers rangés dans des dossiers profonds. Le 22 mai, un utilisateur ouvre un ticket : wp core download tronque silencieusement les noms de fichiers de plus de 100 caractères quand il extrait l’archive. Or certains chemins du client d’IA dépassent cette longueur. Le problème est reproductible à chaque fois.

La cause est ancienne. WP-CLI téléchargeait l’archive au format tar.gz et l’extrayait avec la classe PharData de PHP, qui ne lit que les 100 premiers octets du nom de chaque fichier, un défaut signalé à PHP en juillet 2025 et toujours ouvert. Le choix du format tar.gz remontait à 2012. Les mises à jour par wp core update, qui passent par une archive ZIP, n’étaient pas touchées.

La réponse des mainteneurs

Un quart d’heure après le signalement, le mainteneur Pascal Birchler confirme que l’équipe connaît le problème. Un contributeur publie un contournement : télécharger l’archive sans l’extraire, puis l’extraire avec l’outil tar du système. Le lendemain, une modification qui fait toujours utiliser des archives ZIP est fusionnée, complétée deux jours plus tard.

Mais aucune version stable de WP-CLI n’est sortie depuis mai 2025. En juin, un second utilisateur rencontre le même problème et précise que l’installation fonctionne jusqu’à ce que quelque chose appelle le client d’IA. On lui conseille la version quotidienne de WP-CLI, que la documentation officielle déconseille pourtant en production. En août, un troisième utilisateur, sous Windows, voit même échouer la commande qui doit l’installer ; le mainteneur lui conseille de télécharger le fichier à la main.

Ce qu’il faut en retenir

Dans les deux signalements détaillés, c’est wp core verify-checksums qui a révélé le problème. Un « Success » dit que la commande s’est terminée, pas que le résultat est correct. Sachez quelle version de WP-CLI vous utilisez, et vérifiez systématiquement après une installation ou une réinstallation. Notre article sur les nouveautés de WordPress 7 présente ce client d’IA.

2. wp plugin list, update et verify-checksums : inventaire et contrôle

Pourquoi c’est important

wp plugin list dresse l’inventaire des plugins et force à chaque appel une vérification fraîche des mises à jour. Son champ facultatif wporg_status indique si un plugin a été fermé sur WordPress.org, une information que l’administration n’affiche pas. Prudence toutefois en version 2.12 : un plugin inconnu de l’API de WordPress.org est classé closed dès que le flux de Trac interrogé ensuite répond autre chose qu’une erreur 404, et ce flux limite désormais les requêtes, si bien qu’un plugin sur mesure peut apparaître à tort comme fermé.

Comment faire

wp plugin list --fields=name,status,version,update,wporg_status
wp plugin update --all --dry-run
wp plugin update --all --exclude=woocommerce
wp plugin verify-checksums --all

L’option --dry-run montre ce qui serait mis à jour sans rien toucher. L’option --exclude met de côté un plugin sensible, à tester d’abord sur une copie. Quand un plugin actif est mis à jour, le site passe en mode maintenance ; si la commande est interrompue, wp maintenance-mode deactivate l’en fait sortir.

L’erreur à éviter

Lancer wp plugin update --all en production sans sauvegarde ni test : une version majeure de WooCommerce ou d’un constructeur de pages peut migrer la base de données. Et lire « tous les plugins vérifiés » comme « le site est sain » : les empreintes viennent de WordPress.org, et les plugins premium ou sur mesure sont simplement ignorés.

Deux détails de la version 2.12 méritent d’être connus. Le champ wporg_last_updated, qui devrait indiquer la date de dernière mise à jour sur WordPress.org, revient vide, car la source qu’il interroge limitait les requêtes ; la correction attend la prochaine version. Et l’option --force-check, annoncée pour wp plugin list dans les notes de version, n’a jamais été intégrée : elle n’existe que pour wp core check-update. Ce n’est pas grave, puisque wp plugin list force déjà une vérification à chaque appel.

L’origine de l’option –insecure

Pendant des années, WP-CLI désactivait silencieusement la vérification des certificats quand une connexion sécurisée échouait, puis réessayait. Un attaquant capable d’intercepter le trafic pouvait se faire passer pour un serveur de mises à jour. La faille, enregistrée en 2021 sous la référence CVE-2021-29504, a été corrigée dans WP-CLI 2.5.0 : l’échec devient une erreur, et l’option --insecure rend le contournement explicite. Elle ne doit jamais devenir un réflexe.

3. wp db export et wp db import : la sauvegarde avant tout geste

Pourquoi c’est important

wp db export lance mysqldump, ou mariadb-dump sur un serveur MariaDB, avec les identifiants du fichier wp-config.php, et accepte toutes les options de cet outil. wp db import exécute le contenu d’un fichier SQL dans la base du site. C’est le filet de sécurité de toutes les autres commandes de cet article.

Comment faire

wp db export /home/utilisateur/sauvegardes/site.sql --single-transaction --quick
wp db import /home/utilisateur/sauvegardes/site.sql

WP-CLI n’ajoute pas de lui-même l’option --single-transaction. Sans elle, l’outil de sauvegarde verrouille les tables pendant l’export. Avec elle, les tables InnoDB sont exportées dans un état cohérent sans verrou, à condition qu’aucune modification de structure n’intervienne pendant ce temps. Les tables MyISAM, elles, restent sans garantie.

L’erreur à éviter

Lancer l’export depuis la racine du site avec le nom de fichier par défaut : la sauvegarde atterrit dans le dossier courant, potentiellement téléchargeable par n’importe qui. Autre erreur classique : importer la base de production dans une copie de travail sans lancer ensuite search-replace, si bien que la copie continue d’appeler les adresses de production. Et search-replace ne coupe pas les courriels : une copie de la production en envoie tant que l’envoi n’y est pas désactivé.

Comment vérifier

wp db check contrôle l’état des tables, wp db size donne le poids de la base, et une requête de comptage sur la table des articles permet de comparer avant et après un import. Sachez aussi qu’un import ne supprime pas les tables absentes du fichier : celles qui existent déjà ne sont remplacées que si le fichier contient les instructions de suppression correspondantes, ce que fait par défaut l’outil d’export.

Un export en ligne de commande ne remplace pas pour autant une vraie stratégie de sauvegarde, comme le montre notre comparatif des plugins de sauvegarde WordPress.

4. wp search-replace : migrer sans casser les données sérialisées

Pourquoi c’est important

Lors d’un changement de domaine, l’ancienne adresse est inscrite partout dans la base. Un remplacement brutal dans le fichier SQL casse les données sérialisées, ces valeurs où PHP enregistre la longueur de chaque chaîne : la documentation de WordPress prévient que des thèmes et des widgets cessent alors de fonctionner. wp search-replace désérialise, remplace, puis resérialise en recalculant les longueurs.

Comment faire

wp search-replace 'https://preprod.example.com' 'https://www.example.com' --all-tables-with-prefix --skip-columns=guid --dry-run --report-changed-only

Lancez d’abord la commande avec --dry-run, qui affiche le nombre de remplacements par table sans rien écrire, puis sans, après une sauvegarde. Par défaut, seules les tables enregistrées dans WordPress sont traitées : --all-tables-with-prefix inclut celles des plugins. Excluez la colonne guid, que la documentation demande de ne jamais modifier. Terminez par wp cache flush.

Pour chaque colonne, WP-CLI teste si une valeur ressemble à des données sérialisées. Si c’est le cas, toute la colonne est traitée en PHP, valeur par valeur ; sinon, un remplacement SQL rapide suffit. Le rapport indique le mode utilisé pour chaque colonne. Les valeurs sérialisées qui ne commencent pas par un tableau, un entier ou un objet, comme une simple chaîne sérialisée, peuvent échapper à ce test : l’option --precise force le traitement en PHP partout, au prix de la vitesse.

Notre guide pour migrer un site WordPress sans interruption replace cette étape dans l’ensemble.

L’erreur à éviter

Une faute de frappe dans l’adresse de remplacement. En avril 2026, un contributeur a décrit sur GitHub le cas d’une adresse tapée avec un point-virgule au lieu de deux-points : WP-CLI a écrit la valeur erronée partout, y compris dans les réglages d’adresse du site, et a annoncé un succès. Au chargement suivant, le site affichait une erreur critique. Le mode d’essai montre des nombres, pas la justesse de la valeur : relisez-la.

Deux autres pièges : remplacer un nom de domaine nu modifie aussi les adresses électroniques qui le contiennent, et WP-CLI 2.12 ne reconnaît pas les adresses enregistrées au format JSON, où les barres obliques sont échappées. La correction existe, mais seulement dans la version de développement.

Deux coffres de verre reliés par un canal lumineux où circule un flux de particules

5. wp user : auditer les comptes, supprimer sans perdre les contenus

Pourquoi c’est important

Les comptes d’administrateur oubliés, d’anciens prestataires ou salariés, sont une porte d’entrée classique. wp user list les liste en une ligne, et wp user delete les supprime proprement, à condition de réattribuer leurs contenus.

Comment faire

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user delete 123 --reassign=1
wp user reset-password nom-du-compte --skip-email --porcelain

L’erreur à éviter

Supprimer sans --reassign, surtout avec --yes dans un script. WP-CLI prévient que tous les contenus associés seront supprimés. En réalité, les articles et les pages partent à la corbeille si elle est active, mais les autres types de contenus liés à l’auteur sont supprimés, et les médias le sont définitivement, sauf si la corbeille des médias est activée. Sur un multisite, la réattribution n’est pas possible au niveau du réseau.

Vérifiez enfin que le compte qui reçoit les contenus existe, avec wp user get 1. Avec un identifiant inexistant, WP-CLI pose une question que --yes valide d’office, et les contenus sont rattachés à un auteur qui n’existe pas.

Évitez aussi de passer un mot de passe en clair avec --user_pass : il reste dans l’historique du terminal. Laissez WP-CLI en générer un : c’est ce que fait wp user reset-password, qui, avec --skip-email --porcelain, affiche seulement le nouveau mot de passe, sans courriel au titulaire du compte.

Comment vérifier

Après une suppression avec réattribution, wp post list --author=123 --post_type=any --format=count doit renvoyer zéro pour l’ancien compte, et le compte qui a reçu les contenus doit les retrouver. Profitez de l’audit pour repérer les administrateurs inscrits récemment sans raison connue : la colonne user_registered de la liste les fait ressortir, et un compte inattendu peut signaler une intrusion.

6. wp cron event list et run : voir et déclencher les tâches planifiées

Pourquoi c’est important

WordPress planifie de nombreuses tâches : publications programmées, sauvegardes, renouvellements d’abonnements, synchronisations. wp cron event list les affiche avec leur prochaine exécution ; une date passée signale une tâche bloquée.

Comment faire

wp cron event list
wp cron event run --due-now
wp cron test

Pour fiabiliser ces tâches, désactivez le déclenchement par les visites avec la constante DISABLE_WP_CRON et confiez-le au planificateur du système, qui appelle wp cron event run --due-now à intervalle régulier, sous l’utilisateur du site. Notre comparatif entre WP-Cron et le cron système détaille la mise en place.

L’erreur à éviter

wp cron event run --all en production déclenche immédiatement toutes les tâches planifiées, pas seulement celles en retard : newsletters, renouvellements, synchronisations. Préférez --due-now ou le nom d’une tâche précise. Et ne désactivez jamais WP-Cron sans avoir mis en place le cron système : les tâches resteraient bloquées.

Comment vérifier

Dans la liste des tâches, la colonne next_run_relative affiche « now » pour toute tâche échue, sans dire depuis quand : comparez plutôt next_run_gmt à l’heure actuelle pour repérer une tâche en retard de plusieurs heures. wp cron test vérifie que WordPress sait déclencher ses tâches par une requête interne ; il renvoie une erreur si WP-Cron est désactivé, ce qui est normal une fois le cron système en place. Dans ce cas, c’est la ligne du planificateur système et ses journaux qu’il faut contrôler.

7. wp cache flush et wp transient delete : vider le bon cache

Pourquoi c’est important

wp cache flush vide le cache objet, et seulement lui. Sans cache objet persistant, il ne vide que la mémoire de la commande elle-même. Il ne purge ni le cache de page de LiteSpeed ou de Varnish, ni celui d’un CDN, qui ont leurs propres outils. wp transient delete supprime les données temporaires que plugins et thèmes stockent.

Comment faire

wp cache type
wp transient delete --expired
wp cache flush

Le nettoyage des données temporaires expirées peut devenir une routine. La documentation des développeurs rappelle d’ailleurs que la durée d’une donnée temporaire est un maximum, pas une garantie, et qu’il ne faut jamais supposer qu’elle se trouve en base : un plugin bien écrit sait la recalculer quand elle a disparu. Le vidage du cache objet se justifie après un search-replace ou un import de base. Notre guide du cache objet Redis explique ce que ce cache stocke.

L’erreur à éviter

Vider le cache objet d’une grosse boutique en pleine heure de pointe : le cache froid reporte d’un coup toute la charge sur la base de données. Sur un multisite, la documentation prévient que le vidage touche généralement tous les sites. Et avec Redis ou Memcached, wp transient delete --all ne supprime que les données temporaires stockées en base, comme la commande l’indique elle-même.

8. wp rewrite flush : réparer les permaliens, une seule fois

Pourquoi c’est important

Après un changement de permaliens ou l’ajout d’un type de contenu, des pages peuvent renvoyer une erreur 404. wp rewrite flush régénère les règles de réécriture à partir des types de contenus enregistrés.

Comment faire

wp rewrite flush
wp rewrite list --format=count

L’option --hard régénère aussi le fichier .htaccess sur un site unique sous Apache, à condition de déclarer le module de réécriture dans la configuration de WP-CLI.

L’erreur à éviter

Placer ce vidage dans une tâche qui s’exécute en boucle : la documentation de WordPress rappelle que c’est une opération coûteuse, à n’utiliser qu’en cas de besoin. Et lancer --hard sans garder une copie du fichier .htaccess : WordPress n’y réécrit que le bloc compris entre # BEGIN WordPress et # END WordPress, mais toute règle de sécurité ou redirection ajoutée à la main dans ce bloc disparaît.

9. wp option et l’autoload : lire et régler la table des options

Pourquoi c’est important

La table des options contient les réglages du site, dont une partie est chargée en mémoire à chaque page. Depuis WordPress 6.6, une option de plus de 150 000 octets n’est plus chargée automatiquement par défaut, et la Santé du site signale un volume chargé supérieur à 800 Ko.

Comment faire

wp option get home
wp option update blogdescription "Nouvelle description"
wp option set-autoload nom_de_l_option off

Attention : dans WP-CLI 2.12, le filtre --autoload=on de wp option list ignore les nouvelles valeurs introduites par WordPress 6.6, et sous-estime donc le volume réellement chargé. Aucune version, même de développement, ne corrige ce point en octobre 2026 : la modification fusionnée en juin 2026 répare un autre défaut du même filtre, qui laissait passer des données temporaires dans le résultat. Pour un audit fiable, interrogez directement la base :

wp db query "SELECT autoload, COUNT(*), SUM(LENGTH(option_value)) FROM $(wp db prefix)options GROUP BY autoload"

L’erreur à éviter

Mettre à jour une option sérialisée avec une simple chaîne de caractères, ce qui écrase tout le tableau : utilisez --format=json. Modifier siteurl ou home avec une faute de frappe, ce qui coupe l’accès à l’administration. Et éditer à la main la liste des plugins actifs.

Comment vérifier

wp option get-autoload suivi du nom d’une option affiche sa valeur brute : yes, on, auto et auto-on signifient qu’elle est chargée à chaque page, no, off et auto-off qu’elle ne l’est pas. Les mêmes valeurs servent à lire la requête d’audit. Après un réglage, relancez la requête d’audit ci-dessus et comparez le total chargé à celui d’avant. Dans l’administration, la Santé du site confirme le résultat : son alerte sur les options chargées automatiquement disparaît sous le seuil de 800 Ko.

10. wp eval et wp shell : la puissance brute, avec précaution

Pourquoi c’est important

wp eval exécute du code PHP arbitraire dans WordPress chargé ; wp shell ouvre une console interactive avec accès à toutes les fonctions. C’est irremplaçable pour diagnostiquer, et redoutable : aucune vérification de droits, aucune annulation, et les pleins droits de l’utilisateur système et de la base.

Comment faire

wp eval 'var_dump( wp_using_ext_object_cache() );'
wp plugin deactivate plugin-casse --skip-plugins --skip-themes

La seconde commande illustre les options globales --skip-plugins et --skip-themes, qui permettent de reprendre la main sur un site bloqué par un plugin défaillant. Les plugins indispensables, dans le dossier mu-plugins, restent chargés.

L’erreur à éviter

Coller dans wp eval un extrait trouvé sur un forum, directement en production. Construire une chaîne wp eval à partir de données non fiables dans un script. Et lancer WP-CLI en root : il refuse par défaut, en avertissant que le code du site prendrait alors le contrôle total du serveur, et recommande d’exécuter la commande sous l’utilisateur du site. Ces précautions rejoignent nos 10 mesures pour sécuriser WordPress.

Comment choisir la bonne commande

  • Maintenance courante : wp core check-update, wp plugin list, wp transient delete --expired.
  • Avant toute intervention : wp db export, toujours.
  • Après une mise à jour : wp core update-db et wp core verify-checksums.
  • Migration : wp db import, wp search-replace en mode d’essai, wp cache flush, wp rewrite flush.
  • Audit de sécurité : wp user list, wp plugin verify-checksums --all, wporg_status.
  • Incident : --skip-plugins, wp maintenance-mode deactivate, puis wp eval en lecture seule.

Tableau récapitulatif

Commande Usage Option de sécurité Erreur à éviter
wp core update Mettre à jour WordPress verify-checksums après --insecure par réflexe
wp plugin update Mettre à jour les plugins --dry-run --all sans test
wp db export Sauvegarder la base --single-transaction Fichier dans la racine web
wp search-replace Changer d’adresse --dry-run, --skip-columns=guid Faute de frappe non relue
wp user delete Supprimer un compte --reassign --yes sans réattribution
wp cron event run Lancer les tâches --due-now --all en production
wp cache flush Vider le cache objet Heures creuses Le croire capable de purger le cache de page
wp rewrite flush Réparer les permaliens Copie du .htaccess L’exécuter en boucle
wp option update Régler une option --format=json Écraser une option sérialisée
wp eval Diagnostiquer Lecture seule Code copié d’un forum

Questions fréquentes

Quelle version de WP-CLI utiliser en octobre 2026 ?

La version stable 2.12.0, sortie en mai 2025. La version de développement quotidienne contient des correctifs utiles, notamment pour wp core download avec WordPress 7, mais la documentation officielle la déconseille en production.

WP-CLI remplace-t-il une sauvegarde ?

wp db export sauvegarde la base, pas les fichiers. Une sauvegarde complète comprend aussi le dossier wp-content et le fichier wp-config.php ; elle est stockée hors du serveur et testée par une restauration.

wp search-replace casse-t-il les données sérialisées ?

Non, c’est précisément son intérêt : il recalcule les longueurs des chaînes sérialisées. L’option --precise force un traitement plus complet, plus lent. Il ne gère pas, en version 2.12, les adresses enregistrées au format JSON.

Peut-on lancer WP-CLI en root ?

Il refuse par défaut, et l’option --allow-root qui le force est une mauvaise idée : le code de n’importe quel plugin s’exécuterait avec les pleins pouvoirs sur le serveur. Exécutez WP-CLI sous l’utilisateur propriétaire du site.

Que faire si wp core verify-checksums échoue ?

Lisez les fichiers signalés. Des fichiers manquants après une installation fraîche évoquent le problème d’extraction décrit plus haut. Des fichiers modifiés ou ajoutés dans wp-admin ou wp-includes justifient une réinstallation des fichiers du cœur et une recherche de compromission.

Conclusion

WP-CLI fait gagner un temps considérable à quiconque administre des sites WordPress, et il rend possibles des opérations que l’interface ne permet pas, comme une migration propre ou un audit en une minute. Mais il exécute ce qu’on lui demande, sans filet.

Trois réflexes suffisent à l’utiliser sereinement : exporter la base avant tout geste, passer par le mode d’essai quand il existe, et vérifier le résultat plutôt que de croire le message de réussite. L’histoire de WordPress 7.0 le montre : c’est la commande de vérification qui a révélé les installations incomplètes, pas celle qui annonçait « Success ».

Sources


LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, administration en ligne de commande comprise, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier