Auteur: bruno

Zoals gisteren vermeld, was de URL voor een post in dit weblog samengesteld volgens de methode

http://blog.volume12.net/[JAAR]/[MAAND]/[POST ID].htm

Logisch, en gemakkelijk om terug te vinden, zou u kunnen stellen, al vraag ik mij af welke meerwaarde de jaar- en maandaanduiding in de URL biedt. Het kan inderdaad interessant zijn om alle postje van een bepaald jaar, een bepaalde maand of zelfs dag gegroepeerd terug te vinden, maar die datum noodzakelijk maken om een URL aan te maken, vooral wanneer de eigenlijke identificatie van een post numerisch is, lijkt me overkill.

In alle eerlijkheid, was het vooral de manier waarop MT (mijn vorige blogsysteem) de posten publiceerde dat mij ertoe aanzette een dergelijke structuur te gebruiken. MT publiceert immers de postjes als ‘echte’ bestanden, op de webserver. WP publiceert eigenlijk niks, maar haalt alle informatie uit een database, afgeleid van de samenstelling van de URL. Ergo, een lijst van 1500+ bestanden in de root directory bij MT is een beetje onoverzichtelijk (scroll daar maar eens door), maar bij WP stelt het probleem van een dergelijke hoeveelheid bestanden zich eenvoudig niet.

Een URL waarin de titel van de post wordt vermeld, genre

http://blog.volume12.net/2005/10/boeken-200509.htm

lijkt mij niet voordeliger dan een volledig numerische URL. De ganse opzet achter het gebruik van dergelijke URLs is om het de bezoeker gemakkelijker te maken informatie terug te vinden. Ik zie evenwel niet in wat het voordeel zou zijn van een URL zoals dit

http://gent.blogt.be/2005/12/05/hier-spreekt-men-gents-6-de-tussenstand

te bieden heeft boven een URL zoals dit

http://blog.volume12.net/2452.htm

Integendeel, de tweede (numerische) URL lijkt mij korter om ergens op te schrijven, of te onthouden. Een wijziging naar

http://gent.blogt.be/hier-spreekt-men-gents-6-de-tussenstand

maakt de zaak er niet noodzakelijk eenvoudiger op.

Het probleem zit hem in de lengte van de URL, de samenstelling van de woordgroep (aaneen geschreven, met ‘-‘, ‘_’ of nog iets anders), en de uniciteit van de identifier. In dat laatste geval geldt: hoe langer de URL, hoe kleiner het risico, maar wat te doen indien we twee of meer postjes met als titel ‘boekenlijst’ hebben? In WP levert dat de volgende URLs op

http://blog.bolume12.net/boekenlijst

http://blog.bolume12.net/boekenlijst-1

…waarmee we opnieuw met nutteloze complexiteit geconfronteerd worden.

Geheel anders wordt dat in het geval van een aantal min of meer standaard zaken, zoals ‘info’, ‘archives’, etc., waarvoor het geheel logisch is de naam in de URL te verwerken.

http://blog.volume12.net/info/

Maar hier is duidelijk sprake van een onderscheid tussen permanente informatie en wisselende content.

Terug naar die wisselende content; belangrijker dan de URL is de manier om de informatie te ontsluiten, de mogelijkheid die aan de bezoeker wordt gegeven om informatie terug te vinden. Drie mogelijkheden worden standaard op de meeste weblogs aangeboden: (1) de search box, (2) de categorieën, en (3) de chronologische archivering. Van deze drie is de search box de meest doeltreffende (op voorwaarde dat die goed werd geïmplementeerd), zijn de categorieën vooral handig voor een onderverdeling van de interesses (bvb computers & internet vs klassieke muziek), en is de chronologische archivering eigenlijk de minst interessante voor een weblog. (Tenzij het over een evenement-gedreven weblog gaat natuurlijk.)

Veel interessanter is tegenwoordig het gebruik van tags (keywords), die vrij aan een post kunnen worden toegekend. Klikt men op zo’n tag, dan krijgt men een lijst van alle entries die met dat keyword werden geassocieerd. Wordt de lijst te lang, dan kan men –bij een goede implementatie van het systeem– de selectie verfijnen door een tweede tag toe te voegen die relevant is voor het gezochte. Helaas heb ik voor WP nog geen dergelijke implementatie gevonden (tips zijn uiterst welkom).

