Planet Drupal

In the past few months, Mollom has done a very good job blocking spam on my site. Its accuracy has increased a lot since I first installed it, nearly no spam gets through even though there are hundreds attempts a day.

However, I've been seeing a different kind of spam that does get through. Comments that are left by humans, who can solve the captcha shown by Mollom. These comments are usually on-topic and at first glance appear to be legit, except that the homepage URL of the author links to a spam site. I enabled nofollow a long time ago, but that doesn't appear to make much of a difference anymore.

I've even seen comments that had no link in them at all. I'm not sure what the purpose of those messages is. Maybe they are just checking whether someone removes these comments, or maybe they are trying to confuse Bayesian filters. Either way they are pretty annoying.

I could enable comment moderation on this site, but that would make me the bottleneck as I don't check the queue that often. I noticed that nearly all of these comments show up on a limited number of pages. So I wrote a simple little module that allows me to enable comment moderation for individual nodes and enabled this on the pages that are targeted by these spammers.
This has been running for about a week now and has blocked all such messages. There have even been less attempts, possibly because of the warning message that appears in the comment form. Lets hope it stays this way so I can remove the nofollow tags on links.

After months of testing, Mollom has finally gone public beta. Mollom is a web service that checks comments and other content for spam similar to what Akismet does. The nice thing is that when it's not sure about a message, it doesn't place it in a moderation queue but instead shows the user a CAPTCHA. For more information, see "How mollom works".

I've been testing the module the past few months and it works pretty well. Very few spam comments got past the filters while at the same time most of the regular visitors never had to fill out an ugly CAPTCHA. They also have some interesting goals, not limited to just blocking spam, but checking the quality of content as well.

And most important, it has fancy graphs ;)

It will be interesting to see how this evolves and if their infrastructure can handle all the new users. Earlier today the website itself was unreachable because of a major power outage in the LCL datacenter where the website is hosted. Luckily the web service itself is distributed across multiple locations and as far as I can tell it just kept working. Leave it to Murphy to test your fail-over on the very first day..

It's almost that time of the year again. In a few weeks the eight FOSDEM event will take place here in Belgium. And just like back in 2005 there will be a Drupal developer room.

The developer room will be available on Sunday 24th and there will be sessions non-stop from 9:15 until 17:45. You can read entire schedule here.

Unfortunately as every year there will be a lot of interesting sessions that overlap. I also wanted to go to the talks about Xen and OpenQRM but I think I'll hang out in the drupal devroom and watch the videos of the other sessions later.
I'll definitely be there on both Saturday and Sunday and maybe on the beer event as well, if time permits.

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 ;)