Tuttav olukord: seadistate arendussaiti, ehitate teema välja, ühendate sisu WP Migrate DB Pro abil ja pärast üleslaadimist avastate katkised stiilid, puuduvad pildid ja mittetöötava wp-admini. Põhjus on peaaegu alati sama: toodang asub juurkataloogis, samas kui arendus on alamkataloogis (või vastupidi), ning lihtne URL-ide otsi-ja-asenda andmebaasis seda erinevust ei paranda.

Probleem on sügavam, kui paistab: juurpaigalduses kasutab WordPress kõigi linkide jaoks sama domeeni (nii lehtedele kui ka meediafailidele). Alamkataloogi paigalduses tulevad sisulingid saidi aadressilt, samas kui ressursilingid (css, js, pildid) tulevad WordPressi aadressilt. Tavaline otsi-ja-asenda üle andmebaasi asendab kõik ühetaoliselt ja lõhub pooled teed ära.

Sellest juhendist leiate kaks tõestatud migratsiooniteed (sinna ja tagasi) koos konkreetsete otsi-ja-asenda seadete, wp-config.php ettevalmistuse ja õige failiedastuse järjekorraga. Pärast lugemist kas viite arenduse ja toodangu ühtsele skeemile või teostate teadlikult migratsiooni eri paigaldustüüpide vahel ilma katkise esiküljeta.

💡 Kiire ülevaade:

• Tehke kindlaks oma paigalduse tüüp: kas „WordPressi aadress" ja „Saidi aadress" ühtivad jaotises Seaded → Üldine
• Alamkataloogist juurkataloogi migreerimiseks: kõvakodeerige WP_SITEURL failis wp-config, tehke andmebaasis /subdir → / asendus, liigutage failid ühe taseme võrra üles, uuendage juurkataloogi index.php
• Juurkataloogist alamkataloogi migreerimiseks: asendage andmebaasis ainult teed /wp-content-le, uuendage WordPressi aadressi seadetes, looge alamkataloog, kopeerige index.php ja .htaccess tagasi juurkataloogi
• Pärast igat migratsiooni minge Seaded → Püsilingid ja klõpsake „Salvesta": see taastab URL-ide struktuuri ja tühjendab vahemälu

Kuidas teha kindlaks, kuhu WordPress on paigaldatud

Kui paigaldasite WordPressi käsitsi, siis ilmselt mäletate, kas see oli domeeni juurkataloogis või alamkataloogis nagu /wp või /blog. Aga kui sait on päritud eelmiselt arendajalt, paigaldatud hostinguteenuse pakkuja poolt ühe klõpsuga või on mitu aastat möödas, siis üksikasjad tuhmuvad.

Kiireim viis: minge WordPressi administraatorisse, avage Seaded → Üldine ja vaadake välju „WordPressi aadress (URL)" ja „Saidi aadress (URL)". Kui väärtused ühtivad, on teil juurpaigaldus:

Kui väljad erinevad, on WordPress paigaldatud alamkataloogi (allolevas näites on selleks /subdir):

Täiendav märk alamkataloogi paigaldusest: administraatorisse sisse logides sisaldab URL alamkataloogi, näiteks example.com/wp/wp-admin/ example.com/wp-admin/ asemel.

Miks ei saa lihtsalt otse üle kanda

Probleemi juur peitub kaheses URL-süsteemis, mida WordPress alamkataloogi paigalduste puhul kasutab. Vaatame seda konkreetsete näidete varal.

Oletame, et teil on juurpaigaldus aadressil example.com. Absoluutselt kõik lingid andmebaasis, nii postitusele /2025/about-page kui ka pildile /wp-content/uploads/photo.jpg, algavad sõnaga //example.com. Tavaline otsi-ja-asenda //example.local → //example.com töötab suurepäraselt.

Võtame nüüd paigalduse alamkataloogis /wp. Link samale postitusele näeb välja nagu //example.com/about-page (saidi aadressi kaudu), samas kui link samale pildile on //example.com/wp/wp-content/uploads/photo.jpg (WordPressi aadressi kaudu koos alamkataloogiga). Lihtne asendus //example.local → //example.com lõhub meediafailid: süsteem otsib neid ilma /wp-ta teekonnas ja saab 404 vea.

Allolev tabel näitab, milliseid URL-gruppe tuleb igas migratsioonisuunas uuendada:

Lisaks andmebaasile pead füüsiliselt faile teisaldama ja uuendama juurkataloogis olevat index.php faili, vastasel juhul ei leia WordPress wp-blog-header.php üles. Järgmisena käime mõlemad variandid samm-sammult läbi.

Meetod 1: WordPressi teisaldamine alamkataloogist juurkataloogi

