Bash WP-CLI Update — bash-скрипт, который обновляет ядро, плагины и темы WordPress на парке сайтов, заходя в каждый под его владельцем, с дампом базы до изменений, JSON-отчётом и путём восстановления. Релиз 8.0.4, опубликованный 21 октября 2026 года, — про упаковку, а не про код: менеджер, поисковик и все режимы остались ровно теми же, зато появился npm-пакет из двух обёрток, а README и AGENTS.md получили раздел о трёх путях установки вместо одного. Между 8.0.3 и 8.0.4 ровно один коммит и одиннадцать изменённых файлов. Практическая ценность материала не в новости, а в проверке: прежде чем звать читателя ставить инструмент одной командой из npm, стоит убедиться, что пакет там есть — и на 24 октября 2026 года его в публичном реестре нет.

Bash WP-CLI Update 8.0.4 — обложка релиза
Релиз про доставку: npm-пакет, install.sh и ручная установка

TL;DR

  • Bash WP-CLI Update 8.0.4 от 21.10.2026 — только доставка: менеджер, поисковик и режимы не изменились.
  • Добавлен npm-пакет bash-wp-cli-update с двумя обёртками wp-cli-update и wp-find; обёртки находят свой настоящий путь и передают скрипту исходные аргументы.
  • npm не ставит WP-CLI и ничего не запускает при установке; root на хосте всё равно нужен.
  • Проверено 24.10.2026: npm install -g bash-wp-cli-update пока не работает — в реестре пакета нет (HTTP 404). Рабочие пути: install.sh и клон репозитория.
  • Лицензия PolyForm Noncommercial 1.0.0, пакет помечен os: linux: на macOS со встроенным bash 3.2 инструмент не пойдёт.

Что нового

Релиз добавляет третий канал доставки. Пакет bash-wp-cli-update несёт те же два скрипта без изменений плюс две обёртки, bin/wp-cli-update и bin/wp-find: npm ставит их символическими ссылками, поэтому каждая обёртка сначала находит свой настоящий путь, а затем exec-ом запускает скрипт ровно с теми аргументами, которые получила. Список files в package.json — белый: в архив попадают скрипты, пример конфигурации, contrib/, install.sh и документация, всего 18 файлов объёмом около 107 КБ. Лицензия пакета — PolyForm Noncommercial 1.0.0, os — linux, потому что инструменту нужны bash 4.2 и GNU coreutils, а в macOS до сих пор bash 3.2.

Важная формулировка из заметок к релизу: npm здесь канал доставки, а не установщик. Он не ставит WP-CLI и не выполняет ничего в момент установки; root по-прежнему требуется во время работы, потому что менеджер переключается в владельца каждого сайта. Требования к хосту не изменились: bash >= 4.2, coreutils и findutils, wp в известном месте или WP_CLI_PATH, одна из программ runuser/sudo/su; опционально flock, timeout, tar, gzip, nice, ionice, curl, mail.

Вторая часть релиза — документация и репозиторий. В README раздел 3 теперь перечисляет три пути (npm, install.sh, вручную) и прямо говорит, чего npm-путь не делает; в AGENTS.md то же самое изложено для агента. .gitignore перестал игнорировать bin/: там лежат обёртки, а неотслеживаемая обёртка не может попасть в публикуемый пакет.

Что Подробности
npm-пакет bash-wp-cli-update, версия 8.0.4, os: linux, node >= 16
Что кладёт на PATH wp-cli-update и wp-find (через bin/-обёртки)
Состав архива 18 файлов, около 107 КБ, files — белый список
Лицензия PolyForm Noncommercial 1.0.0
Что npm не делает не ставит WP-CLI, ничего не запускает при установке
Изменено между 8.0.3 и 8.0.4 1 коммит, 11 файлов

Что не изменилось

Заметки к релизу говорят это прямо: в менеджере, поисковике и ни в одном режиме изменений нет. Если хост уже стоит на 8.0.3 и работает, обновление не приносит ни новых флагов, ни исправлений поведения — только способ получить те же файлы другим путём. Это редкий и полезный случай, когда апгрейд можно спокойно отложить до планового окна.

Ключевые изменения

Что Было (8.0.3) Стало (8.0.4)
Способы установки install.sh и клон репозитория три пути: npm, install.sh, вручную
Команды на PATH символические ссылки, созданные вручную плюс обёртки bin/wp-cli-update, bin/wp-find из пакета
Каталог bin/ игнорировался .gitignore коммитится: обёртки нужны для публикации
Документация раздел об установке в общем виде README §3 и AGENTS.md §3 перечисляют три пути и границы npm-пути
Код менеджера и режимы — без изменений

