- Developer Corner
- Recent posts
As you may be able to see, we recently migrated gnunet.org to Drupal 7. I'm trying to document this here a bit, maybe this is helpful to others. The big remaining issue is that our custom theme doesn't work at all anymore, despite me trying to follow the theme migration guide. Help migrating the theme (https://gnunet.org/svn/gnunet-www/GNUnet/ has the code and history) would be very much appreciated, for now, we're back to Garland (ugh). Overall, my upgrade experience was mixed; the worst issues were:
I also had a lot of fun migrating the FAQ module. After migration, all of the entries first simply disappeared. While there is a FAQ for the FAQ module that specifically talks about it, it doesn't give steps for the resolution -- and ultimately the cause mentioned there also didn't apply. When I turned of the categories, the FAQ entries magically showed up, but the number of questions is simply too large for a flat list. In our case, the fix was to assign a language (English) to the terms for the FAQ in the respective taxonomy. Somehow (after migration?) the old terms simply had "no language" and thus the categories didn't get displayed.
The 'date' module also created some issues. Making a Debian package for it using 'dh-make-drupal' works fine, but that package lacks certain 'Provides:'. Using 'equivs' (Debian package), I created a pseudo-package with the missing 'provides', which in my case were "drupal7-mod-date-api,drupal7-mod-date-views,drupal7-mod-field-ui". I believe "drupal7-mod-field-ui" is actually provided by yet again another Drupal component, but I just lumped all of those missing provides in one big fix.
Migrating other Drupal packages (such as captcha, bot, nice-menus and syntaxhighlighter) was painless. One minor issue was that actually running the PHP 'upgrade' script seemed to just hang at times -- no CPU load, no database load, but still minutes of wait time. Given that the new server is VERY fast, I aborted the process serveral times looking for an error. Ultimately, the solution was to just have more patience. So maybe someone should look for those 'sleep' calls --- or at least warn users that patience is required and that servers mightl just idle around during most of the upgrade process.