Заміна домену в базі WordPress після переносу сайту
Генератор скриптів для зміни адреси сайту у базі даних: WP-CLI або чистий SQL для phpMyAdmin. Вкажіть префікс таблиць, старий і новий домен — решту інструмент зробить сам. Усе формується у вашому браузері: введені адреси нікуди не надсилаються.
wp-config.php: $table_prefix. Типово wp_
Заповніть старий і новий домен, щоб побачити скрипт.
Скрипт формується у вашому браузері — введені домени нікуди не надсилаються і ніде не зберігаються.
Чому «просто REPLACE по всій базі» ламає сайт
WordPress зберігає частину налаштувань у PHP-серіалізованому вигляді, де довжина кожного рядка записана окремим числом: a:1:{s:4:"logo";s:26:"http://old.com/logo.png";} Число 26 — це довжина адреси у байтах. Звичайний REPLACE змінить саму адресу, але не чіпне число. Після цього unserialize() повертає false, і значення читається як порожнє. Найчастіше так втрачаються віджети, налаштування теми (theme_mods), поля ACF та дані Elementor — тобто саме те, що складніше за все відновити. Тому режим «WP-CLI» стоїть за замовчуванням: wp search-replace розпаковує серіалізовані структури і перераховує довжини коректно.
Одна адреса — п’ять різних записів у базі
Друга причина, чому після переносу «половина посилань лишилась старими»: той самий домен лежить у базі в кількох формах одночасно. http://old.com — звичайний вигляд https://old.com — інша схема, якщо сайт переїхав на SSL уже після наповнення //old.com — protocol-relative у старих темах http:\/\/old.com — екрановані слеші всередині JSON: так адреси зберігають блоки Gutenberg і поле _elementor_data http%3A%2F%2Fold.com — urlencoded у redirect-плагінах та кеші oEmbed Інструмент генерує заміну для кожної увімкненої форми окремо, у правильному порядку: protocol-relative йде останнім, бо є підрядком повної адреси.