Siirsit sivuston uudelle verkkotunnukselle, ja se on alhaalla. Tai se avautuu, mutta ilman tyylejä. Tai hallintapaneeli ei päästä sinua sisään. Jokainen, joka on manuaalisesti siirtänyt WordPressiä, on kokenut tämän hetken: tietokanta muistaa yhä vanhan URL-osoitteen, ja sivusto yrittää epätoivoisesti ladata resursseja osoitteesta, jota ei enää ole.

Neljä SQL-kyselyä phpMyAdminissa ratkaisee ongelman viidessä minuutissa. Ei lisäosia, ei WP-CLI:tä, ei paniikkia. Alla on vaiheittainen opas nykyisen verkkotunnuksen löytämisestä lopputarkistukseen. Mukana säädöt epästandardille taulun etuliitteelle, HTTPS:lle ja serialisoidulle datalle.

💡 Nopea yleiskatsaus:

• Etsi nykyinen verkkotunnus wp_options-taulusta: siteurl- ja home-kentät
• Suorita neljä UPDATE-kyselyä phpMyAdminin SQL-välilehdellä
• Nollaa järjestelmänvalvojan salasana wp_users-taulun kautta, jos hallintapaneeli ei päästä sisään
• Tallenna permalinkit WordPressin asetuksissa tyylien palauttamiseksi
• Verkkokaupoissa ja multisite-asennuksissa käytä Better Search Replacea tai WP-CLI:tä: tavallinen REPLACE rikkoo serialisoidut taulukot

Mistä aloittaa: etsi nykyinen verkkotunnus tietokannasta

Ennen korvaamista varmista, että tiedät, mikä verkkotunnus sivustolle on tällä hetkellä asetettu. Tämä säästää aikaa, jos sivusto on siirretty aiemmin ja tietokantaan on saattanut jäädä kolmas, "väliaikainen" URL-osoite.

Avaa phpMyAdmin, valitse sivuston tietokanta ja etsi wp_options-taulu. Se sisältää kaksi riviä: siteurl (WordPress-osoite) ja home (sivuston osoite). Nämä ovat arvot, jotka muutamme ensin.

Jos taulun etuliite on epästandardi (esimerkiksi mysite_ eikä wp_), etsi mysite_options-taulu. Löydät etuliitteen wp-config.php-tiedostosta: $table_prefix-muuttuja.

Neljä SQL-kyselyä täydelliseen verkkotunnuksen vaihtoon

Suorita jokainen kysely yksi kerrallaan phpMyAdminin "SQL"-välilehdellä. Ennen niiden suorittamista varmista, että varmuuskopioit tietokannan: vienti phpMyAdminin kautta vie minuutin ja pelastaa peruuttamattomilta virheiltä.

Korvaa http://www.oldurl arvolla http://www.newurl kaikissa alla olevissa kyselyissä. Jos sivusto käyttää HTTPS:ää, käytä https:// molemmissa osoitteissa.

1. HOME- ja SITEURL-arvojen päivitys

Tämä muuttaa kaksi keskeistä osoitetta wp_options-taulussa. Ilman tätä vaihetta sivusto ei yksinkertaisesti avaudu uudessa verkkotunnuksessa; WordPress yrittää jatkuvasti ohjata vanhaan.

1
UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

2. Julkaisujen GUID-tunnisteiden päivitys

wp_posts-taulun guid-kenttä tallentaa jokaisen julkaisun pysyvän tunnisteen. Sen korvaaminen ei ole kriittistä sivuston toiminnalle; WordPress ei käytä GUIDia reititykseen. Mutta jos ihmiset lukevat sivustoasi RSS-lukijoiden kautta, GUIDien siisteys on tärkeää: syötteen vanhat URL-osoitteet johtavat rikkinäisiin linkkeihin.

1
UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl', 'http://www.newurl');

3. Julkaisujen sisällön päivitys

Laajin kysely. post_content sisältää kaikkien sivujen ja julkaisujen tekstin, mukaan lukien upotetut kuvat ja sisäiset linkit. Tämän suorittamisen jälkeen kaikki sisällön kuvat latautuvat uudesta verkkotunnuksesta.

1
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');

4. Meta-kenttien päivitys

Mukautetut kentät, lisäosien asetukset, teeman data: kaikki tämä on tallennettu wp_postmeta-tauluun. Ohita tämä kysely, ja saat rikkinäisiä linkkejä näennäisesti odottamattomissa paikoissa: alatunnisteen logo, mukauttimen taustakuva, SEO-lisäosan URL-osoite.

1
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'http://www.oldurl', 'http://www.newurl');

Kun olet suorittanut kaikki neljä kyselyä, avaa sivusto uudessa verkkotunnuksessa. Jos kaikki tehtiin oikein, ongelmia ei pitäisi olla. Mutta joskus tapahtuu jotain muuta: "Virhe tietokantayhteyden muodostamisessa" -viesti tai sivu avautuu ilman tyylejä.

Ensimmäinen asia, jonka tarvitset tässä tilanteessa, on pääsy hallintapaneeliin.

Kuinka päästä hallintapaneeliin, jos salasana on kadonnut tai sivusto ei päästä sisään