Файлы в релизе

Файл Размер SHA-256
bash-wp-cli-update-8.0.4.tar.gz 161 КБ (164 842 байта) dfc9b6ade2d9eaa9b5b1a4046301164264da7c38d65ecaba27240644de07ccfc
SHA256SUMS 98 байт —

Контрольная сумма лежит рядом с архивом и перечисляет имена без пути, поэтому проверка работает из каталога, куда скачаны оба файла:

sha256sum -c SHA256SUMS

Как обновиться

Штатный путь — install.sh из репозитория: он делает то же, что описано в README, и его можно запускать дважды, потому что ни один шаг не удаляет и не перезаписывает существующее без --force. Сначала сухой прогон, потом установка.

git clone https://github.com/paulmann/Bash_WP-CLI_Update.git
cd Bash_WP-CLI_Update
./install.sh --dry-run
sudo ./install.sh

Установщик раскладывает скрипты в PREFIX/lib/wp-cli-update/, делает ссылки PREFIX/bin/wp-cli-update и wp-find, создаёт каталоги /var/log/wp-cli-update, /var/backups/wp-cli-update, /var/lib/wp-cli-update и кладёт /etc/wp-cli-update.conf, только если его ещё нет. Он не запускает поиск сайтов, не трогает ни один сайт и ничего не стартует; при желании сразу ставится таймер systemd.

sudo ./install.sh --prefix /opt/wp --config /etc/wp-cli-update.conf --systemd

npm-путь в заметках к релизу выглядит так, но на 24.10.2026 команда возвращает ошибку, потому что пакета в реестре нет:

npm install -g bash-wp-cli-update

Если ставите по этому пути, помните: обёртки кладутся в $(npm prefix -g)/bin, а каталоги и конфигурацию всё равно создаёт install.sh или ваши руки — шаги 3.3 и 3.4 из AGENTS.md npm не заменяет.

Что проверить после обновления

sudo wp-cli-update --version
sudo wp-cli-update --doctor
sudo wp-cli-update --check
sudo wp-cli-update --health
sudo wp-cli-update --full --site /srv/www/example.com --dry-run
sudo wp-cli-update --status

Критерий «работает»: --doctor называет бинарник wp и механизм переключения пользователя, --check завершается кодом 0 и печатает по галочке на сайт, --health выводит таблицу, сухой прогон на одном сайте показывает ровно те команды, которые будут выполнены. Путь к сайту в примерах — /srv/www/example.com; подставьте свой, вид каталога здесь не важен. Только после этого имеет смысл запускать парк целиком:

sudo wp-cli-update --full --jobs 4 --backup db --report /var/log/wp-cli-update/run.json

Совместимость и требования

Параметр Значение
ОС Linux; пакет помечен os: linux
Оболочка bash >= 4.2 (встроенный в macOS bash 3.2 не подходит)
Обязательное GNU coreutils/findutils, WP-CLI, root, одна из runuser/sudo/su
Опциональное flock, timeout (или perl), tar, gzip, nice, ionice, curl, mail
Node (для npm-пути) >= 16
Лицензия PolyForm Noncommercial 1.0.0

