Verkkotunnuksen vaihto WordPress-tietokannassa sivuston siirron jälkeen
Skriptigeneraattori sivuston osoitteen vaihtamiseen tietokannassa: WP-CLI tai puhdas SQL phpMyAdminia varten. Anna taulujen etuliite sekä vanha ja uusi verkkotunnus — loput hoitaa työkalu. Kaikki muodostetaan selaimessasi: syötettyjä osoitteita ei lähetetä minnekään.
wp-config.php: $table_prefix. Oletus wp_
Täytä vanha ja uusi verkkotunnus nähdäksesi skriptin.
Skripti muodostetaan selaimessasi — syötettyjä verkkotunnuksia ei lähetetä minnekään eikä tallenneta.
Чому «просто 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 йде останнім, бо є підрядком повної адреси.