Vandaar het ondergeschikte belang van ‘betekenisvolle’ URLs voor weblogs. Gezien de hoeveelheid entries op een webblog, en daaraan toegevoegd de manier waarop de meeste weblog archieven worden samengesteld, is niet de URL maar wel de ontsluiting van de archieven van primordiaal belang. De eerste (voornamelijk theoretische) stappen in de goede richting zijn reeds gezet, maar het is voorlopig nog wachten op een adequate implementatie.

Gisteren, in het eerste deel van de migratie van MT naar WP hadden we het over de export/import van de weblog data. Gezien WP de zaken toch op een iets andere manier presenteert, was het noodzakelijk een aantal voorzorgen (in casu nazorgen) te nemen om linkrot te voorkomen.

2. link rot bestrijding

Niet alleen is er een (klein, maar vervelend) verschil in structurele aanpak bij WP, maar gezien ik toch in .htaccess moest prutsen, heb ik maar meteen de URLs voor de weblog helemaal aangepakt.

De URLs voor dit weblog werden vroeger samengesteld aan de hand van het POST ID, de maand, en het jaar. Voor mijn boekenlijstje met de boeken die ik had gelezen in september, een post gepubliceerd op 1 okotber, zag de URL er als volgt uit:

http://blog.volume12.net/2005/10/002452.htm

Om redenen die ik in een van mijn volgende postjes nog wel uit de doeken zal doen, heb ik de URL gewijzigd naar

http://blog.volume12.net/2452.htm

Dat betekent dat ik ervoor moet zorgen dat de oude links transparant op de nieuwe links uit komen. We editeren de .htaccess file op de server, en voegen het volgende lijntje toe:

1. RedirectMatch permanent /200[1-5]/[0-1][0-9]/0*(.*).htm$ http://blog.volume12.net/$1.htm

Dat laat zich als volgt ontleden:

• RedirectMatch
  Een apache directive. Apache is de webserver; redirect betekent dat iets naar iets anders wordt verwezen, en die ‘match‘ betekent dat er parameters aan te pas komen (meerdere opties).
• permanent
  het is geen tijdelijke verwijzing, maar een permanente.
• /200[1-5]/[0-1][0-9]/0*(.*).htm$
  Het gezochte; een beetje prutsen met regex. We willen elke URL die begint met een jaartal tussen 2001 en 2005 200[1-5], verder gezet wordt met een maand –dus van 01 tot 12; volgens de gebruikte code eigenlijk van 01 tot 19– [0-1][0-9], en eindigt met een POST ID dat begint met een aantal nullen 0* en dan nog iets anders (.*), en eindigend op .htm .htm$. Wat gezocht werd, is die ‘iets anders’ (.*).
• http://blog.volume12.net/$1.htm
  Wat gezocht werd wordt gewijzigd naar de nieuwe URL; (.*) wordt gebruikt in $1.

Er zijn nog een paar andere redirects nodig, want ook de newsfeeds worden anders gelinked:

1. Redirect permanent /index.xml http://blog.volume12.net/feed/
2. Redirect permanent /index.rdf http://blog.volume12.net/feed/
3. Redirect permanent /atom.xml http://blog.volume12.net/feed/

En tot slot zijn er nog de categorieën; WP vereist dat voor elke categorie een voorvoegsel komt, en eigenlijk lijkt me dat best logisch (kwestie van te diferentiëren tussen categorieën en tags). I.p.v. het
langere ‘categorie’ heb ik maar geopteerd voor ‘cat’ –in navolging van het andere 3-letterwoord ’tag’; ‘c’ leek mij bij nader inzien toch maar wat te kort.

1. Redirect permanent /gent/ http://blog.volume12.net/cat/gent/
2. Redirect permanent /de_krant/ http://blog.volume12.net/cat/de-krant/
3. Redirect permanent /transport/ http://blog.volume12.net/cat/vervoer/

Er zijn drie gevallen:

1. Transparante overzetting: ‘/oud/’ naar ‘/cat/oud/’
2. WP werkt met ‘-‘ als verbinding tussen woorden ipv ‘_’ zoals bij MT, dus ‘/oude_cat/’ naar ‘/cat/oude-cat/’
3. Zeldzame volledige wijziging: ‘/oud/’ naar ‘/cat/nieuw/’

