Tuttu tilanne: pystytit kehityssivuston, rakensit teeman, liitit sisällön WP Migrate DB Prolla ja pushauksen jälkeen löysit rikkinäiset tyylit, puuttuvat kuvat ja toimimattoman wp-adminin. Syy on melkein aina sama: tuotanto on juuressa, kun taas dev on alihakemistossa (tai päinvastoin), eikä suoraviivainen URL-osoitteiden haku ja korvaus tietokannassa korjaa tätä eroa.

Ongelma on syvempi kuin miltä näyttää: juuriasennuksessa WordPress käyttää samaa verkkotunnusta kaikkiin linkkeihin (sekä sivuille että mediatiedostoihin). Alihakemistoasennuksessa sisältölinkit tulevat sivusto-osoitteesta, kun taas resurssilinkit (css, js, kuvat) tulevat WordPress-osoitteesta. Tavallinen haku ja korvaus tietokannassa korvaa kaiken yhdenmukaisesti ja rikkoo puolet poluista.

Tästä oppaasta löydät kaksi testattua migraatioreittiä (sinne ja takaisin) tarkkoine haku- ja korvausasetuksineen, wp-config.php-valmisteluineen ja oikeine tiedostonsiirtojärjestyksineen. Lukemisen jälkeen joko yhdenmukaistat devin ja tuotannon asennustavan tai teet tietoisesti migraation eri asennustyyppien välillä ilman rikkinäistä julkisivua.

💡 Pikakatsaus:

• Selvitä asennustyyppisi: täsmäävätkö "WordPress-osoite" ja "Sivusto-osoite" kohdassa Asetukset → Yleinen
• Siirrettäessä alihakemistosta juureen: kovakoodaa WP_SITEURL wp-configiin, tee /subdir → /-korvaus tietokannassa, siirrä tiedostot yhtä tasoa ylemmäs, päivitä juuren index.php
• Siirrettäessä juuresta alihakemistoon: korvaa tietokannassa vain polut kohteeseen /wp-content, päivitä WordPress-osoite asetuksissa, luo alihakemisto, kopioi index.php ja .htaccess takaisin juureen
• Minkä tahansa migraation jälkeen mene kohtaan Asetukset → Osoiterakenne ja klikkaa "Tallenna": tämä rakentaa URL-rakenteen uudelleen ja tyhjentää välimuistin

Miten selvittää, mihin WordPress on asennettu

Jos asensit WordPressin käsin, muistat todennäköisesti, oliko se verkkotunnuksen juuressa vai alihakemistossa kuten /wp tai /blog. Mutta jos sivusto on peritty edelliseltä kehittäjältä, hotellipalvelun yhdellä klikkauksella käyttöön ottama tai siitä on useita vuosia, yksityiskohdat haalistuvat.

Nopein tapa: mene WordPressin hallintaan, avaa Asetukset → Yleinen ja katso "WordPress-osoite (URL)"- ja "Sivusto-osoite (URL)" -kenttiä. Jos arvot täsmäävät, sinulla on juuriasennus:

Jos kentät eroavat toisistaan, WordPress on asennettu alihakemistoon (alla olevassa esimerkissä tämä on /subdir):

Lisämerkki alihakemistoasennuksesta: kun kirjaudut hallintaan, URL sisältää alihakemiston, esimerkiksi example.com/wp/wp-admin/ eikä example.com/wp-admin/.

Miksi et voi vain siirtää suoraan

Ongelman ydin on kaksiosaisessa URL-järjestelmässä, jota WordPress käyttää alihakemistoasennuksissa. Puretaan tämä konkreettisilla esimerkeillä.

Oletetaan, että sinulla on juuriasennus osoitteessa example.com. Aivan kaikki linkit tietokannassa, sekä artikkeliin /2025/about-page että kuvaan /wp-content/uploads/photo.jpg, alkavat //example.com. Tavallinen haku ja korvaus //example.local → //example.com toimii täydellisesti.

