Often wrong, never in doubt

Drupal.be code sprint


On valentine's day I attended my first real code sprint, the drupal.be code sprint. I was really looking forward spending the day with a bunch of fellow Drupal enthusiasts to implement the new drupal.be.

I was not able to make it to Antwerp at 8h30 because that is a wee bit early for me during the weekend. In stead I worked from home and finished a module to download and repackage the drupal tarball from drupal.org together with the Dutch translation to enable the Dutch speaking community to install Drupal in Dutch without having to download anything else. You can download the package created by the module at http://drupal.be/download. I'm currently perfecting this module to make it easy to administer and to be able to add modules to the package as well. It will be released in a couple of weeks.

In the afternoon I joined the code sprint team in Antwerp and spent the afternoon mainly tackling bugs. The first one was that we had issues with the profile and contact pages. Apparently this was caused because the migration from D5 to D6 added a columns "accessed" with 0 as default value and you cannot view profile pages:
// The user is not blocked and logged in at least once.
($account->access && $account->status && user_access('access user profiles'))

The second one that was bothering a lot of people was that the navigation menu was nog behaving properly. After some investigation I noticed that admin links stayed available, even after disabling the modules. The reason for this was probably that the menu table was not working correctly. To resolve the issue I truncated the menu_links table and visited the modules page to rebuild the menu. This worked beautifully and the navigation menu was working as intended again. The only problem was that the primary links dissapeared. Indeed, all the links are in hook_menu so do not truncate it! Just delete the links for the navigation menu.

And last but not least there was a permissions problem on the server. The drupal.be server runs apache and fastcgi (with suexec) to serve .php pages. The .php from drupal.be are run under the Drupal user while images etc. are picked up by the www-data. So if you upload a file through the web interface it will be owned by the drupal user but it has to be readable by the www-data user and this was not the case in our case. After checking umasks and various fastcgi settings I still wasn't able to wrap my head around the issue. It seems everything was configured correctly but for one reason or another some process, somewhere, was not respecting the umask settings. This apparently is a bug in PHP 5.2.0 where move_uploaded_file does not respect the umask but uses its own (0066) in stead of the OS one (0022). Since we're running debian etch and we're sticking with the stock PHP install I added a chmod() in the core file.inc to resolve the issue. Please be careful when upgrading!

A consequence of fiddling with server issues is that I was asked if I would be willing to administer the server drupal.be is running on. An opportunity and challenge I was not going to refuse! So, if there are issues with the server, please pass them on. For the moment everything is running great for regular visitors, I think.

Suddenly it was 23h00 and we were a long way from finished. We still decided to put the new version online and fix the remaining issues during the coming weeks. The problem is now that there are quite a few design problems left and that nobody seems to pick them up. If you're interested in helping, please leave a note and I'll try to arrange svn access so that you can fix up the theme!

I really enjoyed spending the day coding in this way and am already looking forward to the next sprint!