See on lihtsam suund: eemaldad URL-idest alamkataloogi ja kõik aadressid muutuvad „lamedaks", nagu tavalises paigalduses.

Samm 0: probleemi ulatuse tuvastamine

Enne sekkumist on kasulik oma silmaga näha, kui suur see probleem on. Allolev ekraanipilt näitab migreerimisseadeid saidilt wp-in-a-subdirectory.local (WordPress kataloogis /subdir) saidile wp-standard-install.local (juurpaigaldus). WP Migrate DB Pro seaded on standardsed, lisaks on demonstratsiooniks saidi pealkirja asendamine:

Tulemus on ootuspäraselt nukker: lehed avanevad, kuid stiilideta ja katkiste piltidega:

HTML-is näed ressursilinke, mis sisaldavad surnud /subdir teed, mida sihtserveris enam ei eksisteeri. Katse pääseda wp-adminisse põhjustab ümbersuunamise aadressile wp-standard-install.local/subdir/wp-login.php, kuid sellist faili pole olemas. Nüüd parandame selle ära.

Samm 1: ettevalmistus

Esiteks kaitse migreerimise ajal administraatoriliidest. Lisa faili wp-config.php konstandid, mis kirjutavad üle andmebaasist tulevad seaded, nii et WordPress lubab sul jätkuvalt vana teed pidi koos alamkataloogiga administraatoriliidesesse siseneda ka pärast andmebaasi puhastamist:

1
define( 'WP_SITEURL', 'http://wp-in-a-subdirectory.local/subdir' );
2
define( 'WP_HOME', 'http://wp-in-a-subdirectory.local' );