Otetaan nyt asennus /wp-alihakemistossa. Linkki samaan artikkeliin näyttää tältä //example.com/about-page (sivusto-osoitteen kautta), kun taas linkki samaan kuvaan on //example.com/wp/wp-content/uploads/photo.jpg (WordPress-osoitteen kautta alihakemistoineen). Yksinkertainen korvaus //example.local → //example.com rikkoo mediatiedostot: järjestelmä etsii niitä ilman /wp-osaa polussa ja saa 404-virheen.

Alla oleva taulukko näyttää, mitkä URL-ryhmät tarvitsevat päivitystä kummassakin migraatiosuunnassa:

Tietokannan lisäksi sinun täytyy fyysisesti siirtää tiedostot ja päivittää juuressa oleva index.php, muuten WordPress ei löydä wp-blog-header.php-tiedostoa. Seuraavaksi käymme molemmat reitit läpi vaihe vaiheelta.

Tapa 1: WordPressin siirtäminen alihakemistosta juureen

Tämä on yksinkertaisempi suunta: poistat alihakemiston poluista, ja kaikista URL-osoitteista tulee "litteitä", kuten vakioasennuksessa.

Vaihe 0: vianmääritys ennakkoon

Ennen kuin teet mitään, on hyvä nähdä ongelman laajuus omin silmin. Alla oleva kuvakaappaus näyttää migraatioasetukset siirrettäessä osoitteesta wp-in-a-subdirectory.local (WordPress hakemistossa /subdir) osoitteeseen wp-standard-install.local (juuriasennus). WP Migrate DB Pron asetukset ovat vakiot, ja lisäksi on korvattu sivuston nimi havainnollistamisen vuoksi:

Lopputulos on arvattavan surkea: sivut avautuvat, mutta ilman tyylejä ja rikkinäisin kuvin:

HTML-koodissa näkyy resurssilinkkejä, joissa on kuollut /subdir-polku, jota ei enää ole kohdepalvelimella. Yrittäessäsi käyttää wp-adminia sinut ohjataan osoitteeseen wp-standard-install.local/subdir/wp-login.php, mutta kyseistä tiedostoa ei ole olemassa. Nyt korjataan tämä.

Vaihe 1: valmistelu

Suojaa ensin ylläpitäjän pääsy migraation ajaksi. Lisää wp-config.php-tiedostoon vakioita, jotka ohittavat tietokannan asetukset, jotta WordPress päästää sinut edelleen ylläpitoon vanhan polun kautta alihakemistoineen, vaikka olisimme jo siivonneet tietokannan:

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

