SQL для поиска и замены

Смените URL сайта, не повредив сериализованные данные

Работает в вашем браузере. Ничего не загружается.

Изменение

Старый URL Новый URL Префикс таблицПроверьте wp-config.php. Это не всегда wp_ — а на мультисайте точно нет.

Прочитайте это, прежде чем что-либо запускать

WordPress хранит многие параметры в виде строк PHP-serialized, и такая строка записывает собственную длину в байтах — s:19:"http://old-site.com". Обычная замена через SQL меняет текст, но не длину, поэтому PHP больше не может десериализовать эту строку. Ошибки при этом не возникает. Значение просто молча становится пустым.

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

Именно поэтому запросы ниже намеренно не затрагивают wp_options.

Что вы переносите?

Содержимое записей и отрывкиpost_content и post_excerpt — обычный текст. Безопасно. Также переписать столбец GUIDНЕ отмечайте это без чёткого понимания зачем. GUID — постоянный уникальный идентификатор, а не URL: его изменение заставит все читалки лент считать каждую старую запись новой. Мета-поля записей (могут быть сериализованы — рискованно)В postmeta часто хранятся сериализованные данные. При включении запрос показывается с заметным предупреждением.

search-replace.sql

Сначала сделайте резервную копию базы данных. Не «подумайте об этом» — сделайте. У UPDATE нет отмены.

Об инструменте «SQL для поиска и замены»

Наивный поиск и замена через SQL в базе данных WordPress ломает каждую сериализованную опцию, которой касается, потому что сохранённая длина строки перестаёт совпадать. Инструмент генерирует безопасные запросы и объясняет, какие именно небезопасны.

Похожие

Другие инструменты, которые могут пригодиться

Генератор wp-config.php

Соберите правильный wp-config.php, не копируя код из блога 2014 года

Частые вопросы

Вопросы

Можно ли сменить URL сайта WordPress через SQL-поиск и замену?

Безопасно — нет, и это самый растиражированный плохой совет в WordPress. Многие опции хранятся как PHP-сериализованные строки, которые записывают собственную длину в байтах. Обычная SQL-замена меняет текст, но не длину, поэтому PHP молча не может разобрать строку, и значение просто исчезает — вместе с настройками виджетов, правками темы и конфигом плагинов.

Что использовать вместо этого?

WP-CLI: сначала «wp search-replace old new --all-tables --dry-run», затем без --dry-run. Он понимает сериализацию и корректно переписывает префиксы длины. Если доступа к CLI нет, плагин Better Search Replace делает то же самое из админки.

Стоит ли обновлять столбец GUID?

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