Одна оговорка до установки: конфигурация — это файл KEY=VALUE, который никогда не подключается через source. Любая обратная кавычка, $(, |, ;, &, < или > в строке приводит к отказу от всего файла, а групповые и мировые права на запись дают код выхода 4, потому что в конфигурации может лежать лицензионный ключ Astra.

Кому это нужно

Первый сценарий — хостинг или студия с десятком-другим сайтов на WordPress: одна команда обновляет всё, каждый сайт под своим владельцем, с дампом базы и отчётом, где видно plugin jetpack 13.0 -> 13.5. Второй — дежурный, которому нужен не апгрейд, а ответ: --health показывает, что и где ждёт обновления, не беря блокировку и ничего не записывая, поэтому его можно дёргать из мониторинга хоть каждую минуту.

Подводные камни

  • npm-канал объявлен, но пока не работает. На 24.10.2026 https://registry.npmjs.org/bash-wp-cli-update отвечает 404, поиск по реестру пакета не находит. Пробуйте команду перед тем, как вписывать её в runbook; рабочие пути — install.sh и клон репозитория.
  • npm не заменяет установщик. Он не приносит WP-CLI, не создаёт каталоги и конфигурацию и ничего не запускает. Хост, на котором есть только npm-пакет, работать не будет.
  • Лицензия не для коммерческого использования. PolyForm Noncommercial 1.0.0 — это не MIT: использовать инструмент в коммерческой инфраструктуре без отдельной лицензии нельзя, и это стоит проверить до раскатки на парк.
  • Обновление можно не спешить. Менеджер и режимы не изменились, поэтому 8.0.4 не приносит исправлений поведения: если 8.0.3 работает, релиз касается только способа доставки.
  • Первый запуск — не на проде и не с --full. Порядок из AGENTS.md: установка, --doctor, --check, один сайт с --dry-run, один сайт по-настоящему, и только потом парк.

FAQ

npm сам поставит WP-CLI?

Нет. По заметкам к релизу и по AGENTS.md npm — канал доставки: он кладёт на PATH обёртки wp-cli-update и wp-find, но WP-CLI, каталоги и конфигурацию готовит оператор. Root во время работы всё равно нужен: менеджер переключается в владельца каждого сайта.

Можно ли поставить на macOS?

Нет. Пакет помечен os: linux, а инструмент требует bash 4.2 и GNU coreutils — встроенный в macOS bash 3.2 не подойдёт. Для проб на ноутбуке нужен контейнер или виртуальная машина с Linux.

Что изменилось в самом менеджере обновлений?

Ничего. Заметки к релизу говорят прямо: ни менеджер, ни поисковик, ни один режим не менялись. Между 8.0.3 и 8.0.4 один коммит и одиннадцать файлов — обёртки, package.json, .gitignore и документация.

Можно ли запускать два обновления одновременно?

Менеджер берёт блокировку и при занятом локе падает с кодом 3, а --lock-wait позволяет подождать вместо немедленного отказа. Read-only режимы (--health, --check, --doctor) блокировку не берут, поэтому мониторинг не мешает ночному прогону.

Итог

8.0.4 — честный служебный релиз: он не делает инструмент лучше, он делает его доступнее, добавляя третий канал доставки и честно оговаривая, чего этот канал не умеет. Ценность для читателя здесь в двух вещах: install.sh с --dry-run снимает риск «поставил и не понял, что изменилось», а проверка реестра перед публикацией команды избавляет от часа диагностики на пустом месте. Если парк WordPress уже обслуживается этим менеджером на 8.0.3, обновляться не обязательно — но новый хост теперь удобнее ставить через установщик, а не руками.

Цитата: Пакет в npm — это не установщик, а дверь; открывать её стоит, только когда точно знаешь, что за ней лежит WP-CLI, каталоги и конфигурация, которых npm не приносит.

Связанные материалы

LLM Summary

  • Тема: Bash WP-CLI Update — bash-менеджер обслуживания парка WordPress через WP-CLI; релиз 8.0.4 касается только доставки.
  • Версия: v8.0.4, опубликована 21 октября 2026 года; предыдущая v8.0.3 в тот же день, между ними 1 коммит и 11 файлов.
  • Что изменилось: добавлен npm-пакет bash-wp-cli-update с обёртками wp-cli-update и wp-find; README §3 и AGENTS.md §3 описывают три пути установки; bin/ больше не в .gitignore. Код менеджера и режимы не менялись.
  • Ключевые команды: ./install.sh --dry-run, sudo ./install.sh, sudo wp-cli-update --doctor, sudo wp-cli-update --check, sudo wp-cli-update --health, sudo wp-cli-update --full --jobs 4 --backup db --report /var/log/wp-cli-update/run.json.
  • Требования: Linux, bash 4.2+, GNU coreutils, WP-CLI, root и runuser/sudo/su; для npm-пути node >= 16; macOS не поддерживается.
  • Основные риски: пакета bash-wp-cli-update на 24.10.2026 нет в реестре npm (HTTP 404); npm не ставит WP-CLI и не создаёт каталоги; лицензия PolyForm Noncommercial 1.0.0 запрещает коммерческое использование без отдельной лицензии.
  • Проверка результата: --doctor находит wp и механизм переключения пользователя, --check выходит с кодом 0 по каждому сайту, --health печатает таблицу, сухой прогон одного сайта показывает ожидаемые команды.
  • Кому полезно: администраторам парков WordPress на Linux и дежурным, которым нужен read-only обзор ожидающих обновлений.
  • Ссылки: https://github.com/paulmann/Bash_WP-CLI_Update/releases/tag/v8.0.4, https://github.com/paulmann/Bash_WP-CLI_Update

Промт для агента (установка)

Готовый промт для AI-агента: скопируйте блок целиком кнопкой и отдайте своему ассистенту. Шаги и команды взяты из файла AGENTS.md в репозитории проекта — это инструкция, которую автор написал для агентов, а не пересказ.

Задача: установить Bash WP-CLI Update 8.0.4 на Linux-хост, проверить его и обновить один сайт.

Материалы:
- релиз: https://github.com/paulmann/Bash_WP-CLI_Update/releases/tag/v8.0.4
- репозиторий: https://github.com/paulmann/Bash_WP-CLI_Update
- инструкция для агентов (прочитать целиком первой): https://github.com/paulmann/Bash_WP-CLI_Update/blob/main/AGENTS.md

Два правила из AGENTS.md, которые важнее остальных:
1) никогда не запускать изменяющий режим на боевом хосте с первого раза — установка, --doctor, --check, один сайт с --dry-run, один сайт по-настоящему;
2) никогда не удалять бэкап, файл сайта или базу, чтобы «прибраться» после неудачного прогона: остановиться и доложить.

