WordPress Search and Replace

WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…

WordPress сохраняет абсолютные URLs в десятках таблиц базы данных, поэтому при смене домена или переходе на SSL старые адреса разбросаны по постам, опциям и настройкам плагинов: поиск и замена это способ безопасно их очистить. Это руководство охватывает два поддерживаемых способа сделать это в KPanel, объясняет, почему один распространённый третий метод повреждает данные, и как проверить результат.

Когда вам это нужно

Переход с http:// на https:// после включения SSL.
Смена домена, например с old-brand.co.nz на new-brand.co.nz.
После развёртывания staging на production, когда имя хоста staging всё ещё записано в базу данных.
Отказ от старого хоста активов и переадресация всех URL изображений на новый.
Исправление массовой опечатки в множестве постов, например старого номера телефона или снятого с производства названия товара.

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

Почему вы не можете просто запустить SQL REPLACE

Это наиболее разрушительная ошибка в работе с базой данных WordPress, поэтому стоит разобраться перед тем как выбрать метод.

WordPress хранит параметры плагинов, опции темы и данные виджетов в виде сериализованных строк PHP. Сериализованная строка записывает длину каждого значения внутри неё, вот так:

a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}

Это s:26 говорит что URL имеет длину 26 символов. Замените http:// на https:// используя простой SQL REPLACE() и текст станет 27 символов в то время как записанная длина всё ещё утверждает 26. PHP затем отказывается десериализовать весь параметр и параметр молча возвращается к пустому. Параметры настройщика темы исчезают, слайдеры теряют свои слайды, лицензии плагинов отменяют свою регистрацию.

WP-CLI поиск и замена который запускает KPanel десериализует каждое значение, заменяет внутри него и повторно сериализует с исправленными длинами. Вот почему это единственный метод задокументированный здесь.

Никогда не запускайте UPDATE wp_options SET option_value = REPLACE(...) или эквивалент в phpMyAdmin для базы данных WordPress. Выглядит как сработало, сообщает о затронутых строках и тихо уничтожает каждый сериализованный параметр который оно коснулось. Нет способа восстановления кроме как восстановление из резервной копии.

Метод 1: Карточка поиска и замены

Это правильный выбор для почти всех. Он доступен на каждом плане WordPress.

Войдите в KPanel и нажмите Websites на левой боковой панели.
Нажмите на сайт.
Откройте вкладку WordPress, затем раздел Quick Actions.
Найдите карточку Search & Replace и нажмите Configure.
Введите существующий текст в Find (old value).
Введите новый текст в Replace with.
Оставьте галочку на Dry run (preview only, no changes) и нажмите Preview.

Тестовый запуск сообщает сколько замен будет сделано и разбивает подсчёт по таблицам и столбцам, поэтому вы можете увидеть ровно куда упадёт изменение прежде чем вы подтвердите его.

Когда предпросмотр выглядит правильно:

Снимите галочку с Dry run.
Нажмите Run.
Подтвердите диалог.

Полная резервная копия снимается автоматически перед началом замены и запуск охватывает все таблицы включая созданные плагинами.

Ищите самую конкретную строку которую можете. Замена old-domain.co.nz также переписывает mail.old-domain.co.nz и staging.old-domain.co.nz что редко это то что вам нужно. Включение схемы как в https://old-domain.co.nz делает совпадение более точным.

Метод 2: WP-CLI из консоли

Консоль даёт вам тот же движок с большей контролью над флагами. Это один из разделов которые появляются на управляемых планах; на других планах полоса вкладок показывает ссылку +8 on Managed вместо этого.

Откройте сайт затем WordPress затем Console. Приглашение уже начинается с wp поэтому вводите только остальную часть команды.

Сначала предпросмотр:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run

Затем запустите её по-настоящему:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables

Консоль не создаёт резервную копию для вас. Автоматическое резервное копирование перед запуском происходит только когда вы используете карточку Search & Replace в Методе 1. Если вы запустите команду здесь, создайте резервную копию сами сначала из вкладки Backups сайта.

Полезные флаги:

Флаг	Что он делает
`--all-tables`	Включает пользовательские таблицы созданные плагинами не только основные таблицы WordPress
`--dry-run`	Сообщает что будет изменено и ничего не писал
`--precise`	Использует PHP вместо SQL для замены. Медленнее но обрабатывает сложные сериализованные структуры
`--skip-columns=guid`	Оставляет GUID поста в покое (см. ниже)
`--report-changed-only`	Обрезает вывод до таблиц которые действительно изменились

Примечание о GUID

Каждый пост WordPress имеет столбец guid. Несмотря на то что выглядит как URL это идентификатор не ссылка и средства чтения ленты используют его чтобы определить видели ли они уже этот элемент. Переписывание его может сделать каждый пост в вашей ленте появляющимся как новый.

Переписывайте GUID когда вы постоянно переходите на новый домен и начинаете с нуля. Пропускайте их с --skip-columns=guid когда вы только переходите с HTTP на HTTPS на том же домене.

Смена домена: используйте карточку Change Site URL вместо этого

Если вся суть в том чтобы переместить сайт на новый домен не начинайте с поиска и замены. Карточка Change Site URL на том же разделе Quick Actions обновляет опции siteurl и home и запускает замену по всем таблицам в одной операции в правильном порядке. Если сделать это другим способом может оставить WordPress неспособным загрузить собственный админ.

После замены

Пройдите по этому списку перед тем как считать это завершённым.

Очистите кэш. На раздел Quick Actions запустите Flush Cache. Если сайт использует полностраничный кэш очистите его из WordPress затем Caching.
Очистите правила переписывания. Запустите Flush Rewrites на том же разделе или откройте Settings затем Permalinks в wp-admin и нажмите Save Changes без изменений чего-либо.
Очистите CDN если сайт на нём из Performance затем Kapsule CDN. Смотрите Purging the CDN Cache.
Загрузите сайт в приватном окне чтобы кэш браузера не мог вас ввести в заблуждение.
Проверьте замок. Отсутствующий или предупреждающий замок после переноса SSL означает что URL были оставлены позади: Fixing Mixed Content Warnings.
Кликните по сложным страницам. Слайдеры домашней страницы логотип заголовка любая страница построенная с конструктором страниц и оформление покупки на магазине. Эти содержат URL которые живут в сериализованных параметрах.
Очистите любой плагин кэширования из его собственного экрана параметров.

Решение проблем

Тестовый запуск сообщает нулевых замен. Строка не в базе данных в той точной форме. Проверьте на завершающий слеш префикс www. или схему. Попробуйте искать сначала просто голое имя хоста чтобы подтвердить что оно там вообще есть.

Изображения сломаны после смены домена. URL медиа живут в wp_posts и wp_postmeta и подбираются --all-tables но CDN или плагин оптимизации изображений может кэшировать свои собственные переписанные копии. Очистите CDN и кэш плагина затем перезагрузите.

Параметры исчезли после замены. Это проблема сериализации и это означает что изменение было сделано с помощью сырого SQL вместо инструментов здесь. Восстановите резервную копию созданную перед запуском: Restoring From a Backup.

URL staging продолжают возвращаться. Что-то их переполняет обычно запланированный push или кэшированный параметр. Проверьте рабочий процесс в Using Staging: Pushing and Pulling и убедитесь что Rewrite URLs отмечен когда вы push.

Запуск поиска и замены в базе данных WordPress