I posted an article on the CivicActions blog about upgrading your CiviCRM installation from version 1.x to 2.x. Follow the "Continue reading" link to see the complete post.

When upgrading your CiviCRM site from 1.x to 2.x you might have to upgrade some custom modules. If you're upgrading to CiviCRM 2.1 or higher, this also requires that you're running Drupal 6. Upgrading your custom Drupal 5 modules for Drupal 6 is pretty easy: you simply download the coder module which will point out almost all required changes to your module with direct links to the documentation page about converting 5.x modules to 6.x.

Upgrading your custom CiviCRM modules to be compatible with 2.x however won't be as easy since a bunch of functions have been replaced or removed. The idea is to motivate developers to use the internal API's directly and not use these helper functions anymore. There is a developer discussion about the API Migration from 1.x to 2.x and while it offers some indication as to what functions were replaced, it doesn't provide a valid alternative for all removed functions.

Continue reading »

Earlier this year I wrote a small guide on what to do when you're experiencing character encoding issues after upgrading MySQL to version 4.1 or higher. Now after a large combined effort with JirkaRybka a documentation page is set up in the Troubleshooting FAQ: MySQL 4.0 -> 4.1 migration.

This guide includes background information, a description of several issues when upgrading MySQL and a solution for each problem. You no longer need to manually change update.php (cfr. my earlier guide) since a stand-alone script was written that works for Drupal 4.7, Drupal 5 and Drupal 6! This is very important since Drupal 6 will require you to have MySQL 4.1 or up, if you're using MySQL of course, and this will make upgrading so much easier, saving people a lot of precious time debugging. This documentation and the script are all a combined effort of JirkaRybka, Heine, Acert93 and myself.

You can check the original request by Acert93 to provide more information on this issue and see how this documentation came to be.

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 »