Массовое редактирование записей в WordPress: что выбрать

Если нужно изменить категорию у 300 записей, заменить автора у 2 000 или снять с публикации архивный раздел, открывать записи по одной — плохой план. В WordPress 6.x для такой задачи есть четыре подхода: встроенное массовое редактирование, табличные плагины, WP-CLI и прямой SQL. Они дают разную скорость, точность отката и цену ошибки.

Сначала определите, что именно меняется

«Массово отредактировать записи» может означать совершенно разные операции. От этого зависит инструмент.

• Стандартные поля: статус, автор, рубрика, метки, комментарии, закрепление, пароль и шаблон, если эти поля доступны для конкретного типа записи.
• Текст и заголовки: замена фразы, удаление блока, единообразное изменение формулировок.
• Произвольные поля: цены, артикулы, даты, SEO-параметры и значения, добавленные темой или плагином.
• Связи и таксономии: перенос записей между рубриками, добавление терминов, работа с пользовательскими типами записей.

Встроенный экран WordPress хорошо справляется с первым пунктом. Для текста и произвольных полей он почти бесполезен. WP-CLI подходит для повторяемых операций и больших выборок, но требует доступа к серверу и умения проверить результат.

Чем быстрее способ меняет записи, тем дороже ошибка. Перед массовой операцией важнее подготовить выборку и откат, чем найти самый короткий путь.

Сноска. Произвольное поле — дополнительное значение записи, которое хранится отдельно от заголовка и основного текста. Его используют темы, SEO-плагины, каталоги и системы импорта.

Четыре подхода и их цена

Таблица показывает важное различие: табличный плагин оптимизирует ручную работу, а WP-CLI — повторяемую операцию. Это не взаимозаменяемые инструменты.

Встроенное редактирование: лучший первый вариант

В админке откройте список записей, отметьте нужные строки и выберите действие «Изменить» или «Редактировать» в массовых действиях. Набор полей зависит от версии WordPress, типа записи и зарегистрированных возможностей этого типа.

Метод подходит, если нужно:

• перенести записи в одну или несколько рубрик;
• добавить или удалить метки;
• сменить автора;
• изменить статус публикации;
• включить или выключить комментарии;
• снять или установить признак закреплённой записи.

Ограничение часто обнаруживается слишком поздно: на экране показана только текущая страница списка. Если фильтр или поиск вернул много записей, проверьте, что в выборку попали все нужные строки, а не первые 20 или 100. Число записей на странице задаётся в настройках экрана, но слишком большое значение может замедлить админку.

Когда встроенного режима достаточно

Выберите его, если операция выполняется один раз, затрагивает стандартные поля и её можно визуально проверить. Например, перенос 80 старых публикаций из рубрики «Новости» в «Архив» безопаснее сделать через админку, чем писать запрос к базе.

Цена подхода — ручная проверка и ограниченная гибкость. Сменить часть слова в 500 заголовках, заполнить произвольное поле или отобрать записи по нескольким условиям стандартный интерфейс обычно не позволяет.

Табличный плагин: когда важна визуальная проверка

Плагины для массового редактирования показывают записи в виде таблицы: строки — записи, столбцы — поля. Значение можно изменить прямо в ячейке, а затем сохранить группу изменений. Это удобнее админки, если редактору нужно сравнивать записи глазами, а не запускать команду.

Что проверить до установки

1. Какие поля поддерживаются. Уточните, видит ли расширение заголовок, основной текст, рубрики, метки, произвольные поля, изображения и пользовательские таксономии. Название «массовое редактирование» не означает поддержку всего объекта записи.
2. Есть ли фильтры. Нужны условия по типу записи, автору, статусу, дате, рубрике и значению поля. Без фильтра таблица превращается в длинный список с высоким риском выбора не тех строк.
3. Как работает сохранение. Узнайте, сохраняет ли плагин каждую строку отдельно, показывает ли ошибки и умеет ли отменять изменения. Автоматического отката у таких решений может не быть.
4. Что происходит с хуками и кэшем. Обновление через плагин может запускать обработчики WordPress и сторонних расширений. После операции проверьте страницы, карту сайта, поиск и кэш.

Табличный способ хорош для редакционной команды: человек видит результат до сохранения и может поправить 30–500 строк без доступа к серверу. Он хуже подходит для регулярных ночных операций, миграций и выборок вроде «все записи с полем X, созданные до даты Y».

WP-CLI: выбор для повторяемых операций

