Having tested it since the private beta, I'm running Mollom for about 4 months now on this blog. Ten days ago I started running it on a client's site: 16plus.be. The site allowed anonymous comments after moderator approval when overnight we started receiving hundreds of spam messages on a daily base. This didn't affect the live site since all comments were placed in the moderation queue, but for the maintainers it was very annoying and it created a lot of extra work wading through the pages upon pages of spam. With Mollom enabled we allowed anonymous users to post comments without approval.

Continue reading »

Working at the VRT I've had the pleasure of upgrading Toyinima from Drupal 4.6, 16plus.be from Drupal 4.7 and Studio Brussel from 5.1 to the newest Drupal 5.3. These were core-altered installations with a lot of custom and contribute-altered modules. I started of by dividing the non-core modules between those still in their original state to a "contrib" directory and those that were either completely custom or altered in a "custom" directory, to get the following tree structure:

This helps you identify what needs to happen and will also save a lot of work for future upgrades. I then started from a clean Drupal 5.3 installation, download the newest version of the modules in /contrib and then started a process of 1) moving the core changes to non-core modules and themes and 2) updating the /custom modules.

I must admit updating the custom modules went a lot faster than I imagined. Drupal 4.6 took by far the longest time with upgrading the forms to the FormAPI as well as updating the theme. What took the most time for all three sites was identifying the alterations done to core, what they were doing and how this could be moved to the modules and templates. The developers did a fine job documenting their changes to core, which made things a lot easier. Some of these changes were patches offered in the d.o issue queue (not necessarily by the module maintainers) as quick bug/security fixes, like this issue for the event module.

Two things to remember:

Upgrading Drupal is not a scary task. People refrain from upgrading because they fear it might fail and break their site. Keep your head cool and make an index of changes that need to happen: divide your modules in altered and non-altered versions, identify any changes made to core and take it one step at a time. There's plenty of good documentation to help you and people in the forum and on #drupal-support are waiting to help you on your way.

Once again, please don't alter core, don't even suggest altering core as a quick fix. The time you win by "fixing" the issue in this manner is lost twice when upgrading later.

Continue reading »