WordPress 3.x lanserades för några månader sedan fanns det förutom synliga nya finesser även en del förändringar bakom kulisserna. En av de stora var custom post types, men här ska jag istället koncentrera mig på den för den vanliga bloggaren nästan osynliga multisite möjligheten.
Jag har inte mindre än fem bloggar som alla kör WordPress. Med fem diskreta installationer av WordPress kändes det alltid som lite väl mycket möda att hålla allt uppdaterat. För ca. ett år sedan började jag därför fundera på att flytta allt till WordPress MU och testade också lite, men hade aldrig tid att bena ut alla detaljer för att riktigt komma till skott. Budskapet att den skilda MU-distributionen skulle försvinna, eller rättare sagt bli inkluderad i normal WordPress från och med version 3 gjorde också att jag satt planerna på hyllan i det skedet.
Nu när WordPress 3.x varit ute ett tag och jag hade lite extra tid i somras beslöt jag mig för att på allvar försöka mig på att migrera mina fem installationer av WordPress till en enda multisite-installation. Målen var framför allt att:
- minska på jobbet med att hålla plugins uppdaterade
- förbättra prestanda genom att utnyttja det snålt tilltagna minnet i min hostade server effektivare
- förenkla administrationen och skrivandet genom att bara behöva logga in en gång för att administrera alla bloggar
Jag utnyttjade inte WordPress export och import-funktionaliteten för att flytta data mellan bloggarna eftersom jag tidigare haft problem och inte tyckt att den gjort ett bra jobb. Men den som står inför samma situation som jag kan gott börja med att prova det och se hur långt det bär.
Jag valde istället att göra en helt ny installation och endast ta över det nödvändiga, dvs. själva inläggen och de media-filer som laddats upp och refereras från dessa inlägg. Hela processen var i mitt tycke ganska smärtfri, men allt är relativt.
Om du vill göra något motsvarande så har jag här skrivit ner från minnet hur det gick till. Det rör sig inte om ett absolut steg för steg recept, men om du är lite van med WordPress och MySQL är det inte speciellt svårt. Som vanligt är det första och viktigaste steget att göra en säkerhetskopia på databaser och WordPress-installationer.
Bakgrund
Jag hade alltså fem vanliga WordPress-installationer som redan uppgraderats till 3.0 som jag ville flytta till en WP 3.0 installation med multisite-stöd.
Det gällde specifikt följande bloggar som tidigare var hostade som skilda domäner på Dreamhost.
- fickludd.sjostrom.fi
- klipptoklistrat.sjostrom.fi
- niklas.sjostrom.fi
- stranden.sjostrom.fi
- teknobabbel.sjostrom.fi
Jag började med att installera WP multisite på sjostrom.fi enligt instruktionerna på WordPress.org. Även om det ser lite långrandigt ut så består det i praktiken av att:
- installera en vanlig WordPress
- modifiera wp-config.php för att göra multisite möjligt
- logga ut/in
- aktivera multisite
- modifiera filerna
wp-config.phpoch.htaccess
Om en vanlig WordPress installation tar 3 minuter att göra tar det visserligen kanske 3 gånger så länge att göra en multisite installation, men på 10 minuter ska det vara möjligt att få det gjort. Mycket enkelt alltså.
Multisite kan göras på ett av två sätt vilket måste bestämmas en gång för alla vid aktiveringen. Alternativen är att antingen göra varje blogg till en subblogg under huvudbloggen.
- http://sjostrom.fi/stranden
- http://sjostrom.fi/teknobabbel
eller också göra bloggarna till skilda subdomäner i huvuddomänen
- http://stranden.sjostrom.fi/
- http://teknobabbel.sjostrom.fi/
Eftersom jag ville att min bloggar skulle behålla sina gamla adresser var valet lätt; subdomän skulle det vara.
Problemet med subdomän-alternativet är att man måste få förändringar gjorda i domändatat så att t.ex. i mitt fall stranden.sjostrom.fi presenterar WordPress-installationen under sjostrom.fi. Någon vanlig vidarestyrning ("redirect") med omskrivning av url:en som följd duger inte eftersom WordPress måste se den ursprungliga url:en för att kunna presentera rätt blogg. S.k. jokertecken i domändatat rekommenderas, men det ville jag inte använda eftersom jag har andra (icke WordPress) sites på sjostrom.fi (t.ex. url-förkortaren strm.sjostrom.fi) som jag ville att skulle fortsätta att fungera. Lösningen för mig var att använda mirror-funktionen i Dreamhosts (där jag hostar) administrationspanel. Med den kunde jag styra om enbart de fem aktuella subdomänerna till sjostrom.fi och lämna de övriga orörda.
Med en ny fungerande WordPress var det sedan bara att logga in som SuperAdmin och definiera de fem bloggarna. Så här långt var allt väldigt rakt på sak.
Hur multisite påverkar hur data lagras
En liten paus för allmän information om hur en multisite-installation ändrar på hur data i databaser och filer lagras.
Databasen
Databasen i en normal "singel-installation" av WordPress innehåller tabeller med namn som börjar på wp_. I en multisite-installation har den ursprungsinstallationen tabeller med samma namn, medan övriga bloggar i samma installation har tabeller med namn börjande på wp_{ID}_ och där {ID} bestämmer vilken blogg tabellen hör till. Vilka {ID}:n som gäller för bloggar får man lätt reda på genom att i WordPress administratörsgränssnitt gå till SuperAdmin → Sites och notera ID och Domain-kolumnerna.
Uppladdade filer
De uppladdade filerna i en singel-installation av WordPress lagras i /wp-content/uploads mappen, medan uppladdade filer i en multisite-installation lagras i /wp-content/blogs.dir/{ID}/files mappen.
I en singel-installation av WordPress refereras uppladdade filer direkt med url:ar i stil med http://{BLOGG}.{DOMÄN}/wp-content/uploads/ där urlen direkt motsvarar mappstrukturen i filsystemet. För en multisite-installation gör WordPress däremot vidarestyrningar vilka variera beroende på om det rör sig om en submapp eller subdomän multisite-installation. För en submapp multisite-installation refereras uppladdade filer med urlar i stil med http://{DOMÄN}/{BLOGG}/files/ medan de för en subdomän multisite-installation refereras med http://{BLOGG}.{DOMÄN}/files/.
Ett konkret exempel för att belysa. Filen NS_D200_2010-02-28_5308-Edit.jpg ansluten till ett inlägg bloggat på Teknobabbel i mars 2010 skulle alltså lagras följande olika ställen beroende på installation.
- /wp-content/uploads/2010/03/NS_D200_2010-02-28_5308-Edit.jpg
(gammal singel-installation)
- /wp-content/blogs.dir/4/files/2010/03/NS_D200_2010-02-28_5308-Edit.jpg
(multisite installation oberoende av typ)
Samma fil skulle refereras i html-koden i inlägget som
- http://teknobabbel.sjostrom.fi/uploads/2010/03/NS_D200_2010-02-28_5308-Edit.jpg (gammal singel-installation)
- http://teknobabbel.sjostrom.fi/files/2010/03/NS_D200_2010-02-28_5308-Edit.jpg (subdomän multisite-installation)
- http://sjostrom.fi/teknobabbel/files/2010/03/NS_D200_2010-02-28_5308-Edit.jpg (submapp multisite-installation)
Förhoppningsvis någorlunda klart? Bra, då fortsätter vi.
Exportera och importera data
För varje blogg gjorde jag sedan följande för att flytta över mina inlägg och mina filer.
Jag dumpade följande tabeller från den gamla installationen av en blogg med phpMyAdmin i Dreamhosts administrationspanel.
- wp_comments
- wp_links
- wp_postmeta
- wp_posts
- wp_terms
- wp_term_relationships
- wp_term_taxonomy
wp_commentmeta verkade i allmänhet tomma på mina bloggar så jag struntade i dem. Eftersom jag är den enda användaren brydde jag mig heller inte om att flytta över informationen i wp_users och wp_usermeta.
Jag adderade Add DROP TABLE/VIEW/PROCEDURE/FUNCTION till export-optionerna i phpMyAdmin, men körde annars med standard inställningar och valde att spara som fil.
Innan den sparade filen kunde laddas upp måste den modifieras lite för att laddas in i rätta tabeller i den nya installationens databas.
Jag editerade den dumpade filen med en text-editor och korrigerade `wp_ till lämpligt `wp_{ID}_ (apostrof för att hindra att t.ex. _wp_ i tabelldata också byts ut). Här gäller det ändå att vara försiktig. I en av mina bloggars data finns en sträng som matchar men som inte ska bytas ut. Här liksom i instruktionerna i fortsättningen ska {ID} bytas ut mot den aktuella bloggens {ID}. Hoppa under inga omständigheter över det här steget eftersom du i så fall skriver över själva multisite-installationens tabeller.
Sedan importera jag den sparade filen till den nya installationens databas. Också här använde jag phpMyAdmin.
Flytta uppladdade filer
Jag flyttade över allt från den gamla installationens /wp-content/uploads mapp till den nya installationens /wp-content/blogs.dir/{ID}/files.
Sedan hamnade jag att korrigera databasen så att inläggen korrekt refererar till de nyss flyttade filerna enligt beskrivningen ovan.
För en submapp-installerad MU-installation ändrar detta från t.ex. http://{BLOGG}.sjostrom.fi/wp-content/uploads/ till http://test.sjostrom.fi/{BLOGG}/files/. För en subdomän-installerad åter till http://{BLOGG}.sjostrom.fi/files/.
I mitt fall med en subdomän-installation gällde det alltså att köra SQL-kommandon i stil med (åter igen använde jag phpMyAdmin) och SQL-fliken där.
update wp_{ID}_posts set POST_CONTENT = replace(POST_CONTENT, 'http://{BLOGG}.{DOMÄN}/wp-content/uploads/', 'http://{BLOGG}.{DOMÄN}/files/')
Allt innnanför klamrar i meta-kommandot ovan ska naturligtvis bytas ut så t.ex. i mitt fall så såg det konkreta kommandot ut så här:
update wp_4_posts set POST_CONTENT = replace(POST_CONTENT, 'http://teknobabbel.sjostrom.fi/wp-content/uploads/', 'http://teknobabbel.sjostrom.fi/files/')
Det kommandot gör är alltså att det går igen post_content-fälten i wp_4_posts-tabellen och byter ut http://teknobabbel.sjostrom.fi/wp-content/uploads/ mot http://teknobabbel.sjostrom.fi/files/.
Lösa ändor
Efter instruktionerna ovan hade jag alltså flyttat över allt mitt data (inlägg och bilder) för bloggarna. Ännu återstod att ominstallera alla plugins, teman och liknande. De här försökte jag inte ens migrera eftersom jag såg det som en direkt fördel att börja från tomt bord gällande plugins eftersom det under fem års användning samlats allt möjligt som fyllt wp_options-tabellen med skräp.
När WordPress görs multisite försvinner vissa inställningar från de enskilda bloggarnas "Settings" och flyttar istället till Super Adminens Sites->
update mns_{ID}_options set option_value = "http://rpc.pingomatic.com/\nhttp://topicexchange.com/RPC2\nhttp://rpc.weblogs.com/RPC2\nhttp://blogsearch.google.com/ping/RPC2\nhttp://rpc.technorati.com/rpc/ping\nhttp://ping.weblogs.se/\nhttp://nyligen.se/ping/\nhttp://rpc.pingomatic.com\nhttp://rpc.twingly.com\nhttp://ping.bloggnytt.se\nhttp://rpc.aitellu.com" where option_name = "ping_sites"
I mina tidigare singel-installationer använde jag Thesis och WP Zooms Gallery som teman. Inget av dessa fungerade riktigt klockrent i en multisite-installation utan framför allt TimThumb-funktionen som dynamisk genererar olika storlekars bilder ställde till med problem. Sannolikt skulle problemen ha gått att lösa, men eftersom jag ändå funderat på att övergå till Genesis temat genomgående beslöt jag att göra det samtidigt. Genesis och dess subteman har visat sig fungera utan problem även i en multisite-installation.
Efter några veckor med den nya multisite-installationen kan jag konstatera att det absolut var värt jobbet att göra konverteringen i.o.m. att de ursprungliga målsättningarna alla har uppfyllts.