Пошук і заміна в 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 прямо каже не змінювати його.