Vincent Kouters

De complete lay-out van deze website is veranderd, dat moge duidelijk zijn. Ik hoop dat een en ander nu duidelijker te vinden is, en dat de ‘visuele aspecten’ op de voorpagina het geheel wat aantrekkelijker maken. Toch was deze verandering van vormgeving nooit een doel op zich, maar een bijkomstigheid. Ik ben namelijk overgestapt op een ander content managing system.

Drupal vs. WordPress

Drupal is ingeruild voor WordPress. Waarom? Een hoop redenen. Dit artikel zegt het aardig. Punt is dat Drupal een topzwaar systeem is, waarmee in principe hele grote communitywebsites kunnen worden gerund, maar dat van gebruiksvriendelijkheid geen kaas heeft gegeten. Iets ogenschijnlijk simpels als, zeg foto’s bij een artikel plaatsen, was met een Drupal een hele toer. Het ‘admin’-gedeelte van de site was een volstrekt onoverzichtelijke wirwar van knoppen, opties en willekeurig verschijnende modules. Plus qua vormgeving bleef het systeem achter. Tel daar nog eens bij op dat updaten van de core files en modules bij Drupal een crime was, iets waar ik vaak aan ben begonnen, maar nooit heb voltooid en de conclusie was: exit Drupal.

Enter WordPress. Een systeem dat ik al kende van andere websites waar ik voor schrijf, en dat in verhouding een licht en toegankelijk stukje software is.

Maar goed, toen kwam het: de verhuizing. Omdat het geen optie was om 250 berichten en 450 tags opnieuw in te voeren, moest ik een manier verzinnen om de gegevens uit de Drupal 5.4-database te verhuizen naar de WordPress 2.7-database, die een compleet andere structuur kent. Hiervoor bestaat helaas geen kant-en-klaar programma. Via Google kwam ik op websites van D’Arcy Norman, Vrypan en Jungle bruikbare stukken script en info tegen van mensen die voor dezelfde uitdaging stonden – want dat is het.

Deze websites waren handig, maar omdat het toch altijd gaat om net iets andere versies (Drupal 5.6, 5.7 of zelfs 4.X, of WP 2.nooit-de-mijne), waarbij de databasestructuur altijd net even anders is, en omdat niet iedereen exact dezelfde info wil verhuizen (wel tags en geen categorien, of toch allebei, en misschien ook custom-made velden?), moest ik mijn eigen migratie script in sql-statements schrijven.

Workflow

1 WordPress installeren (in dezelfde database als Drupal)

2 Mijn sql script loslaten op de database via de PHPMyAdmin interface van de webhost. (Eerst het hele ding geback-uped.)

Dit verwijdert eerst alle fabriekscontent van WP

use naam_database;

delete from wp_posts;    
delete from wp_comments;
delete from wp_terms;    
delete from wp_term_taxonomy;
delete from wp_term_relationships;

Zet de berichten over

# posts
INSERT INTO
    wp_posts (id, post_date, post_content, post_title,
    post_excerpt, post_name, post_modified)