Seejärel pane sait hooldusrežiimi: muuda avalikus juurkataloogis faili index.php, kommenteeri välja rida require( dirname( __FILE__ )... ja pärast sulgevat ?> silti lisa lühikese katkestusteatega html-i kohatäide. Külastajad näevad seda:

Samal ajal pääsed sa jätkuvalt administraatoriliidesesse aadressil http://wp-in-a-subdirectory.local/subdir/wp-admin/, sest WP_SITEURL konstant töötab.

Samm 2: otsi ja asenda andmebaasis

Nüüd puhasta andmebaas. Käivita otsi-ja-asenda nende paaridega (näidatud WP Migrate DB Pro liideses, kuid sama põhimõte töötab WP-CLI search-replace või SQL-päringutega phpMyAdmini kaudu):

• //wp-in-a-subdirectory.local/subdir → //wp-in-a-subdirectory.local
• /app/public/subdir → /app/public (failitee asukoht serveris)

Vahetult pärast migreerimist välimus ei muutu (hooldusleht on endiselt üleval, administraatoriliides töötab läbi sissekodeeritud konstandi). Kuid kui vaatate postituste sisu, siis pildid veel ei lae ja sisemised lingid on alamkataloogi „kaotanud", mis on täpselt see, mida me selles etapis tahtsime:

3. Samm: failide füüsiline teisaldamine

Eemaldage (või kommenteerige välja) read WP_SITEURL ja WP_HOME failist wp-config.php. Administraatoriliides nüüd katkeb, seega liigutage failid kohe alamkataloogist ühe taseme võrra ülespoole.

SSH või käsurea kaudu serveris tehakse see kolme käsuga:

1
rm index.php && mv subdir/* . && rm -rf subdir

FTP või majutuse failihalduri kaudu lohistage kõik alamkataloogi sisu avalikku juurkataloogi, asendades index.php:

Valmis. Sait avaneb juur-URL-il; pildid ja stiilid on paigas:

Viimane lihv: minge administraatoriliidesesse (nüüd aadressil http://wp-in-a-subdirectory.local/wp-admin ilma alamkataloogita), avage Seaded → Püsilingid ja klõpsake „Salvesta muudatused", isegi kui te midagi ei muutnud. WordPress ehitab URL-ide struktuuri uuesti üles ja tühjendab vahemälu.

Meetod 2: WordPressi viimine juurkataloogist alamkataloogi

Paljud arendajad peavad WordPressi paigaldamist alamkataloogi heaks tavaks: põhifailid ei risusta juurkataloogi, haldamine Git/Composeriga on lihtsam ning domeeni ennast saab kasutada muude rakenduste jaoks. Kuid olemasoleva saidi migreerimine alamkataloogi on objektiivselt keerulisem kui vastupidine protsess, sest nüüd PEAVAD mõned lingid alamkataloogi säilitama, samas kui teised ei tohi seda teha.

Samm 0: diagnostika

Sama lähtepunkt: proovime standardset migratsiooni juurpaigaldusest wp-standard-install.local alamkataloogi paigaldusse wp-in-a-subdirectory.local (WordPress kataloogis /subdir):

Tulemus on täiesti ootuspärane: lehed avanevad, kuid stiilid ja pildid katkevad, sest nende teekondadele ei lisatud /subdir:

Erinevalt esimesest stsenaariumist töötavad lingid postitustele ja lehtedele õigesti (need ei tohiks alamkataloogi sisaldada). Katki lähevad just ressursid (css, js, meedia), mille teekonnad peavad nüüd sisaldama /subdir.

Samm 1: ettevalmistus

Selles etapis me EI määra konstante WP_SITEURL ja WP_HOME, sest meie otsi-ja-asenda operatsioon neid väärtusi ei puuduta ning me uuendame WordPressi aadressi käsitsi veidi hiljem.

Seadistage hooldusleht samamoodi: kommenteerige välja require(...) failis index.php ja lisage html-i kohatäide. Külastajad näevad hooldusteadet, samal ajal kui teie pääsete administraatorisse jätkuvalt aadressil http://wp-standard-install.local/wp-admin/.

Samm 2: valikuline otsi-ja-asenda andmebaasis

Peamine erinevus esimesest meetodist: me asendame AINULT failide ja ressursside teekonnad, PUUDUTAMATA lehtede URL-e. Selleks suunake asendus mustrit /wp-content kasutades:

• //wp-standard-install.local/wp-content → //wp-standard-install.local/subdir/wp-content
• /app/public → /app/public/subdir (tee serveris)

Pärast migratsiooni kontrollige postituste sisu: lingid teistele saidi lehtedele EI sisalda alamkataloogi (õige), samas kui manustatud pildid sisaldavad seda (samuti õige):

Samm 3: WordPressi aadressi uuendamine ja failide teisaldamine

Nüüd minge Seaded → Üldine ja lisage alamkataloog välja „WordPressi aadress (URL)" lõppu, näiteks http://wp-standard-install.local/subdir. Kohe pärast salvestamist läheb administraator katki, sest WordPress proovib leida faile uuelt teekonnalt, kuid neid seal veel ei ole:

Looge avalikus juurkataloogis alamkataloog subdir ja teisaldage KÕIK WordPressi failid sinna. Seejärel kopeerige index.php ja .htaccess TAGASI juurkataloogi, et hooldusleht jätkaks kuvamist, kuni me lõpetame:

Taastage alamkataloogis asuv index.php selle tehaseseisundisse: eemaldage html-i kohatäide ja eemaldage kommentaar require realt:

1
<?php
2
define( 'WP_USE_THEMES', true );
3
require( dirname( __FILE__ ) . '/wp-blog-header.php' );

Nüüd on administraator taas ligipääsetav aadressil http://wp-standard-install.local/subdir/wp-admin/:

Kontrolli sisu: pildid on paigas, stiilid laadivad:

Viimane lihv: juurikataloogi index.php

Jääb üle vaid uuendada index.php avalikus juurikataloogis. Eemalda hooldusleht ja määra õige tee failini wp-blog-header.php, arvestades alamkataloogi:

1
<?php
2
define( 'WP_USE_THEMES', true );
3
require( dirname( __FILE__ ) . '/subdir/wp-blog-header.php' );

Sait avaneb juur-URL-il, kusjuures kõik ressursid laaditakse alamkataloogist:

Mine uuesti Seaded → Püsilingid ja salvesta ilma muudatusteta, et WordPress värskendaks URL-ide struktuuri.

Alternatiivsed tööriistad ja ametlik meetod

Eespool kirjeldatud lähenemine WP Migrate DB Pro-ga on mugav, kuid mitte ainus võimalus. Siin on teised tööriistad, millega saad töötada:

• WP-CLI search-replace. Käsk wp search-replace '//oldsite.local/subdir' '//newsite.com' lipuga --dry-run näitab esmalt, mitu vastet asendatakse. Valikuliseks asendamiseks (juur → alamkataloog) kitsenda mustrit: wp search-replace '//newsite.com/wp-content' '//newsite.com/subdir/wp-content'.

• Ametlik WordPressi meetod. Dokumentatsioon aadressil developer.wordpress.org kirjeldab protseduuri „WordPressile oma kataloogi andmine" koos üksikasjalike seadistustega Apache (.htaccess), nginx (serveriplokk) ja IIS (web.config) jaoks. Meetod ei vaja pluginaid ja töötab igal hostingul.

• Käsitsi SQL. Kui muudatuste maht on väike, saad käivitada UPDATE wp_posts SET post_content = REPLACE(post_content, '/subdir/', '/') otse phpMyAdminis, kuid alati eelneva varukoopiaga, sest selline asendamine rikub serialiseeritud andmed tabelites wp_options ja wp_postmeta.

Ükskõik millise tööriista valid, reegel on sama: kui migreerid JUUR → ALAMKATALOOG, asenda ainult /wp-content ja failiteed; kui migreerid ALAMKATALOOG → JUUR, asenda kõik, mis viitab alamkataloogile.

⁉️🤔 Korduma kippuvad küsimused

Kas WP Migrate DB Pro on seda tüüpi migratsiooniks hädavajalik?

Ei. WP Migrate DB Pro pakub lihtsalt mugavat liidest otsinguks ja asendamiseks, mis mõistab PHP serialiseeritud andmeid. Tehniliselt saad samad asendused teha WP-CLI kaudu (käsk wp search-replace käsitleb samuti serialiseeritud stringe õigesti) või kasutada ametlikku WordPressi meetodit koos käsitsi failide ülekandmise ja index.php muutmisega. Plugin säästab aega suurtel ja keskmistel projektidel, kus on palju vasteid.

Mida teha, kui mõned pildid ei lae ka pärast migratsiooni?

Kõige levinum põhjus: andmebaasi on jäänud vana serveri absoluutsete teedega sissekodeeritud URL-id, mis ei vastanud asendusmustrile. Kontrolli postituste sisu phpMyAdmini kaudu: SELECT ID, post_content FROM wp_posts WHERE post_content LIKE '%/subdir/%' (või vana domeen). Teine kandidaat on brauseri ja CDN-i vahemälu: tühjenda mõlemad ja kontrolli inkognito režiimis.

Kas pärast ülekannet on vaja uuendada.htaccess faili?

Kui kasutad ilusaid püsilinge, siis jah, kuid WordPress teeb seda automaatselt, kui klõpsad lehel Seaded → Püsilingid nuppu „Salvesta". Kui serveril puuduvad kirjutusõigused, kuvab WordPress valmis.htaccess sisu, et saaksid selle käsitsi kopeerida. Alamkataloogi migreerides veendu, et juurikataloogi.htaccess (mitte see, mis on alamkataloogi sees) ei sisaldaks uue struktuuriga vastuolus olevaid reegleid.

Kas migratsiooni on võimalik teostada nullilähedase katkestusajaga?

Tehniliselt jah, kui kasutad meetodit.htaccess ümbersuunamistega (ametliku WordPressi dokumentatsiooni I meetod, „URL-e muutmata"). Selle lähenemise korral teisaldatakse failid alamkataloogi, samal ajal kui juurikataloogi.htaccess suunab kõik päringud sujuvalt uude asukohta. Külastajad ei märka kolimist. Puudus: sa jääd samale domeenile ja saidi URL formaalselt ei muutu (alamkataloog ei ole aadressiribal nähtav).

Miks WP Migrate DB Pro ei toeta eri tüüpi installatsioonide vahelist migratsiooni kohe karbist võttes?

Delicious Brainsi arendajad arutasid seda GitHubis ligi kolm aastat. Probleemi tuum: plugin rakendab ÜHTE otsingu ja asendamise paari KOGU andmebaasile, kuid migratsioon juurikataloogi ja alamkataloogi vahel nõuab ERINEVAID asendusi erinevatele URL-igruppidele (lehed vs ressursid). Automaatne tuvastamine, milline URL millisesse gruppi kuulub, eeldaks sisu struktuuri parsimist, mis väljub lihtsa otsingu ja asendamise raamidest. Seetõttu on praegune soovitus: vii saidid ENNE migratsiooni ühtsele installatsiooniskeemile.

Lõppjäreldus: juurkaust või alamkaust?

Valik juurkausta ja alamkausta WordPressi paigalduse vahel taandub sisuliselt ühele kompromissile. Juurkausta paigaldus on lihtsam: vähem liikuvaid osi, otsene ühilduvus arendus- ja tootmiskeskkonna vahel, üllatusi topelt-URL-idega ei teki. Alamkausta paigaldus on arhitektuuriliselt puhtam: põhifailid on isoleeritud, juurkaustas asub ainult index.php, WordPressi uuendamine Git'i/Composer'i kaudu on lihtsam ning mitme rakenduse majutamine ühel domeenil on turvalisem.

Kui sul on üks tootmissait ja üks arendussait, vii mõlemad ühtsele skeemile (ükskõik kummalegi) ja unusta probleem. Kui töötad meeskonnas, kus mõned projektid on ajalooliselt juurkaustas, teised aga alamkaustades, siis tead nüüd täpseid otsi-ja-asenda mustreid mõlema suuna jaoks.

Peamine reegel, mida tasub järjehoidjasse panna: kui migreerid JUUR → ALAMKAUST, puuduta ainult /wp-content ja failiteekondi; kui migreerid ALAMKAUST → JUUR, asenda kõik, mis sisaldab alamkausta. Ja alati, alati klõpsa pärast kolimist püsilinkide lehel „Salvesta".