Ha a WordPress-webhelye új domainre költözik, vagy egy staging másolatot élesít, a régi cím nemcsak a Beállítások oldalon szerepel: ott van a bejegyzések szövegében, a képek címében, a widgetekben, a sablon és a bővítmények beállításaiban. Ezeket a WP-CLI wp search-replace parancsa egy lépésben átírja, és ami a legfontosabb, a szerializált adatokat sem rontja el.

Ha a webhelyet a WP Toolkit kezeli, egyszerűbb esetben a webhely sorának ⋮ menüjében a Frissített webhely URL-cím pont is elvégzi a címcserét. Ez a cikk a parancssori utat mutatja be, amely mindent megmutat és mindent ellenőrizhetővé tesz. A cPanel tárhelyeken a WP-CLI az SSH-hozzáféréssel rendelkező csomagokban érhető el; az alapokat a WP-CLI használatáról szóló cikk írja le.

Miért nem jó a sima SQL-csere?

A WordPress és a bővítmények sok beállítást szerializált PHP-formátumban tárolnak, amely minden szöveg elé odaírja a hosszát bájtban: s:22:"https://regi-domain.hu". Ha egy SQL REPLACE() vagy egy szövegszerkesztő az SQL-fájlban kicseréli a domaint, a szöveg megváltozik, a hossz nem. A PHP ilyenkor nem tudja visszaolvasni az értéket, a WordPress az alapértelmezést használja, és a widgetek vagy a bővítménybeállítások hibaüzenet nélkül üresek lesznek.

Egy alattomos részlet: ha a régi és az új domain véletlenül ugyanolyan hosszú, a sima csere működni látszik, és a hiba csak a következő költözésnél jön elő. Ékezetes szövegeknél a hossz bájtban számít, egy ékezetes betű 2 bájt, így kézzel sem érdemes javítgatni.

A wp search-replace kibontja a szerializált értéket, a szerkezeten belül cserél, majd visszaírja, és újraszámolja a hosszakat.

1. Mentés

Mentse el az adatbázist, mielőtt bármit módosít. Az aWh cPanel szerverein a wp db export nem használható (a proc_open PHP-függvény le van tiltva), ezért közvetlenül a mysqldump parancsot használja. Az adatbázis jelszavát tartalmazó ~/.my.cnf fájl elkészítését a WP-CLI használatáról szóló cikk mutatja be.

cd ~/public_html
mysqldump --single-transaction --no-tablespaces "$(wp config get DB_NAME)" > ~/domainvaltas-elott.sql
tail -1 ~/domainvaltas-elott.sql

Az utolsó sor legyen -- Dump completed on …. Ha valami elromlik, a visszaállítás:

mysql "$(wp config get DB_NAME)" < ~/domainvaltas-elott.sql

A WP Toolkit Biztonsági mentés/visszaállítás funkciója és a napi JetBackup mentés is megfelelő (a mentés lehetőségei), de egy friss SQL-fájlból percek alatt visszaállhat.

2. Számolja meg, mit fog cserélni

Keressen a csupasz domainre, protokoll nélkül. A blokkszerkesztő és sok bővítmény a címet JSON-ban, https:\/\/regi-domain.hu alakban tárolja; a https://regi-domain.hu keresés ezeket nem találja meg, a regi-domain.hu igen.

wp db search 'regi-domain.hu' --all-tables --stats

A kimenet végén a találatok száma szerepel, például Success: Found 7 matches.

3. Próbafuttatás

wp search-replace 'regi-domain.hu' 'uj-domain.hu' --all-tables --skip-columns=guid --precise --report-changed-only --dry-run

A kapcsolók:

• --dry-run: semmit nem ír, csak megmutatja, melyik tábla melyik oszlopában hány cserét végezne.
• --all-tables: a bővítmények saját tábláit is átnézi (a képen például egy WooCommerce-tábla is szerepel). Ha az adatbázisban több webhely tábláit tárolja, használja helyette az --all-tables-with-prefix kapcsolót, hogy csak a saját előtagú táblákhoz nyúljon.
• --skip-columns=guid: a bejegyzések guid mezője állandó azonosító, nem cím; ha átírja, a hírolvasók minden régi bejegyzést újnak látnak.
• --precise: minden sort PHP-val dolgoz fel; lassabb, de az oldalépítők bonyolult adatainál biztosabb.
• --report-changed-only: csak azokat a táblákat írja ki, ahol tényleg csere lesz.

Vesse össze az eredményt a 2. lépés számával. Ha sokkal több a csere, a keresett szöveg egy másik névnek is része (például a pelda.hu a masikpelda.hu címben is szerepel); ilyenkor a hosszabb, pontosabb formával cseréljen. Ha sokkal kevesebb, valószínűleg rossz webhely mappájában van.

4. A csere

Futtassa ugyanazt a parancsot a --dry-run nélkül, hogy pontosan az fusson le, amit ellenőrzött:

wp search-replace 'regi-domain.hu' 'uj-domain.hu' --all-tables --skip-columns=guid --precise --report-changed-only