Asiakas ei jättänyt salasanaa. Tai lukitsit itsesi ulos vaihtamalla verkkotunnusta, ja /wp-admin heittää sinut loputtomaan uudelleenohjaukseen. Tässä on kaksi tapaa saada järjestelmänvalvojan oikeudet suoraan tietokannan kautta.

Järjestelmänvalvojan salasanan nollaus phpMyAdminin kautta

Avaa wp_users-taulu (etuliitteesi voi olla eri: mysite_users jne.). Etsi käyttäjä, jolla on järjestelmänvalvojan oikeudet, ja napsauta "Muokkaa":

Valitse user_pass-rivillä pudotusvalikosta MD5-funktio ja kirjoita uusi salasana viereiseen kenttään. Napsauta "Siirry":

Huomautus: nykyaikainen WordPress käyttää phpass-järjestelmää (bcrypt-tiivisteitä), ei MD5:tä. Mutta kun syötät WordPress-salasanan, se tarkistaa tiivisteen järjestyksessä: jos bcrypt-tarkistus epäonnistuu, se kokeilee MD5-varajärjestelmää ja tiivistää salasanan välittömästi uudelleen nykyiseen muotoon. Siksi MD5 phpMyAdminin kautta toimii väliaikaisena avaimena.

Ylläpitäjän luominen PHP:n avulla

Vaihtoehtoinen tapa on lisätä uusi ylläpitäjäkäyttäjä ohjelmallisesti. Koodi lisätään aktiivisen teeman functions.php-tiedostoon tai MU-lisäosan kautta.

Lisää seuraava lapsiteemasi functions.php-tiedostoon:

1
function sdstudio_add_admin_user() {
2
    $userdata = array(
3
        'user_login' => 'tempadmin',
4
        'user_pass'  => 'TempPass123!',
5
        'user_email' => '[email protected]',
6
        'role'       => 'administrator',
7
    );
8
    wp_insert_user( $userdata );
9
}
10
add_action( 'init', 'sdstudio_add_admin_user' );

wp_insert_user()-funktio luo käyttäjän annetuilla parametreilla, ja init-koukku suoritetaan jokaisella WordPress-pyynnöllä. Avaa vain mikä tahansa sivuston sivu kerran, niin käyttäjä luodaan.

Kun olet kirjautunut hallintapaneeliin, muista poistaa sekä funktio functions.php-tiedostosta että luomasi väliaikainen käyttäjä. tempadmin-käyttäjän jättäminen selkokielisellä salasanalla on tietoturva-aukko.

Rikkinäisten kuvien ja tyylien korjaaminen domainin vaihdon jälkeen

Sinulla on pääsy hallintapaneeliin, mutta kuvat eivät lataudu ja ulkoasu on rikki. Yhdeksässä tapauksessa kymmenestä yksi yksinkertainen toimenpide auttaa.

Mene kohtaan "Asetukset" → "Osoiterakenne":

Älä muuta mitään; napsauta vain "Tallenna muutokset":

WordPress rakentaa URL-rakenteen uudelleen, päivittää uudelleenkirjoitussääntöjen välimuistin ja tyhjentää sisäisen uudelleenohjausvälimuistin. Tämän jälkeen kuvat yleensä palaavat paikoilleen.

Jos tämä ei auttanut, se tarkoittaa, että vanha domain on upotettu sarjallistettuihin taulukoihin. Tavallinen REPLACE-komento SQL:ssä rikkoo ne: merkkijonon pituus sarjallistetussa taulukossa on kovakoodattu numerona, ja "vanha-pitka-domain.ru"-osoitteen korvaaminen "uusi-lyhyt.io"-osoitteella muuttaa tätä pituutta, tehden taulukosta lukukelvottoman. Asenna ilmainen Better Search Replace -lisäosa; se käsittelee sarjallistuksen oikein ja näyttää, kuinka monta osumaa kustakin taulusta löytyi ennen korvaamista.

Sivustoille, joissa on WP-CLI, se on vielä yksinkertaisempaa yhdellä komennolla:

1
wp search-replace 'http://olddomain.ru' 'https://newdomain.io' --all-tables --dry-run

--dry-run-lippu näyttää ensin, mitä korvattaisiin tekemättä muutoksia. Kun olet varma, aja komento ilman lippua. WP-CLI:n search-replace käsittelee myös sarjallistetun datan ja tekee sen nopeammin kuin verkkokäyttöliittymä.

Alla oleva video näyttää koko prosessin phpMyAdminiin kirjautumisesta sivuston tarkistamiseen korvaamisen jälkeen:

⁉️🤔 Usein kysytyt kysymykset

Onko phpMyAdminin käyttö pakollista domainin vaihtoon?

Ei. Jos sivustoa ei ole vielä siirretty, Duplicator tai All-in-One WP Migration tekevät korvauksen automaattisesti käyttöönoton yhteydessä. Jos sivusto on jo uudella palvelimella ilman ylläpitäjän oikeuksia, jäljelle jäävät SQL-kyselyt phpMyAdminin, Adminerin tai WP-CLI:n kautta. Useimmille verkkovastaaville phpMyAdmin on suorin ja hallituin tapa: näet jokaisen operaation sen sijaan, että luottaisit liitännäisen mustaan laatikkoon.