Предусловия (§2), каждую строку сравнить с ожидаемым ответом; расхождение — стоп и отчёт, а не молчаливый обход:
bash --version | head -1
id -u
command -v wp
command -v runuser || command -v sudo || command -v su
command -v flock; command -v timeout; command -v tar; command -v gzip
php -v | head -1

Установка (§3): npm-путь объявлен, но на 24.10.2026 пакета нет в реестре, поэтому идём путём репозитория:
sudo git clone https://github.com/paulmann/Bash_WP-CLI_Update.git /opt/wp-cli-update
sudo chmod 755 /opt/wp-cli-update/Bash_WP-CLI_Update.sh /opt/wp-cli-update/Find_WP_Senior.sh
sudo ln -sf /opt/wp-cli-update/Bash_WP-CLI_Update.sh /usr/local/bin/wp-cli-update
sudo ln -sf /opt/wp-cli-update/Find_WP_Senior.sh   /usr/local/bin/wp-find
sudo install -d -m 755 /var/log/wp-cli-update /var/backups/wp-cli-update /var/lib/wp-cli-update
sudo install -m 600 /opt/wp-cli-update/wp-cli-update.conf.example /etc/wp-cli-update.conf

Конфигурация (§3.5): минимум — WP_CLI_PATH, SITES_FILE, AUTO_DISCOVER=0, LOG_FILE, ERROR_LOG_FILE, BACKUP=db, BACKUP_DIR, KEEP_BACKUPS, MIN_FREE_MB, JOBS, TIMEOUT. Файл никогда не подключается через source: обратная кавычка, $(, |, ;, &, < или > в строке отклоняют весь файл. Права 600 обязательны.

Список сайтов (§3.6):
sudo wp-find --output /var/lib/wp-cli-update/wp-found.txt /srv/www /home
sudo wc -l /var/lib/wp-cli-update/wp-found.txt
sudo wp-cli-update --list-sites

Проверка по порядку (§4), шаг не пропускать:
sudo wp-cli-update --doctor
sudo wp-cli-update --check
sudo wp-cli-update --health
sudo wp-cli-update --full --site /srv/www/example.com --dry-run
sudo wp-cli-update --full --site /srv/www/example.com --backup db
sudo wp-cli-update --status

Только после этого — парк целиком:
sudo wp-cli-update --full --jobs 4 --backup db --report /var/log/wp-cli-update/run.json

Ограничения:
- не запускать тесты под root «чтобы прошли проверки переключения пользователя»: на обычной учётке они честно дают SKIP;
- не отключать fail-on и не менять JOBS/BACKUP «временно»: фактическое состояние показывает --print-config;
- не удалять маркеры .no_wp_cli, локи активных прогонов и бэкапы;
- не запускать --restore-db без причины и без --yes: он перезаписывает живую базу;
- если команда падает — остановиться и показать команду, вывод и код возврата.

Что считать успехом: --doctor называет бинарник wp и механизм переключения пользователя; --check завершается кодом 0 с галочкой по каждому сайту; --health печатает таблицу; сухой прогон одного сайта показывает ожидаемые команды; настоящий прогон одного сайта завершается кодом 0, а в отчёте .sites и .changes соответствуют увиденному.