WP-CLI 2.x запускает команды WordPress из терминала. Его преимущество не в том, что он всегда быстрее клика по админке, а в воспроизводимости: фильтр, список идентификаторов и порядок действий можно сохранить, проверить и повторить на тестовом сайте.

Перед использованием нужны SSH-доступ, установленный WP-CLI, резервная копия и понимание того, в какой директории находится сайт. Команды нужно выполнять от пользователя и в окружении, где загружен нужный WordPress. На продакшене сначала запускайте операцию на копии сайта.

Как строить безопасную процедуру

1. Сначала получите список. Выведите идентификаторы и ключевые поля будущей выборки. Не меняйте данные на этом этапе. Проверьте количество строк и несколько записей вручную.
2. Сохраните исходные значения. Для важных полей выгрузите идентификатор записи, старое значение и новое значение. Это будет основой для обратной операции.
3. Ограничьте выборку. Используйте одновременно тип записи, статус, рубрику, автора или диапазон дат, если это соответствует задаче. Один широкий фильтр хуже двух независимых ограничений.
4. Выполните небольшую пробную партию. Измените несколько записей на копии сайта и проверьте публичную страницу, админку, поиск и связанные поля.
5. Запустите полную операцию порциями. После каждой порции сравнивайте количество обработанных записей с планом. При расхождении остановитесь, а не продолжайте «до конца».

Если операция должна менять не только запись, но и данные конкретного плагина, сначала изучите документацию этого плагина. Простое обновление поля в базе или стандартного объекта не гарантирует, что расширение перестроит свой индекс, кэш или связанные таблицы.

Почему прямой SQL почти всегда последний вариант

В базе WordPress данные записи распределены не в одной таблице: основной объект хранится отдельно от произвольных полей и таксономий. У плагинов могут быть собственные таблицы, индексы и фоновые задачи. Поэтому запрос, который быстро меняет нужные строки, может оставить сайт в противоречивом состоянии.

Прямой SQL оправдан при миграции, когда структура данных известна, есть резервная копия и предусмотрена проверка связей. Для обычного редакционного изменения безопаснее использовать WordPress API через админку, WP-CLI или специально написанный скрипт. Даже при работе с базой сначала сохраните выборку, выполните пробу на копии и проверьте, как приложение читает изменённые данные.

Когда что выбирать

• До нескольких сотен записей и стандартные поля: встроенное массовое редактирование.
• Много ручных изменений в разных полях: табличный плагин с фильтрами и журналом изменений.
• Операция повторяется или выборка сложная: WP-CLI 2.x и сохранённая процедура.
• Миграция между структурами данных: отдельный скрипт или миграционный процесс после анализа схемы, а не быстрый SQL в продакшене.

Главный критерий — не размер списка сам по себе. Если ошибку можно обнаружить только после публикации, выбирайте способ с предварительным просмотром и журналом. Если операцию придётся повторить через месяц, выбирайте воспроизводимый сценарий, а не ручную таблицу.

Что ломается чаще всего

Выбраны не все записи

Причина — пагинация, неверный статус или фильтр только по видимому экрану. До изменения сохраните список идентификаторов и сравните его с ожидаемым количеством.

Рубрика изменилась, а сайт показывает старое

Обычно это кэш страницы, объекта или поискового индекса. Очистите кэш по правилам конкретной системы и проверьте несколько URL из разных групп. Не начинайте повторную массовую операцию, пока не выяснили, изменились ли данные в базе или только отображение.

Исчезли значения произвольных полей

Некоторые инструменты при сохранении отправляют пустое значение вместо «оставить как было». Перед работой на копии проверьте поведение на записи с заполненным и пустым полем.

Плагин перестал видеть записи

Возможна несовместимость с версией WordPress, типом записи или редактором. Проверьте расширение на тестовой копии, отключая плагины только там. На рабочем сайте не включайте режим отладки и эксперименты без плана отката.

Что делать дальше

Начните с инвентаризации: тип записи, количество объектов, поля для изменения и способ проверки результата. Затем сделайте копию базы и файлов, выберите один подход и проведите пробную операцию на небольшой группе. Для WP-CLI сохраните список идентификаторов и журнал изменений, а после запуска проверьте публичные страницы, поиск, кэш и данные плагинов.

Если массовые изменения становятся регулярной задачей, измеряйте не только время выполнения, но и число ошибок, повторных запусков и ручных исправлений. Именно эти показатели покажут, пора ли переходить от админки к воспроизводимой автоматизации.