Ако някога сте чакали 30 секунди, за да зареди страница с „Разширения“ бек-офис, WP-CLI бързо ще се превърне в любимия ви пряк път. WordPress 6.9.4 (април 2026 г.), инструментите на CLI са достатъчно зрели, за да обработват 90% от операциите. поддръжка, без браузър, с използваеми лог файлове и по-добра възпроизводимост.
Какво ще изградим
Ще настройвате ориентиран към производството „инструментариум“ за WP-CLI, състоящ се от:
- от основата на основни команди (ядро, плъгини, теми, база данни, потребители, cron),
- на възпроизводим работен процес за диагностика и актуализиране,
- многократно използваем Bash скрипт за работа с множество сайтове,
- и пример за персонализирана WP-CLI команда (mu-plugin) за стандартизиране на вашите операции.
Предназначен е за „истински“ WordPress сайтове: блогове с висок трафик, сайтове за представяне с конструктори на страници (Divi 5, Elementor, Avada), мултисайтове, среди за подготовка/производство.
В крайна сметка ще знаете:
- насочете се към правилния WordPress екземпляр от терминала (и избягвайте грешката класическо „В грешен файл съм“),
- актуализиране, като същевременно се ограничават рисковете (режим на поддръжка, проверки, прагматично връщане назад),
- бърз одит на уебсайт (версии, активни теми, cron задачи, чувствителни опции),
- Автоматизирайте рутините си и създайте свои собствени команди.
Бързо обобщение
- Първо проверете :
wp --infoСлед товаwp core versionetwp plugin list. - Насочвайте се изрично уебсайтът:
--path,--urlи избягвайте „текст в празнотата“. - Преди актуализация експортиране на база данни + списък с версии, след това актуализация, накрая тестове за дим.
- Търсене-замяна винаги с
--dry-runи бъдете внимателни със сериализираните данни (WP-CLI се справя с това, но опциите ви може да са трудни). - Автоматизирайте Bash скриптове + кодове за връщане и централизирайте командите си в WP-CLI mu-плъгин.
- Сигурност Няма тайни в историята на черупките, няма
--allow-rootпо навик и регистрирайте транзакциите си.
Кога да използвате това решение
- Когато управлявате множество обекти и административната част е твърде бавна (или недостъпна).
- Когато имате нужда да индустриализирам седмични актуализации, проверки на версиите, експортиране на база данни, временно прочистване.
- Когато работите в headless/CI/CD среди (GitHub Actions, GitLab CI и др.).
- Когато е необходимо да диагностицирате повреден сайт (фатална грешка в администраторския панел): WP-CLI често остава използваем.
Кога НЕ трябва да използвате това решение
- Ако нямате надежден SSH достъп (заключен споделен хостинг). В този случай вижте раздела „Вариант / Алтернатива“.
- Ако не можете да тествате на етап staging: изпълнете a
search-replaceили голяма „актуализация на живо“ без предпазна мрежа е лоша идея. - Ако вашият доставчик на хостинг услуги налага собствена обвивка (някои панели), която скрива PHP средата: WP-CLI може да работи с различна PHP версия от тази на сайта.
Преди да започнете (предварителни изисквания)
защита преди всяка разрушителна команда (db import, search-replace(Актуализиране), направете резервно копие на базата данни и, ако е възможно, моментна снимка на директорията wp-content.
- Цел на WordPress: 6.9.4 (или по-скорошни).
- Препоръчително е PHP: 8.1 + (8.2/8.3 са често срещани през 2026 г.). Проверете дали WP-CLI използва същата версия на PHP като вашия FPM/Apache.
- Достъп: SSH + права за запис на сайта (или поне на
wp-contentи базата данни).
Полезни инструменти :
- Тестова среда (една и съща база, едни и същи плъгини, една и съща тема);
- Система за контрол на версиите (Git);
- Инструмент за сравнение на износ (например
diff,jq(ако започнете от JSON).
Предпазни мерки (Повтарям това, защото често виждам грешката):
- Избягвайте да поставяте пароли като обикновен текст в терминала (историята на обвивката).
- Не използвайте
--allow-root„Като рефлекс.“ Ако е необходимо, документирайте защо. - Предпочитайте да използвате именувани SSH акаунти + sudo и log команди.
Полезни официални документи:
- WP-CLI (официален уебсайт)
- WP-CLI команда (справка)
- Справочник за WordPress (Функции и API)
- PHP 8.1 (бележки по изданието)
- WP-CLI в GitHub
Стъпка 1: Инсталирайте WP-CLI правилно и проверете средата
На повечето Linux сървъри, методът за инсталиране „phar“ остава най-лесният. Целта: двоичен файл wp налично и изпълнение с правилния PHP.
1.1 Инсталиране на WP-CLI (pharm)
Свържете се чрез SSH, след което:
# Téléchargement du phar
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
# Vérification basique : le fichier doit répondre
php wp-cli.phar --info
# Rendre exécutable et installer globalement
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
# Vérifier la commande
wp --infoОчакван резултат: wp --info показва версията на WP-CLI, използвания PHP и някои пътища.
1.2 Проверете дали WP-CLI използва правилния PHP код
Класическият капан: вашият сайт работи на PHP 8.2 чрез FPM, но WP-CLI извиква PHP 8.1 (или по-лош). Сравнете:
php -v
wp --infoАко версиите се различават, коригирайте ги, като използвате изричен псевдоним или път до правилния PHP двоичен файл (в зависимост от вашата дистрибуция). Пример (ще бъде адаптиран):
# Exemple : forcer PHP 8.2 pour WP-CLI
alias wp='php8.2 /usr/local/bin/wp'Често виждам този проблем на сървъри с множество PHP инсталации (Plesk, cPanel, Docker „multi“ образи).
1.3 Инсталиране на автоматично довършване (по избор, но си струва)
WP-CLI предлага автодопълване на командния интерфейс (shell completion). Вижте документацията на WP-CLI (в зависимост от bash/zsh). Това е значително повишаване на производителността.
Стъпка 2: Изберете правилната инсталация на WordPress (и избягвайте нарушаване на производствената среда)
WP-CLI работи „контекстно зависимо“. Трябва да сте в правилната директория (тази, която съдържа wp-config.php) или дайте --path.
2.1 Разберете дали сте на правилното място
# Depuis un dossier supposé être la racine du site
wp core is-installed
# Si ça échoue, vérifiez le chemin
pwd
ls -laОчакван резултат: код за връщане 0 (успех). Ако WP-CLI отговори, че не може да намери WordPress, почти винаги е в лоша директория.
2.2 Използвайте –path и –url (препоръчително за конфигурации с множество сайтове/множество инстанции)
# Exemple : cibler explicitement une instance
wp --path=/var/www/site1/public core version
# Exemple : cibler une URL (utile si WP_HOME/WP_SITEURL diffèrent)
wp --path=/var/www/site1/public --url=https://example.com option get home2.3 Създаване на wp-cli.yml файл за всеки проект
създавам wp-cli.yml в основата на проекта (на същото ниво като wp-config.phpТова избягва повторението. --path.
# À la racine de votre site
cat > wp-cli.yml <<'YAML'
path: public
# url: https://example.com
YAMLОчакван резултат: от родителската папка, wp core version работи.
Стъпка 3: Бърза диагностика (ядро, PHP, разширения, състояние на сайта)
Преди да започна каквото и да било, винаги правя „логическа снимка“: версии, активни плъгини, тема и няколко критични опции.
3.1 Версии и контекст
wp --info
wp core version
wp core verify-checksumsverify-checksums Сравнете основните файлове с официалните контролни суми. Много полезно. après инцидент (модифицирани файлове, основен зловреден софтуер, непълно внедряване). На сайтове, неправилно „персонализирани“ в wp-includesВеднага се връща нагоре.
3.2 Плъгини и теми (използваем инвентар)
wp plugin list --status=active
wp plugin list --format=csv > /tmp/plugins.csv
wp theme list
wp theme list --status=active3.3 Състояние на сайта чрез WP-CLI
Модулът „Site Health“ (Състояние на сайта) е достъпен чрез WP-CLI при стандартни инсталации. Тествайте го:
wp site health status
wp site health info --format=json > /tmp/site-health.jsonАко вашият хостинг или WordPress версия не предоставя тази команда, ще получите съобщение за грешка. В този случай се придържайте към командите за контрол на версиите и проверете PHP/nginx лог файловете.
3.4 Бърза диагностична таблица (често срещани симптоми)
| симптом | Вероятна причина | проверка | Решение |
|---|---|---|---|
| Грешка „Това изглежда не е инсталация на WordPress“ | Лош рекорд / лошо --path |
ls (наличие на wp-config.php) |
употреба --path където wp-cli.yml |
| WP-CLI работи, но сайтът се срива след актуализацията. | Несъвместимост на плъгини/теми + PHP | wp plugin list + логове |
Деактивирайте дефектния плъгин чрез WP-CLI, версия за връщане към предишната версия |
| Бавни команди | Кеш на обекти / База данни пълна / DNS | wp profile stage (ако е налично), мониторинг |
Ограничете автоматичното зареждане, проверете кеша, оптимизирайте базата данни |
| Разлика в поведението между CLI и уеб | Различни PHP, променливи на средата, системен потребител | php -v vs wp --info |
Принудително инсталиране на правилния PHP, подравняване на средата |
Стъпка 4: Надеждни актуализации (ядро, плъгини, теми) + прагматично връщане към предишни версии
Актуализациите с едно щракване са удобни, но трудни за одит. С помощта на интерфейса на командния ред (CLI) можете да регистрирате, поръчвате и проверявате актуализации.
4.1 Подготовка: поддръжка + архивиране на базата данни
# Activer le mode maintenance
wp maintenance-mode activate
# Export DB horodaté (à stocker hors serveur si possible)
wp db export "/tmp/db-$(date +%F-%H%M).sql"
# Capturer l'état des plugins/thèmes
wp plugin list --format=json > "/tmp/plugins-$(date +%F-%H%M).json"
wp theme list --format=json > "/tmp/themes-$(date +%F-%H%M).json"Очакван резултат: експортиран SQL файл и два JSON инвентаризация.
4.2 Актуализиране на ядрото на WordPress
# Vérifier les mises à jour disponibles
wp core check-update
# Mettre à jour vers la dernière version stable
wp core update
# Mettre à jour la base si nécessaire
wp core update-dbВ WordPress 6.9.4, update-db Обикновено би трябвало да е без опция, но на сайтове, които са пропуснали няколко версии, това има значение.
4.3 Актуализиране на плъгини и теми
wp plugin update --all
wp theme update --allАко управлявате сайтове с Divi 5 / Elementor / Avada, често препоръчвам да актуализирате в този ред:
- „Инфраструктурни“ плъгини (кеш, сигурност, SEO),
- конструктор на страници (Elementor / Divi / Fusion),
- тема (Авада / Диви)
- добавки за строители.
Това намалява сценариите, при които добавката очаква по-нов конструктор на API.
4.4 Бързо деактивиране на плъгин, който нарушава работата на сайта
Когато администраторският панел е недостъпен (фатална грешка), WP-CLI е вашият бутон за „деактивиране“:
# Désactiver un plugin précis
wp plugin deactivate nom-du-plugin
# Désactiver tous les plugins (utile pour isoler)
wp plugin deactivate --all4.5 Прагматично връщане назад
WP-CLI не поддържа универсално връщане към предишни версии за всички плъгини. На практика надеждното връщане към предишни версии се постига чрез:
- вашият архив (база данни + файлове),
- или Git + внедряване,
- или преинсталиране на определена версия, когато плъгинът го позволява.
# Réinstaller WordPress core (même version) si fichiers corrompus
wp core download --force
# Installer une version précise d'un plugin (si disponible sur .org)
wp plugin install woocommerce --version=9.1.0 --forceЗабележка: ако плъгинът идва от пазар (Divi, Avada) или частен zip архив, ще трябва да предоставите zip файла или да го използвате чрез техния механизъм.
4.6 Излизане от поддръжката
wp maintenance-mode deactivateСтъпка 5: Управлявайте потребители и роли, без да преминавате през администраторския панел
Използвам го главно за: създаване на временен администраторски акаунт по време на подготовка, коригиране на имейл, налагане на нулиране на парола или одитиране на това кой има високи права.
5.1 Списък и филтър
wp user list --fields=ID,user_login,user_email,roles,registered
wp user list --role=administrator --fields=ID,user_login,user_email5.2 Създаване на временен администратор (само за подготовка)
wp user create admin-temp [email protected] --role=administrator --user_pass="$(openssl rand -base64 24)"Избягвайте да правите това в производствена среда без система за заявки/проследимост. И изтрийте акаунта след това.
5.3 Нулиране на парола
wp user update monlogin --user_pass="NouveauMotDePasseFortIci"Истински капан: поставянето на паролата ви като обикновен текст в shell-а оставя следа в историята. Предпочитайте интерактивен вход (или мениджър на секретни пароли) в зависимост от вашите нужди.
Стъпка 6: Управление на съдържание, редакции, медии и почистване
WP-CLI е много ефективен за почистване без плъгин за „еднократно инсталиране“, особено когато искате възпроизводим резултат.
6.1 Броене и изброяване на съдържанието
wp post list --post_type=post --posts_per_page=10 --fields=ID,post_title,post_date,post_status
wp post list --post_type=page --post_status=publish --fields=ID,post_title6.2 Групово почистване на ревизии
В сайтове с инструменти за изграждане на страници, ревизиите могат да се „експлодират“ (всяко запазване на конструктора създава нова ревизия). Преди да изтриете каквото и да било, измерете резултатите.
# Compter les révisions
wp post list --post_type=revision --format=count
# Supprimer les révisions (irréversible sans backup)
wp post delete $(wp post list --post_type=revision --format=ids) --forceКласически капан: на много голям сайт, заместване $(...) може да надвишава ограничението за дължина на поръчката. В този случай изтривайте на партиди (вижте „Капани“).
6.3 Регенериране на миниатюри (в зависимост от вашия стек)
WP-CLI предоставя медийни команди, но пълната регенерация често зависи от плъгини. Ако използвате плъгин за регенерация, който предоставя WP-CLI команди, използвайте го. В противен случай, следната команда може да помогне в прости случаи:
# Lister quelques attachements
wp media list --posts_per_page=5 --fields=ID,post_title,guid
# Exemple : régénération basique (selon version/commandes disponibles)
wp media regenerate --yesSi wp media regenerate не е наличен във вашата WP-CLI инсталация, не го насилвайте: инсталирайте съвместим инструмент или използвайте специален плъгин.
Стъпка 7: База данни: експортиране, търсене и замяна, оптимизации и капани
Базата данни е мястото, където грешките са скъпоструващи. Моделът: експорт → пробен период → изпълнение → проверки.
7.1 Износ / Внос
# Export
wp db export /tmp/backup.sql
# Import (dangereux en production)
wp db import /tmp/backup.sql7.2 Търсене и замяна (миграция на http→https, промяна на домейн)
WP-CLI обработва много сериализирани данни правилно. Но все пак трябва да направите --dry-run и изключете това, което не трябва да се движи (понякога GUID).
# Simulation
wp search-replace 'http://ancien.tld' 'https://nouveau.tld' --dry-run
# Exécution
wp search-replace 'http://ancien.tld' 'https://nouveau.tld' --skip-columns=guid --report-changed-onlyЧесто съм виждал подмяната на guid Нарушаване на RSS емисии или логиката на импортиране. Следователно --skip-columns=guid в по-голямата част от миграциите.
7.3 Диагностициране на автоматично зареждане (често срещана причина за бавност)
Когато началната страница се зарежда за 2 секунди без причина, почти винаги проверявам опциите за автоматично зареждане за прекомерно тегло.
# Lister les plus grosses options autoload (nécessite MySQL/MariaDB accessible)
wp db query "
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 20;
"Коригирайте префикса wp_ ако е необходимо (или го извлечете чрез wp config get table_prefix).
7.4 Оптимизиране (с повишено внимание)
wp db optimizeПри някои управлявани хостинг планове тази команда е или забранена, или ненужна (оптимизацията се обработва от страна на инфраструктурата). Ако не успее, това не е непременно проблем.
Стъпка 8: wp-config, кеш, cron и планирани задачи
Тази стъпка обхваща операции, които разрешават „странни“ инциденти: непоследователни опции, блокиран cron, кеш, който крие корекция.
8.1 Четене/запис в wp-config.php
# Lire une constante
wp config get WP_DEBUG
# Activer WP_DEBUG (à faire sur staging ou temporairement)
wp config set WP_DEBUG true --raw
# Désactiver l'édition de fichiers via l'admin
wp config set DISALLOW_FILE_EDIT true --rawИстински капан: забравяне --raw записва низ вместо булева стойност. В крайна сметка получавате 'true' вместо trueМоже да изглежда, че „работи“, а след това да наруши дадено поведение.
8.2 Изчистване на определени кешове на WordPress
# Purger les transients expirés
wp transient delete --expired
# Purger les caches d'objets (si object cache actif)
wp cache flushПри кеширащите плъгини (WP Rocket, LiteSpeed Cache и др.), целият процес на почистване зависи от плъгина. Много от тях предоставят WP-CLI команда, но това не е стандартно. Проверете документацията на вашия плъгин.
8.3 Cron: Изброяване, изпълнение, дебъгване
# Lister les événements cron
wp cron event list
# Exécuter tous les événements dus
wp cron event run --due-now
# Exécuter un hook précis
wp cron event run action_scheduler_run_queueВ сайтовете на WooCommerce, екосистемата на Action Scheduler често е източник на „чакащи задачи“. Точният hook може да варира в зависимост от версията/плъгина, така че започнете с wp cron event list.
Стъпка 9: Минималистичен одит на сигурността (без фалшиви обещания)
WP-CLI не замества скенер за сигурност, но можете да направите много конкретен „хигиенен“ одит.
9.1 Проверка на целостта на ядрото
wp core verify-checksums9.2 Избройте администраторите и техните имейл адреси
wp user list --role=administrator --fields=ID,user_login,user_email,registered9.3 Идентифицирайте „mu-плъгините“ и дроп-ините
wp plugin list --field=name
wp plugin list --status=must-use
wp config get WP_CACHEDrop-in-овете (object-cache.php, advanced-cache.php) и mu-плъгините са често срещани места, където се намират критични персонализации... или изненади.
9.4 Проверка на ключовете за сигурност (без показването им)
Не искате да показвате солите си в споделен терминал. Вместо това, просто проверете дали константите съществуват:
wp config has AUTH_KEY
wp config has SECURE_AUTH_KEY
wp config has LOGGED_IN_KEY
wp config has NONCE_KEYСтъпка 10: Автоматизирайте с Bash скриптове + персонализирани WP-CLI команди
Две нива: Bash скрипт (прост, преносим), след това персонализирана WP-CLI команда (стандартизация от страна на WordPress).
10.1 Bash скрипт: „безопасна“ рутина за обновяване
Създаване на файл wp-update-routine.sh на вашата машина (или на сървъра), след което го направете изпълним.
#!/usr/bin/env bash
set -euo pipefail
# --- Configuration ---
WP_PATH="${WP_PATH:-/var/www/site/public}"
WP_URL="${WP_URL:-https://example.com}"
BACKUP_DIR="${BACKUP_DIR:-/tmp}"
timestamp="$(date +%F-%H%M%S)"
db_backup="${BACKUP_DIR}/db-${timestamp}.sql"
plugins_snapshot="${BACKUP_DIR}/plugins-${timestamp}.json"
themes_snapshot="${BACKUP_DIR}/themes-${timestamp}.json"
# --- Vérifications ---
wp --path="$WP_PATH" --url="$WP_URL" core is-installed >/dev/null
echo "[1/7] Activation maintenance"
wp --path="$WP_PATH" maintenance-mode activate
echo "[2/7] Backup DB: $db_backup"
wp --path="$WP_PATH" db export "$db_backup"
echo "[3/7] Snapshots plugins/thèmes"
wp --path="$WP_PATH" plugin list --format=json > "$plugins_snapshot"
wp --path="$WP_PATH" theme list --format=json > "$themes_snapshot"
echo "[4/7] MAJ core + DB"
wp --path="$WP_PATH" core update
wp --path="$WP_PATH" core update-db
echo "[5/7] MAJ plugins + thèmes"
wp --path="$WP_PATH" plugin update --all
wp --path="$WP_PATH" theme update --all
echo "[6/7] Flush caches"
wp --path="$WP_PATH" cache flush || true
wp --path="$WP_PATH" transient delete --expired || true
echo "[7/7] Désactivation maintenance"
wp --path="$WP_PATH" maintenance-mode deactivate
echo "OK: sauvegarde DB = $db_backup"Екзекуция:
chmod +x wp-update-routine.sh
WP_PATH=/var/www/site/public WP_URL=https://example.com ./wp-update-routine.shОчакван резултат: пълна актуализация с архивиране на базата данни и снимки. В случай на неуспех, скриптът спира (благодарение на set -e) и знаете на кой етап.
10.2 Персонализирана WP-CLI команда (mu-plugin): „bp audit“
Създаване на файл wp-content/mu-plugins/bp-cli-audit.phpАко файлът mu-plugins Ако не съществува, създайте го. Mu-плъгините се зареждат автоматично.
<?php
/**
* Plugin Name: BP CLI Audit
* Description: Commandes WP-CLI internes pour auditer rapidement un site.
* Author: Votre équipe
* Version: 1.0.0
*/
declare(strict_types=1);
if ( ! defined('WP_CLI') || ! WP_CLI ) {
// Sécurité : ne rien exécuter en contexte web.
return;
}
/**
* Petite commande d'audit orientée ops.
*
* Usage:
* wp bp audit
*/
final class BP_CLI_Audit_Command {
/**
* Affiche un audit synthétique (versions, thème, plugins actifs, autoload top).
*
* ## EXAMPLES
* wp bp audit
*
* @when after_wp_load
*/
public function audit( array $args, array $assoc_args ): void {
// 1) Versions
WP_CLI::log('--- Versions ---');
WP_CLI::log('WordPress: ' . get_bloginfo('version'));
WP_CLI::log('PHP: ' . PHP_VERSION);
// 2) Thème actif
$theme = wp_get_theme();
WP_CLI::log('--- Thème actif ---');
WP_CLI::log($theme->get('Name') . ' ' . $theme->get('Version'));
// 3) Plugins actifs
WP_CLI::log('--- Plugins actifs ---');
$active = (array) get_option('active_plugins', []);
if (empty($active)) {
WP_CLI::log('(aucun plugin actif)');
} else {
foreach ($active as $plugin_file) {
WP_CLI::log('- ' . $plugin_file);
}
}
// 4) Options autoload les plus lourdes (top 10)
global $wpdb;
WP_CLI::log('--- Autoload (top 10) ---');
// Attention : requête volontairement simple ; sur très gros sites, adaptez (index, LIMIT).
$results = $wpdb->get_results(
"SELECT option_name, LENGTH(option_value) AS bytes
FROM {$wpdb->options}
WHERE autoload = 'yes'
ORDER BY bytes DESC
LIMIT 10",
ARRAY_A
);
if (empty($results)) {
WP_CLI::log('(aucune donnée)');
return;
}
foreach ($results as $row) {
WP_CLI::log(sprintf('- %s : %d bytes', $row['option_name'], (int) $row['bytes']));
}
}
}
WP_CLI::add_command('bp audit', BP_CLI_Audit_Command::class);тест:
wp bp auditОчакван резултат: четлив одит, полезен при управление на инциденти. След това можете да го подобрите (cron, константи и др.).
Пълният резултат
На този етап имате:
- WP-CLI инсталиран и синхронизиран с вашия PHP,
- чисто насочване чрез
--path/--urlouwp-cli.yml, - скриптирана рутина за актуализиране с архивиране,
- mu-плъгин, който добавя команда за одит.
Бързо персонализиране
- Добави заключване за сигурност В скрипта: разрешаване на изпълнение само при подготовка (напр. проверка
WP_ENVIRONMENT_TYPEотwp option getили константа). - Регистриране във файл: пренасочване на stdout/stderr към
/var/log/wp-cli-ops.log. - На мултисайт: добавете
--networkза актуализации на плъгините, когато е необходимо.
Адаптиране за Divi 5 / Elementor / Avada
WP-CLI не е „специфичен“ за конструкторите на страници, но променя приоритетите ви за поддръжка.
Диви 5
- Актуализациите на Divi (тема/плъгин) често идват от платен канал. В CLI можете активиране/деактивиране, избройте версиите, но инсталацията/връщането назад зависи от вашия механизъм (zip, API, Elegant Themes manager).
- В сайтовете на Divi обръщам особено внимание на размера на ревизиите и автоматичното зареждане (конструктор на опции).
wp post list --post_type=revision --format=count
wp bp auditElementor
- Elementor + добавки = риск от каскадни несъвместимости. Направете моментна снимка на версиите (вече обхванати) и актуализирайте Elementor, преди да актуализирате определени добавки.
- Ако получите бял екран, първо деактивирайте добавките, след това Elementor, ако е необходимо.
wp plugin list | grep -i elementor
wp plugin deactivate elementor-pro
wp plugin deactivate elementorАвада (Fusion Builder)
- Авада често се съчетава с Fusion Core / Fusion BuilderСъщата логика: актуализирайте „ядрото“ на Avada по начин, който е съвместим с неговите плъгини.
- В Avada често съм виждал агресивно кеширане като маска за решение: purge plugin cache +
wp cache flush.
wp cache flush
wp transient delete --expiredПоследна проверка
- WP-CLI може да вижда сайта :
wp core is-installed wp core version - Без поддръжка, заключен режим :
wp maintenance-mode status - Последователни плъгини/теми :
wp plugin list --status=active wp theme list --status=active - Cron operative :
wp cron event list --fields=hook,next_run wp cron event run --due-now - Уеб тестове за дим (ръчно):
- начална страница,
- създател на страници (Divi/Elementor/Avada),
- вход за администратор,
- публикуване на чернова (ако е възможно на етап подготовка).
Ако резултатът не е такъв, какъвто се очаква
- Имате грешка „Не можа да се отвори входният файл: wp“
Провери това/usr/local/binе във вашияPATHили се обадете/usr/local/bin/wp --info. - WP-CLI показва, че WordPress не е инсталиран
Вие сте в грешната папка. Използвайте--pathили създайтеwp-cli.ymlПроверете също правата за четене наwp-config.php. - След актуализацията сайтът има фатална грешка.
Деактивирайте дефектния плъгин:wp plugin deactivate nom-du-pluginПроверете PHP лог файловете. Ако сте актуализирали без snapshot, ще си загубите време. - Търсенето със замяна наруши някои URL адреси.
Вероятно сте го заменили с нещо твърде общо (напр. „включи“guid(или заменете подниз, присъстващ в JSON данните). Възстановете базата данни от експорта, след което започнете отново с--dry-runи по-строги модели. - Промените не са видими
Кеш: изчистване на кеша/CDN на плъгина, след товаwp cache flushОт страна на браузъра, тествайте в режим на частно сърфиране.
Често срещани капани и грешки
| Грешка | Причина | Решение |
|---|---|---|
изпълнява wp search-replace за продукцията „да върви бързо“ |
Без подготовка + без резервно копие | Експортиране на база данни преди това, --dry-runпрозорец за поддръжка, валидиране |
употреба --allow-root Partout |
Лош навик / копирани скриптове | Коригирайте разрешенията, използвайте специален потребител, документирайте изключението |
| Изтриването на редакции с една команда е неуспешно | Ограничение на дължината на командата на Shell | Изтриване на групи (вижте по-долу) |
WP_DEBUG дефинирано в низ |
Забравяне --raw |
wp config set WP_DEBUG true --raw |
| Бавни WP-CLI команди | Огромна автоматично зареждаща се/бавна база данни/DNS | Одит на автоматично зареждане, оптимизиране на базата данни, проверка на мрежата |
Изтриване на редакции на партиди (устойчив модел)
# Supprimer 500 révisions à la fois
while true; do
ids="$(wp post list --post_type=revision --posts_per_page=500 --format=ids)"
if [ -z "$ids" ]; then
break
fi
wp post delete $ids --force
doneВариант / алтернатива
Алтернатива без SSH: плъгин „WP Crontrol“ + инструменти за администриране
Ако нямате SSH, можете да получите достъп до някои задачи чрез администраторския интерфейс:
- управление на cron чрез плъгин (напр. WP Crontrol),
- управление на плъгини/теми чрез интерфейса,
- експортиране на база данни чрез хостинг доставчика (phpMyAdmin, управляеми инструменти).
Губите възпроизводимост и прецизно регистриране. За напреднали сайтове това често е временен компромис.
По-напреднала алтернатива: стартирайте WP-CLI в контейнер (Docker) възможно най-близо до производствената среда.
Ако имате контейнеризиран стек, стартирайте WP-CLI в същия PHP контейнер (същите разширения, същият ini файл). Това е най-добрият начин да избегнете несъответствия между CLI/уеб.
Съвети за безопасност, производителност и поддръжка
- Дневник Пренасочвайте изходите си към лог и дръжте експортите на базата данни извън сървъра, когато е възможно.
- Избягвайте тайни Не съхранявайте пароли като обикновен текст в скриптове. Използвайте променливи на средата, инжектирани от мениджър на секрети.
- Стандартизирайте : A
wp-cli.ymlна проект + mu-плъгин с вътрешни команди = по-малко човешки грешки. - Тестване в тестова среда Конструкторите на страници и техните добавки понякога имат изненадващи съвместимости; „незначителна“ актуализация може да повреди модул.
- Следете автоматичното зареждане : това е подценен източник на бавност, особено при плъгини, които съхраняват JSON blob-ове.
За да се отиде по-далеч
- Добавяне на команда
wp bp preflightкоято проверява: дисково пространство, версия на PHP, критични плъгини и блокове, ако дадено условие не е изпълнено. - Интегрирайте WP-CLI във вашата CI: PHP lint, тестове и след това
wp core verify-checksumsв ефимерна среда. - Създайте рутина за „инциденти“: каскадно деактивиране на плъгини, постепенно повторно активиране, експортиране на лог файлове, заснемане
site health info. - За многосайтови: мрежови команди (
wp site list,wp plugin activate --network) и специфични за обекта одитни скриптове.
ресурси
- WP-CLI (официален уебсайт)
- Справочник за разработчици: WP-CLI команди
- WP-CLI GitHub хранилище
- wp_get_theme() (препратка)
- get_option() (препратка)
- клас wpdb (препратка)
- WordPress Core Trac (проследяване на промените)
- wordpress-develop (GitHub огледало на ядрото)
- PHP CLI (ръчно)
Често задавани въпроси
WP-CLI „съвместим“ ли е с WordPress 6.9.4?
Да, стига да използвате скорошна версия на WP-CLI и съвместим PHP. Критичният момент не е WordPress, а подравняването. PHP CLI срещу PHP уебЗапочнете от wp --info.
Как да избегнем изпълнението на команди на грешен сайт?
Използвайте систематично --path et --url във вашите скриптове или wp-cli.ymlНа многосайтови сървъри това е разликата между чиста рутина и инцидент.
Това е wp search-replace Безопасно ли е за сериализирани данни?
WP-CLI обработва много случаи правилно, но „безопасно“ зависи от това какво замествате. Винаги го правете. --dry-runизбягвам guid В повечето случаи дръжте експортирана база данни готова за възстановяване.
Как да деактивирам плъгин, ако администраторският панел е недостъпен?
wp plugin deactivate nom-du-pluginАко не знаете кой от тях, деактивирайте всичко (--all), след което постепенно реактивирайте.
Може ли Divi/Avada да се актуализира чрез WP-CLI?
Можете да управлявате активирането/деактивирането и инвентара. За актуализациите всичко зависи от техния канал (премиум, zip, API). На практика често автоматизирате това, като изтеглите zip файла. wp theme install/wp plugin install с --force.
Как да изброя cron задачите, които достигат капацитет?
Започнете с wp cron event listсортиране по следващо изпълнение и изпълнение wp cron event run --due-nowВ WooCommerce следете куките, свързани с Action Scheduler.
Pourquoi wp cache flush Не променя ли нищо?
Защото основният ви кеш може да е кеш на страница (плъгин) или CDN. wp cache flush Фокусирайте се предимно върху кеша на обектите. Също така, изчистете кеша на плъгините и CDN.
Как да стартирам WP-CLI на мултисайт?
употреба --url да се насочите към даден сайт и --network За определени мрежови операции (напр. мрежово активиране на плъгини), проверете с wp site list ако командата е налична във вашия контекст.
Може ли WP-CLI да поправи „цикъл на пренасочване“ след миграция?
Често да: проверете home et siteurl (wp option get home, wp option get siteurl), след което го коригирайте. Пренасочванията могат да идват и от прокси/CDN (заглавки) или плъгина за кеширане.
Каква е най-добрата практика за споделяне на WP-CLI скриптове в екип?
Git хранилище за „ops“ + променливи на средата + mu-плъгин за вътрешни команди. Получавате версирани, преглеждаеми и последователни рутини в различните сайтове.