Categorie: Wordpress

Na jaren van afwezigheid ben ik weer terug op het net. Ik vond onlangs een sql backup van mijn oude WordPress site in de mail terug. Hiermee heb ik mijn blog alsnog kunnen installeren. Samen met de Wayback Machine ga ik proberen om zoveel mogelijk nog te redden.

De reden dat mijn blog verdwenen was is dat enkele jaren geleden mijn microclient abrupt is overleden. De harde schijf was niet repareerbaar.

Voor nu ga ik verder met een volgende uitdaging die je in de volgende blogposts ongetwijfeld terug zult lezen.

Terug van weggeweest. Zowel de site als ik zijn een tijdje met vakantie geweest. Nu was het niet de bedoeling dat de site ook plat ging maar mijn gratis dyndns account moet elke 30 dagen vernieuwt worden. Nu had ik mijn sitecom router ingesteld om dit te doen maar blijkbaar werkt dat niet naar behoren.

Terwijl ik op de camping zat is er een mailtje in mijn mailbox terecht gekomen met de melding dat ik nog enkele dagen had om de boel alsnog te vernieuwen. Maar aangezien ik afgezien van de (auto)radio verder alle luxe afzweer tijdens de vakantie kon ik dit mailtje nu pas lezen.

Ik kwam op de site van Henk van de Kamer weer wat tegen, iets wat overigens al van een tijd terug is. Het gaat om een controle over correcte HTML. Nu heb ik ook een mooi XHTML 1.0 logo op de site staan maar heb hier na een 1e controle nooit meer naar omgekeken. Tijd dus om hier even verandering in aan te brengen.

Als eerste het bash script maar even aanpassen naar mijn situatie:

#!/bin/bash

let i=1
while [ $i -le 141 ]; do
wget -q -O index.htm "http://validator.w3.org/check?uri=http%3A%2F%2Ftecumseh.homeip.net%2F%3Fp%3D$i"
echo "$i is "`grep -E '^( *)\[(Valid|Invalid)\]$' index.htm | sed -re 's/.*\[(.*)\]$/\1/'` >> checked.txt
rm index.htm
sleep 15
let i=i+1
done

Hieruit volgen een aantal fouten, het merendeel is overigens correct. De meeste fouten zitten tussen de <pre> tags. WordPress negeert hier over het algemeen de opmaak, zoals het hoort overigens.

Hier een opsomming van de aanpassingen:

• Bericht 6: Het verwijderen van een harde return lost de fout op (<hr />)
• Bericht 10: Het vervangen van de haakjes < en > door &lt; en &gt; in het fstab stukje
• Bericht 63: Ik heb in tussen de <pre> tags een stuk staan waarin tekstueel een smiley zit, wordpress vervangt deze maar moet er eigenlijk vanaf blijven. Ik heb er dus een punt achter gezet zodat de smiley niet geconverteerd wordt.
• Bericht 70: In het commentaar heb ik in een reactie een stuk van mijn fstab staan, hierin moesten de tekens < en > geconverteerd worden naar &lt; en &gt;
• Bericht 82: WordPress geeft de <img> tag een backslash op het eind, na het toevoegen van een aantal extra parameters (width, heigt en class) vindt de validator dit geen probleem mee
• Bericht 99: Ook hier weer een aantal < en > tekens die vervangen zijn door &lt; en &gt;

Iets wat ik tot nu toe nog niet gebruikt heb zijn de file-uploads. Nu ben ik gisteravond even bezig geweest om te controleren of mijn berichten wel Xhtml valid zijn. Ik kwam meteen al een 1e post tegen die destijds vanuit blogger overgenomen is. Hierin zat nog de afbeelding vanuit blogger, die heb ik dus maar op deze server gezet. WordPress sputterde echter nogal tegen, de juiste directory kon niet aangemaakt worden.

Het koste uiteindelijk nogal zoeken, eerst de directory rechten aangepast naar 775 en zelfs 777. De eigenaar veranderd in www-data (de gebruiker die de webserver bedient) maar ook dat mocht niet baten. Uiteindelijk heb ik in WordPress een optie gevonden die het aanmaken van subdirectory’s kan uitschakelen. Hiermee krijg ik echter alles op 1 grote hoop. Het werkt wel voorlopig maar ideaal is het dus niet.