Laita sitten sivusto huoltotilaan: muokkaa julkisessa juuressa olevaa index.php-tiedostoa, kommentoi rivi require( dirname( __FILE__ )... ja lisää sulkevan ?>-tagin jälkeen html-paikkamerkki, jossa on lyhyt katkoviesti. Vierailijat näkevät tämän:

Sillä välin sinä pääset edelleen ylläpitoon osoitteessa http://wp-in-a-subdirectory.local/subdir/wp-admin/, koska WP_SITEURL-vakio toimii.

Vaihe 2: haku ja korvaus tietokannassa

Nyt siivotaan tietokanta. Suorita haku ja korvaus näillä pareilla (esitetty WP Migrate DB Pron käyttöliittymässä, mutta sama periaate toimii WP-CLI:n search-replace-komennolla tai SQL-kyselyillä phpMyAdminin kautta):

• //wp-in-a-subdirectory.local/subdir → //wp-in-a-subdirectory.local
• /app/public/subdir → /app/public (tiedostopolku palvelimella)

Heti siirron jälkeen ulkoasu ei muutu (ylläpitosivu on edelleen päällä, hallintapaneeli toimii kovakoodatun vakion kautta). Mutta jos katsot artikkelien sisältöä, kuvat eivät vielä lataudu ja sisäisistä linkeistä on "hävinnyt" alihakemisto, mikä on juuri se mitä tässä vaiheessa halusimmekin:

Vaihe 3: tiedostojen fyysinen siirto

Poista (tai kommentoi pois) rivit, joilla on WP_SITEURL ja WP_HOME, tiedostosta wp-config.php. Hallintapaneeli hajoaa nyt, joten siirrä tiedostot välittömästi alihakemistosta yhden tason ylöspäin.

SSH:n tai palvelimen komentorivin kautta tämä tehdään kolmella komennolla:

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

FTP:n tai palveluntarjoajan tiedostonhallinnan kautta vedä kaikki alihakemiston sisältö julkiseen juureen ja korvaa index.php:

Valmista. Sivusto avautuu juuri-URL-osoitteessa; kuvat ja tyylit ovat paikoillaan:

Viimeinen silaus: mene hallintapaneeliin (nyt osoitteessa http://wp-in-a-subdirectory.local/wp-admin ilman alihakemistoa), avaa Asetukset → Osoiterakenne ja klikkaa "Tallenna muutokset", vaikka et olisi muuttanut mitään. WordPress rakentaa URL-rakenteen uudelleen ja tyhjentää välimuistin.

Tapa 2: WordPressin siirtäminen juuresta alihakemistoon

Monet kehittäjät pitävät WordPressin asentamista alihakemistoon hyvänä käytäntönä: ydintiedostot eivät täytä juurta, hallinta Gitin/Composerin kautta helpottuu ja itse domainia voi käyttää muihin sovelluksiin. Olemassa olevan sivuston siirtäminen alihakemistoon on kuitenkin objektiivisesti monimutkaisempaa kuin päinvastainen toimenpide, koska nyt joidenkin linkkien TÄYTYY säilyttää alihakemisto, kun taas toisten ei.

Vaihe 0: diagnostiikka

Sama lähtökohta: kokeilemme vakiosiirtoa juuriasennuksesta wp-standard-install.local alihakemistoasennukseen wp-in-a-subdirectory.local (WordPress hakemistossa /subdir):

Tulos on täysin odotettu: sivut avautuvat, mutta tyylit ja kuvat rikkoutuvat, koska /subdir-polkua ei ole lisätty niiden osoitteisiin:

Toisin kuin ensimmäisessä skenaariossa, linkit artikkeleihin ja sivuihin toimivat oikein (niiden ei kuulu sisältää alihakemistoa). Rikkoutuvia ovat nimenomaan resurssit (css, js, media), joiden polkujen täytyy nyt sisältää /subdir.

Vaihe 1: valmistelu

Tässä vaiheessa emme ASETA WP_SITEURL- ja WP_HOME-vakioita, koska haku ja korvaus ei koske näitä arvoja, ja päivitämme WordPress-osoitteen manuaalisesti hieman myöhemmin.

Aseta ylläpitosivu samalla tavalla: kommentoi require(...) pois index.php-tiedostosta ja lisää html-paikanvaraaja. Vierailijat näkevät ylläpitoviestin, kun sinä jatkat ylläpitopaneelin käyttöä osoitteessa http://wp-standard-install.local/wp-admin/.

Vaihe 2: valikoiva haku ja korvaus tietokannassa

Keskeinen ero ensimmäiseen tapaan: korvaamme VAIN tiedosto- ja resurssipolut, emmekä koske sivuosoitteisiin. Tee tämä kohdistamalla korvaus /wp-content-kaavan avulla:

• //wp-standard-install.local/wp-content → //wp-standard-install.local/subdir/wp-content
• /app/public → /app/public/subdir (polku palvelimella)

Tarkista siirron jälkeen artikkelien sisältö: linkit muille sivuston sivuille EIVÄT sisällä alihakemistoa (oikein), kun taas upotetut kuvat sisältävät sen (myös oikein):

Vaihe 3: WordPress-osoitteen päivitys ja tiedostojen siirto

Siirry nyt kohtaan Asetukset → Yleiset ja lisää alihakemisto "WordPress-osoite (URL)" -kentän loppuun, esimerkiksi http://wp-standard-install.local/subdir. Heti tallennuksen jälkeen ylläpitopaneeli hajoaa, koska WordPress yrittää etsiä tiedostoja uudesta polusta, mutta ne eivät ole vielä siellä:

Luo subdir-alihakemisto julkiseen juureen ja siirrä KAIKKI WordPress-tiedostot sinne. Kopioi sitten index.php ja .htaccess TAKAISIN juureen, jotta ylläpitosivu pysyy näkyvissä, kun viimeistelemme työn:

Palauta index.php alihakemiston SISÄLLÄ tehdasasetuksiinsa: poista html-paikanvaraaja ja poista require-rivin kommentointi:

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

Nyt ylläpitopaneeli on taas käytettävissä osoitteessa http://wp-standard-install.local/subdir/wp-admin/:

Tarkista sisältö: kuvat ovat paikoillaan, tyylit latautuvat:

Viimeinen silaus: juuren index.php

Jäljellä on enää index.php-tiedoston päivitys julkisessa juuressa. Poista huoltosivu ja määritä oikea polku wp-blog-header.php-tiedostoon ottaen alihakemisto huomioon:

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

Sivusto avautuu juuri-URL-osoitteessa ja kaikki resurssit latautuvat alihakemistosta:

Siirry uudelleen kohtaan Asetukset → Permalinkit ja tallenna ilman muutoksia, jotta WordPress päivittää URL-rakenteen.

Vaihtoehtoiset työkalut ja virallinen menetelmä

Yllä kuvattu lähestymistapa WP Migrate DB Prolla on kätevä, mutta ei ainoa vaihtoehto. Tässä muita työkaluja, joita voit käyttää:

• *WP-CLI search-replace.* Komento wp search-replace '//oldsite.local/subdir' '//newsite.com' --dry-run-lipulla näyttää ensin, kuinka monta esiintymää korvataan. Valikoivaa korvausta varten (juuri → alihakemisto) rajaa kaava: wp search-replace '//newsite.com/wp-content' '//newsite.com/subdir/wp-content'.

• Virallinen WordPress-menetelmä. Dokumentaatio osoitteessa developer.wordpress.org kuvaa "Giving WordPress Its Own Directory" -menettelyn, jossa on yksityiskohtaiset konfiguraatiot Apachea (.htaccess), nginxiä (server block) ja IIS:ää (web.config) varten. Menetelmä ei vaadi lisäosia ja toimii millä tahansa hostingilla.

• Manuaalinen SQL. Jos muokkausten määrä on pieni, voit suorittaa UPDATE wp_posts SET post_content = REPLACE(post_content, '/subdir/', '/') suoraan phpMyAdminissa, mutta aina varmuuskopion kanssa, sillä tällainen korvaus tuhoaa serialisoidun datan wp_options- ja wp_postmeta-taulukoissa.

Minkä työkalun valitsetkin, sääntö on sama: kun siirrät JUURI → ALIHAKEMISTO, korvaa vain /wp-content ja tiedostopolut; kun siirrät ALIHAKEMISTO → JUURI, korvaa kaikki, mikä viittaa alihakemistoon.

⁉️🤔 Usein kysytyt kysymykset

Tarvitaanko WP Migrate DB Prota tämäntyyppiseen migraatioon?

Ei. WP Migrate DB Pro tarjoaa vain kätevän käyttöliittymän search-replace-toiminnolle, joka ymmärtää PHP:n serialisoitua dataa. Teknisesti voit tehdä samat korvaukset WP-CLI:n kautta (wp search-replace -komento käsittelee myös serialisoidut merkkijonot oikein) tai käyttää virallista WordPress-menetelmää manuaalisella tiedostonsiirrolla ja index.php:n muokkauksella. Lisäosa säästää aikaa suurissa ja keskikokoisissa projekteissa, joissa on paljon esiintymiä.

Mitä teen, jos osa kuvista ei vieläkään lataudu migraation jälkeen?

Yleisin syy: tietokantaan on jäänyt kovakoodattuja URL-osoitteita absoluuttisilla poluilla vanhalta palvelimelta, eivätkä ne täsmänneet korvauskaavaan. Tarkista artikkelien sisältö phpMyAdminin kautta: SELECT ID, post_content FROM wp_posts WHERE post_content LIKE '%/subdir/%' (tai vanha domain). Toinen ehdokas on selaimen ja CDN:n välimuisti: tyhjennä molemmat ja tarkista incognito-tilassa.

Täytyykö.htaccess päivittää siirron jälkeen?

Jos käytät selkeitä permalinkkejä, kyllä, mutta WordPress tekee tämän automaattisesti, kun napsautat "Tallenna" Asetukset → Permalinkit -sivulla. Jos palvelimella ei ole kirjoitusoikeuksia, WordPress näyttää valmiin.htaccess-sisällön kopioitavaksi manuaalisesti. Kun siirrät alihakemistoon, varmista, ettei juuren.htaccess (ei alihakemiston sisällä oleva) sisällä sääntöjä, jotka ovat ristiriidassa uuden rakenteen kanssa.

Onko mahdollista suorittaa migraatio ilman käyttökatkoa?

Teknisesti kyllä, jos käytät menetelmää.htaccess-uudelleenohjauksilla (virallisen WordPress-dokumentaation menetelmä I, "Without changing URLs"). Tässä lähestymistavassa tiedostot siirretään alihakemistoon, kun juuren.htaccess ohjaa kaikki pyynnöt saumattomasti uuteen sijaintiin. Vierailijat eivät huomaa siirtoa. Haittapuoli: pysyt samassa domainissa, eikä sivuston URL muodollisesti muutu (alihakemisto ei näy osoiterivillä).

Miksi WP Migrate DB Pro ei tue migraatiota eri asennustyyppien välillä suoraan paketista?

Delicious Brainsin kehittäjät keskustelivat tästä GitHubissa lähes kolme vuotta. Ongelman ydin: lisäosa soveltaa YHTÄ search-replace-paria KOKO tietokantaan, mutta migraatio juuren ja alihakemiston välillä vaatii ERI korvauksia eri URL-ryhmille (sivut vs. resurssit). Sen automaattinen määrittäminen, mikä URL kuuluu mihinkin ryhmään, vaatisi sisällön rakenteen jäsentämistä, mikä menee yksinkertaista search-replacea pidemmälle. Siksi nykyinen suositus on: tuo sivustot yhtenäiseen asennusmalliin ENNEN migraatiota.

Lopputulos: juureen vai alihakemistoon?

Valinta juuriasennuksen ja alihakemistoon tehtävän WordPress-asennuksen välillä kiteytyy yhteen kompromissiin. Juuriasennus on yksinkertaisempi: vähemmän liikkuvia osia, suora yhteensopivuus kehitys- ja tuotantoympäristön välillä, ei yllätyksiä kaksien URL-osoitteiden kanssa. Alihakemistoasennus on arkkitehtonisesti siistimpi: ydintiedostot on eristetty, juuressa on vain index.php, WordPressin päivittäminen Gitin/Composerin kautta on helpompaa ja usean sovelluksen isännöinti yhdellä verkkotunnuksella on turvallisempaa.

Jos sinulla on yksi tuotantosivusto ja yksi kehityssivusto, yhdenmukaista molemmat samaan malliin (kumpaan tahansa) ja unohda koko ongelma. Jos työskentelet tiimissä, jossa jotkin projektit ovat historiallisista syistä juuressa ja toiset alihakemistoissa, tiedät nyt tarkat haku- ja korvausmallit kumpaankin suuntaan.

Pääsääntö, joka kannattaa laittaa muistiin: kun siirrät JUURI → ALIHAKEMISTO, koske vain /wp-content-kansioon ja tiedostopolkuihin; kun siirrät ALIHAKEMISTO → JUURI, korvaa kaikki, mikä sisältää alihakemiston. Ja aina, aina klikkaa "Tallenna" Osoiterakenteet-sivulla siirron jälkeen.