PCWereld upgrade naar Drupal 5 en verhuis

Nu Drupal 6 al in beta is, werd het wel eens tijd om de PCWereld website te upgraden van Drupal 4.7 naar Drupal 5. Ik loop meestal redelijk achter met upgrades omdat er heel wat custom code achter zit die elke keer moet worden geupdate, maar ook omdat ik die site regelmatig gebruik om patches te testen.

Dankzij de hook_*_alter() functies heb ik in mijn pcwereld_custom module heel wat aanpassingen kunnen doen aan de links en forms die door drupal core worden gegenereerd, zonder de core files te moeten patchen. Hoe minder dat nodig is, hoe beter natuurlijk.
Maar zoals gewoonlijk heb ik toch drupal core op een paar plaatsen gepatched, voornamelijk voor performantie redenen. Ter info (en vooral als geheugensteuntje voor mezelf), dit zijn de gebruikte patches:

• Drupal 5 backport van de javascript aggregation patch. We hebben heel wat modules die hun eigen stukjes javascript toevoegen. Als dat allemaal in verschillende bestanden zit, zijn dat veel te veel bestandjes om in te laden. Gecombineerd met css aggregation zorgt dit voor heel wat minder requests en betere YSlow scores. Het enige wat de score nu nog naar beneden haalt is dat die bestanden nog niet ge-gzipt worden, mod_deflate ontbreekt op de server. Ik zou er misschien eens achter moeten vragen..
• legacy-module-fix-redirects.patch. Een bugfix voor fouten in de legacy module, ondertussen gecommit in 5.x-dev.
• "no table locking"-patch. De gebruikelijke aanpassing, gebruikt mysql-specifieke "REPLACE" syntax in plaats van table locking te gebruiken.
• use http 1.0 responses on error pages. Als drupal een error pagina genereert gebruikt die altijd HTTP/1.1, onafhankelijk van wat de client gebruikt. Een bepaalde proxy kan daar niet goed mee overweg en geeft dan random cijfers bovenaan de pagina weer. Dit maakt dat beest weer happy.
• forum 404s de forum module heeft de gewoonte gewoon blanco paginas te genereren als je iets opvraagt dat niet bestaat (eg. http://drupal.org/forum/blah). Zeker nu we pathauto gebruiken is het belangrijk om wel deftig "page not found" berichten te genereren.
• een paar eenvoudige aanpassingen zodat de locale module minder queries naar de database lanceert. Eigelijk zou iemand die 75 chars limiet van de locale cache eens moeten herzien. Maar ja, wie ben ik nu weer om dat te zeggen, het is niet dat ik die limiet uit mijn duim heb gezogen. Of wacht, misschien toch..
• automatische path whitelist, voor elke url een query naar de database sturen leverde enorm veel queries op, van veel daarvan weet ik op voorhand dat ze toch niet gaan bestaan. Dit is een backport van een patch die op drupal.org gepost geweest is en ik destijds opnieuw gemaakt had voor D5. Het origineel moet ergens hiertussen staan denk ik.

En waarom zit dit niet allemaal in de issue queue op drupal.org? Omdat ik enkel de dingen submit waarvan ik denk dat ze kans maken ooit gecommit te worden. Nadeel van de voor developers minder hippe stabiele versie te gebruiken, je krijgt daar praktisch niets in zonder eerst doorheen D6 te gaan en dan te laten backporten. Maar ik loop achter en heb geen D6 omgeving dus ik wacht gewoon tot iemand anders datzelfde opmerkt.

Aangezien de site toch down moest voor een upgrade, heb ik van de gelegenheid gebruik gemaakt om van webhost te veranderen. Met enige moeite is de site nu bij Openminds ondergebracht. Voor bezoekers niet direct een groot verschil maar voor mezelf is heel wat eenvoudiger geworden. Alle code staat eindelijk netjes in CVS/SVN en ik heb eindelijk SSH toegang. Iemand die ooit een database van 100M heeft proberen te importeren via phpmyadmin weet wat een miserie upgrades vroeger waren.
En natuurlijk een lichtjes getweakte php.ini om wat vriendelijker te zijn op de server (APC, memory limit wat verlaagd,..).

De site draait nu ook achter een reverse proxy, dus standaard gaat drupal in de watchdog en tracking altijd het IP adres van de proxy loggen. Daarmee weet je natuurlijk weinig. Dit is echter heel simpel op te lossen door dit op te nemen in je settings.php:

$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];

Drupal 6 zou hiervoor waarschijnlijk een speciale instelling gaan hebben, maar dit werkt voor mij perfect.

Oh ja, *ooit* zal er wel eens iemand langskomen die een deftige nieuwe layout kan maken hoop ik. Wees blij dat ik me er niet mee bezig hou want als developers dat moeten doen gaat het resultaat heel Web 0.9 zijn ;)