Az utolsó sor Success: Made N replacements., ahol N megegyezik a próbafuttatás számával. Többwebhelyes (multisite) telepítésnél adja hozzá a --network kapcsolót, különben csak a fő webhely címe változik.

5. HTTP-ről HTTPS-re külön lépésben

A domain és a protokoll cseréjét ne vonja össze egy keresésbe. Előbb a domaint cserélje, majd az új domainen a protokollt:

wp search-replace 'http://uj-domain.hu' 'https://uj-domain.hu' --all-tables --skip-columns=guid --precise --report-changed-only
wp option update siteurl 'https://uj-domain.hu'
wp option update home 'https://uj-domain.hu'

Ha csak HTTPS-re áll át, domainváltás nélkül, ez a lépés a teljes munka. A kimaradt http:// hivatkozások felderítésében a mixed content cikk segít.

6. Gyorsítótárak ürítése

Amíg egy gyorsítótár a régi tartalmat szolgálja ki, a csere eredménye nem látszik:

wp cache flush
wp transient delete --all
wp rewrite flush

Ezután ürítse a gyorsítótárazó bővítmény (például AccelerateWP, LiteSpeed Cache, WP Rocket) saját tárolóját a bővítmény felületén, és ha CDN-t használ, ott is.

7. Ami nincs az adatbázisban

A search-replace csak az adatbázist írja át. Nézze meg a fájlokat is:

grep -n "WP_HOME\|WP_SITEURL\|DOMAIN_CURRENT_SITE" ~/public_html/wp-config.php
grep -rn "regi-domain\.hu" ~/public_html/.htaccess ~/public_html/wp-content/themes/

Ha a wp-config.php fájlban WP_HOME vagy WP_SITEURL szerepel a régi címmel, az felülírja az adatbázist: a csere hibátlan, mégis a régi cím látszik, és a Beállítások oldalon a mezők szürkék. Javítsa vagy törölje ezeket a sorokat. Ezen kívül ellenőrizze a sablonba égetett címeket, a .htaccess átirányításait, a CDN, az SMTP- és a statisztikai bővítmények beállításait, valamint a külső szolgáltatásoknál (fizetési kapu, API) regisztrált visszahívási címeket.

Az Elementor a tartalmát kétszeresen kódolt JSON-ban tárolja, és a lefordított CSS-fájljaiban is abszolút címek vannak. Használja az Elementor menü Tools (Eszközök) oldalán a Replace URL funkciót, majd generálja újra a CSS-t:

wp elementor flush-css

Más oldalépítők (Divi, Beaver Builder, WPBakery) is saját CSS-gyorsítótárat tartanak; ürítse ezeket, mielőtt arra jutna, hogy a csere nem sikerült.

Ellenőrzés

wp option get siteurl && wp option get home
wp db search 'regi-domain.hu' --all-tables --stats
curl -sI https://uj-domain.hu/ | head -5
curl -s https://uj-domain.hu/ | grep -c 'regi-domain\.hu'

A siteurl és a home az új címet mutassa, a wp db search legfeljebb a guid oszlopban találjon egyezést, a curl -sI válasza 200 legyen, és ne irányítson vissza a régi domainre, az utolsó parancs pedig 0-t írjon ki. Ha nem nulla, a 7. lépésben felsorolt helyek egyikén maradt a régi cím.

Ezután nyissa meg az admin felületen a szerializált beállításokat tároló oldalakat: Megjelenés › Widgetek, a Testreszabó, a WooCommerce szállítási zónái és az oldalépítő sablonjai. Ha valamelyik üres, ahol korábban beállítás volt, állítsa vissza a mentést, és futtassa újra a cserét a --precise kapcsolóval.

Gyakori hibák

Nulla csere, pedig a régi domain mindenhol ott van. Rossz mappában futtatta (nézze meg: wp option get siteurl), vagy a cím másképp van tárolva, mint ahogy keresett. Keressen rövidebb formára: wp db search 'regi-domain' --all-tables --stats.

A csere sikerült, de az oldal a régi címre irányít. A leggyakoribb okok sorrendben: WP_HOME/WP_SITEURL a wp-config.php fájlban, ki nem ürített gyorsítótár, a régi címet kiszolgáló CDN, vagy egy átirányítás a .htaccess fájlban.

A többwebhelyes hálózat aloldalai a régi címen maradtak. Kimaradt a --network kapcsoló, vagy a wp-config.php fájl DOMAIN_CURRENT_SITE állandója még a régi domaint tartalmazza. Javítsa, futtassa újra a --network kapcsolóval, és ellenőrizze: wp site list --field=url.

Élő webáruház. Webáruháznál a csere idejére állítsa le a rendeléseket (például karbantartási móddal), ellenőrizze az eredményt, és csak utána nyissa meg újra a boltot. Ha a domainváltás tárhelyköltözéssel is jár, a WordPress költöztetéséről szóló cikk írja le a teljes folyamatot.