Vandaag even verder gezocht op php safe mode, dat zou namelijk de boosdoener zijn. Dit uitschakelen lijkt me niet een goed plan maar na een stukje lezen (onvoorstelbaar hoeveel sites er eigenlijk niets over schrijven) ben ik er eindelijk uit. De safe mode beperking zorgt er namelijk voor dat een script met een bepaald uid en guid enkel bestanden aan mag maken op de webserver onder zijn eigen gebruikersnaam. De webserver maakt ze echter aan en die heeft een ander uid. De oplossing is dus dat ik de scripts (de php bestanden) van eigenaar moet veranderen. Het volstaat al om de groep te veranderen, dus:

Arkon:~/web/tecumseh.homeip.net$ chgrp -R www-data wordpress/

Na het herstellen van de wordpress optie zodat er weer subdirectory’s aangemaakt mogen worden kan ik netjes georganiseerd bestanden toevoegen.

Ik kom met het updaten er ook achter dat ik voor deze wordpress installatie een mailadres gebruik wat niet meer bestaat. Het is dan ook vrij rustig in de mailbox. Helaas lijdt het veranderen van het mailadres bij de gebruikersnaam niet tot het updaten van alle instantie’s hiervan. Zo blijft het oude adres bij alle commentaren staan. Dat wordt weer prutsen met SQL in phpmyadmin:

UPDATE `wordpress`.`wp_comments` SET `comment_author_email` = 'mgdijkerman@gmail.nscom' WHERE `wp_comments`.`comment_author` = "Tecumseh";

Recent is er een nieuwe versie van WordPress uitgekomen. De update procedure die ik nu gevolgd heb is ietswat anders verlopen. Ik heb deze keer geen patch gemaakt waarmee de verschillen in de 2 versies eruit gehaald kunnen worden. Ik kwam namelijk na de wijziging van 2.3.1 naar 2.5 een paar onhebbelijkheden tegen. Bijvoorbeeld het niet inladen van de afbeeldingen in de editor.

Ik heb dus nu bijna de lelijke manier gebruikt die WordPress zelf voorsteld. Namelijk het volledige vervangen van alle bestanden terwijl de database intact gehouden wordt. Uiteraard heb ik de wijzigingen die ik zelf gedaan heb (slechts enkele kleine dingen) wel weer doorgevoerd. Deze omschakeling heb ik niet live gedaan, ik heb de database eerst gekopieerd om vervolgens de nieuwe versie van WordPress op een ander domein neer te zetten. Deze heb ik vervolgens stukje bij beetje veranderd zodat ik geen missende onderdelen meer heb.

De grootste wijziging is het thema geweest. Niet aan de oppervlakte maar wat betreft de vertaling. Ik heb dit thema namelijk ooit van een site afgehaald wat de boel al volledig vertaald had, te volledig helaas omdat ook de variabelen en dergelijke meevertaald werden. Vervolgens heb ik de vertaalslag in een schoon thema nogmaals gedaan maar dan op de correcte manier. Althans dat dacht ik. Het blijkt namelijk dat dit thema al volledig multi-talig was. Het enige wat nodig is dat is een taalbestand voor het nederlands. Geheel in de stijl van WordPress wordt dit gedaan met gettext. Ik heb hiervoor dus de .mo en .po bestanden aangemaakt. Deze zijn hier te vinden.

De andere wijziging die ik doorgevoerd heb is het verplaatsen van de wordpress bestanden. Ik had deze voorheen in de documentroot van dit domein staan. Ik kwam er echter achter dat dit netter kan. Je kunt namelijk wordpress in een subdirectory zetten en vervolgens het index.php bestand en het configuratiebestand 1 niveau lager zetten. Je moet in index.php wel 1 klein dingetje aanpassen:

/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php');

Moet worden:

/** Loads the WordPress Environment and Template */
require('./wordpress/wp-blog-header.php');

Hiermee is meteen de weg vrij om meerdere blogs vanuit 1 wordpress installatie te bedienen. Hiervoor hoef je dan enkel een symlink te plaatsen naar de algemene wordpress bestanden. Wat er dan nog overblijft is de wp-content directory waarin bijvoorbeeld de uploads geplaatst worden. Die moet ook nog verplaatst kunnen worden maar dat is voor een volgende keer.