En we zijn ermee klaar. Of toch bijna. Want gezien ik niet met het standaard WP archief-formaat /%year%/%monthnum%/%day%/%postname%/ werk, maar met /%post_id%.htm, maakt WP van mijn ‘gedateerd’ archief /date/%year%/%monthnum%/%day%/%postname%/. Geen probleem: in de door WP aangebrachte wijzigingen in .htaccess halen we gewoon telkens die date/ eruit. Als je dit doet, moet je er wel voor zorgen dat die RedirectMatch van daarnet, boven de WP wijzigingen staat in .htaccess; anders krijgen we een infinite loop.

Totdaar. In een volgende aflevering hebben we het no over MT plugins, en daarmee wordt deze korte reeks waarschijnlijk beïndigd.

Het begint er zowaar goed uit te zien (achter de schermen). Migratie van MT naar WP is lang niet zo gecompliceerd als men zou willen denken. Natuurlijk zijn er een paar zaken waar men rekening mee moet houden, maar zoals steeds bestaat er voor alles wel een trucje.

1: export/import

Simpel, zou u denken gebruik de ‘export‘ functie bij de MT admin interface. Bij dit log zat er echter een eerste addertje onder het gras. De entries worden gelist met hun ‘ID’, ipv de titel. Bij een export uit MT import in WP krijgen alle entries een nieuw ID, waardoor links vanop andere sites niet langer zouden werken.

De oplossing is redelijk eenvoudig (cfr WordPress Migration Notes).

Stap 1:

In uw MT installatie dient u /lib/MT/App/CMS.pm te editeren op (ongeveer) lijn 2970: daar voegt u het stukje code POSTID: <$MTEntryID$> toe:

2970. CATEGORY: <$MTCategoryLabel$>
2971. </MTEntryCategories>
2972. DATE: <$MTEntryDate format="%m/%d/%Y %I:%M:%S %p"$>
2973. POSTID: <$MTEntryID$>
2974. —--
2975. BODY:
2976. <$MTEntryBody convert_breaks="0?$>

Stap 2:

Exporteer uw entries via de MT interface.

Stap 3:

In de WP installatie editeert u /wp-admin/import-mt.php; op lijn 277 (de lijn voor default:) voegt u de volgende code toe:

275. $post_date_gmt = get_gmt_from_date("$post_date");
276. break;
277. case 'POSTID':
278. $post_id = $value;
279. break;
280. default:

en op (ondertussen) lijn 292 wijzigt u de code

292. id, post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt, post_status, comment_status, ping_status, post_name, post_modified, post_modified_gmt)
293. VALUES
294. ('$post_id', '$post_author', '$post_date', '$post_date_gmt', '$post_content', '$post_title', '$excerpt', '$post_status', '$comment_status', '$ping_status', '$post_name','$post_date', '$post_date_gmt')");

Stap 4:

Importeer uw geëxporteerd bestand, zoals in de WP codex beschreven staat.

Stap 5 (optioneel):

Zelf was ik nogal allergisch aan het systeem van de <!-- more --> toestanden, die bij het importeren tussen uw body en extended entry body wordt gestoken. Vooral op de voorpagina (index, homepage) toon ik reeds graag de volledige post.

Geen probleem: we doen een beetje van SQL. Via de phpMyAdmin interface, voeren we dit simpel SQL commando uit (opgelet dit is onomkeerbaar):

1. UPDATE wp_posts SET post_content=(REPLACE ( post_content,'<!--more-->',''));

En voilà: uw MT weblog is een WP weblog geworden.

Volgende keer: MT naar WP: linkrot bestrijding

Er wordt lustig gefrunnikt, achter die schermen. Al is Telenet niet geneigd serieus mee te werken. ’s ochtends vroeg wijst de DNS naar de nieuwe locatie bij Dreamhost, maar voor de rest van de dag, tot een uur of vijf-zes ’s avonds, krijg ik zelf de oude locatie (Priorweb) te zien. U begrijpt, dat werkt niet gemakkelijk.

De overgang van MT naar WP verliep zonder al te veel problemen, al moe(s)ten er nog een paar zaken gefinetuned worden. Eenmaal alles naar behoren draait, schrijf ik een kort verslagje.

Wordt (zoals steeds) vervolgd, m.a.w.

En bij deze zijn we verhuisd.

Verandering van spijs doet eten, en op één been kunt ge bovendien niet staan, waardoor we niet alleen de provider hebben gewisseld, maar tevens de weblog software. Van priorweb naar dreamhost, van Movabletype naar WordPress.

Het verloopt allemaal nog een beetje moeizaam, maar ik ben ervan overtuigd dat u daarvoor alle begrip kunt opbrengen. Het is tenslotte voor iedereen weekend.