Mitä teen, jos taulun etuliite ei ole wp_?

Tarkista $table_prefix-vakion arvo tiedostosta wp-config.php. Se on yleensä wp_, mutta palveluntarjoajat tai tietoturvaliitännäiset, kuten Solid Security (entinen iThemes Security), muuttavat sen joskus satunnaiseksi. Kaikissa yllä olevissa kyselyissä korvaa wp_ omalla etuliitteelläsi (esimerkiksi xyz123_options eikä wp_options).

Miksi sivusto avautuu ilman tyylejä korvauksen jälkeen?

Vanha domain on jäänyt teeman asetuksiin, välimuistiin tai CDN:ään. Nollaa permalinkit (ohjeet yllä) ja tyhjennä välimuistiliitännäisesi välimuisti. Jos käytät Cloudflarea tai muuta CDN:ää, mitätöi välimuisti palveluntarjoajan puolella. Jos tämä ei auttanut, aja Better Search Replace: vanha URL on todennäköisesti upotettuna serialisoituun theme_mods_*-taulukkoon.

Sivusto on HTTPS:ssä, mutta siirron jälkeen sertifikaatti ei toimi. Mitä teen?

Varmista, että käytit https:// (et http://) kaikissa kyselyissä. Tarkista, että molemmat osoitteet WordPressin asetuksissa ylläpitopaneeliin kirjautumisen jälkeen alkavat https://. SSL-sertifikaatti itsessään määritetään palvelinpuolella, hallintapaneelin tai ilmaisen Let's Encryptin kautta. Tämä on erillinen toimenpide, joka ei liity tietokantaan.

Voinko korvata domainin ilman phpMyAdmin-yhteyttä?

Kyllä. WP-CLI: wp search-replace 'http://olddomain' 'http://newdomain' --all-tables. Pelkkä FTP: lisää rivit define('WP_HOME','http://newdomain'); ja define('WP_SITEURL','http://newdomain'); tiedostoon wp-config.php. Tämä ohittaa osoitteet väliaikaisesti ja antaa sinulle ylläpitäjän oikeudet. Kirjautumisen jälkeen poista rivit ja tallenna asetukset käyttöliittymän kautta.

Tarvitseeko GUID-kenttää muuttaa wp_posts-taulussa, vai voinko ohittaa sen?

Sitä ei tarvita sivuston toimintaan. WordPress ei käytä GUID:tä reititykseen, vaan ainoastaan artikkelien tunnistamiseen RSS-syötteissä. Jos ihmiset lukevat sivustoasi aktiivisesti RSS:n kautta, korvaus on järkevä. Jos ei, voit ohittaa neljästä kyselystä kolmannen ilman seurauksia.

Domainin SQL-korvauksen jälkeen osa liitännäisten asetuksista katosi. Miksi?

Liitännäiset, kuten WooCommerce, Advanced Custom Fields ja sliderit, tallentavat URL-osoitteita serialisoituihin taulukoihin wp_postmeta-taulussa. Tavallinen REPLACE ei huomioi merkkijonon pituuslaskuria serialisoinnissa ja rikkoo rakenteen. Ratkaisu on Better Search Replace tai wp search-replace (ne purkavat serialisoinnin, korvaavat merkkijonon ja serialisoivat sen uudelleen). Jos olet jo rikkonut sen, palauta tietokanta varmuuskopiosta ja toista korvaus oikealla työkalulla.

Mitä tehdä monimutkaisissa tapauksissa: verkkokaupat, multisite-verkostot ja suuret tietokannat

Domainin vaihto SQL:n kautta on viiden minuutin toimenpide, jos sinulla on suora yhteys phpMyAdminiin ja vakio taulun etuliite. On kuitenkin tilanteita, joissa manuaalinen korvaus REPLACE-komennolla on aidosti riskialtista.

Verkkokaupat WooCommercella, joissa on satoja tuhansia tilauksia. Multisite-verkostot, joissa on kymmeniä erillisiä tauluja jokaiselle alisivustolle. Sivustot, joissa URL-osoitteet on kovakoodattu serialisoituihin taulukoihin (teeman asetukset, sivunrakentajat, sliderit). Tällaisissa tapauksissa yksi SQL REPLACE voi vahingoittaa tietorakennetta, ja tietokannan palauttaminen varmuuskopiosta vie enemmän aikaa kuin tarkka korvaus kerralla.

Better Search Replace tai WP-CLI search-replace osaavat käsitellä serialisoinnin; käytä niitä. Ja jos tietokannan koko ylittää gigatavun ja virheen hinta on korkea, tunti dev-asiantuntijan työtä maksaa vähemmän kuin sellaisen verkkokaupan palauttaminen, jonka seisokki maksaa rahaa.

Käsittelimme sivuston siirron aihetta SEO:n säilyttäen ja liikennettä menettämättä erillisessä oppaassa. Ja jos kohtaat tietyn virheen korvauksen jälkeen, kirjoita kommentteihin, niin autamme diagnostiikassa.