SELECT DISTINCT
    n.nid, FROM_UNIXTIME(created), body, n.title,
    teaser,
    REPLACE(REPLACE(REPLACE(REPLACE(LOWER(n.title),’ ‘, ‘_’),’.', ‘_’),’,', ‘_’),’+', ‘_’),
    FROM_UNIXTIME(changed)
FROM naam_database.node n, naam_database.node_revisions r
WHERE n.vid = r.vid;

# fix post slugs. first we have to remove the duplicate _____ chars, then replace that with a single – char
UPDATE wp_posts set post_name = REPLACE(post_name, ‘__’, ‘_’);
UPDATE wp_posts set post_name = REPLACE(post_name, ‘__’, ‘_’);
UPDATE wp_posts set post_name = REPLACE(post_name, ‘__’, ‘_’);
UPDATE wp_posts set post_name = REPLACE(post_name, ‘__’, ‘_’);
UPDATE wp_posts set post_name = REPLACE(post_name, ‘_’, ‘-’);

Dan de reacties

# comments
INSERT INTO
    wp_comments
    (comment_post_ID, comment_date, comment_content, comment_parent, comment_author, comment_author_email, comment_author_url)
SELECT
    nid, FROM_UNIXTIME(timestamp),
    comment, thread, name, mail, homepage
FROM naam_database.comments ;

# update comments count on wp_posts table
UPDATE `wp_posts` SET `comment_count` = (SELECT COUNT(`comment_post_id`) FROM `wp_comments` WHERE `wp_posts`.`id` = `wp_comments`.`comment_post_id`);

Dan de tags naar de nieuwe WP taxonomy structuur

# tags en categorien (drupal) naar tags (WP)
INSERT INTO naam_database.wp_terms(term_ID, name, slug)
SELECT term_data.tid, name, lower(replace(name,’ ‘,’-')) as slug
FROM  naam_database.term_data ;
insert into naam_database.wp_term_taxonomy (term_taxonomy_id, term_id)
SELECT term_data.tid, tid
FROM  naam_database.term_data ;

update wp_term_taxonomy set taxonomy =”post_tag” where taxonomy = “”;
INSERT INTO naam_database.wp_term_relationships(object_id, term_taxonomy_id)
SELECT term_node.nid, tid
FROM  naam_database.term_node;

en verwijdert ten slotte de om de een of andere reden automatisch gegenereerde samenvattingen van de berichten.

# optioneel – leegmaken van de samenvatting
update wp_posts set post_excerpt=”";

Wat dit script niet doet: categorien overzetten. Dat heb ik daarom handmatig gedaan. (Ook doet het niks met users, images en wat dies meer zei, maar dat was in mijn specifieke geval niet nodig.)

3 Omdat WordPress URL-aliassen anders samenstelt dan Drupal, en het onmogelijk was om de lijst in de database over te zetten, was het nodig om in een .htaccess bestand voor ieder bericht in een zogenaamd ’301 redirect statement’ te voorzien. Omdat een weblog als dit zijn meeste verkeer haalt uit Google-zoekopdrachten en referrer links van andere websites, zou het doodzonde zijn om al die oude URLs naar een 404-foutmelding te laten verwijzen. Met een 301 daarentegen laat je bezoekers subtiel weten dat een URL is veranderd door ze naar het nieuwe adres te verwijzen en dit ook aan te passen in de URL-balk van de browser. Vandaar dat ik voor ieder bericht een dergelijke regel in het .htaccess bestand heb opgenomen. (Let op de kleine verschillen.)

Redirect 301 /kluchtige_satire_op_politieke_bedrijf_in_richard_i_bij_keesen_co http://www.vincentkouters.nl/kluchtige-satire-op-het-politieke-bedrijf-in-richard-i-bij-keesenco

Zowel de oude als de nieuwe URL-aliassen zijn met PHPMyAdmin uit de database te exporteren naar een Excel-bestand, waarin ik de twee lijsten vervolgens verder heb geformateerd (met ‘merge cell content’) tot 400 regels in bovenstaande exacte opmaak.

Daarbij niet vergeten om ook een redirect te maken voor de URL van de RSS feed, zodat ook de RSS-lezers niet zonder content komen te zitten.

4 Dat was het moeilijkste. Ten slotte heb ik mijn nieuwgemaakte theme geactiveerd en in WordPress zelf – op de gangbare  manier – de puntjes op de i gezet. Dat duurde ook nog vele uren en dagen vanwege allerlei problemen met browser-compatibiliteit (Firefox, Explorer, Chrome en Safari hebben iedere zo hun eigen interpretatie van een html-pagina en bijbehorende CSS-regels), maar dat is weer een heel ander onderwerp.

Dit was even een korte uiteenzetting van mijn ervaring met het overstappen van Drupal op WordPress. Omdat hier niet zo heel veel informatie over te vinden is, leek het me nuttig om dit online uit de doeken te doen. Natuurlijk is het bovenstaande alleen van toepassing op mijn specifieke situatie. Dit is dan ook zeker geen kant-en-klare tutorial. Dat gezegd hebbende: doe er je voordeel mee. Er zijn 999.999 manier waarop het fout kan gaan. Dus dat het fout gaat gaan, is zeker. Maar uiteindelijk is het de moeite waard. WordPress FTW!