Engwar

Drupal, amelioratory management

I’m going to take Drupal as an example during this post and outline some of the challenges of working on it with a loosely knit team. One major problem with PHP based content management systems is that it’s PHP. So, anyone who have taken the time to stare at some code snippets could modify, say, the user module (in Drupal) and get his changes displayed (assuming that’s what he wanted in the first place). As a side note, PHP Manual is all you need to learn about PHP. This was a much criticized fact for Ruby, lack of freely accessible up-to-date documentation. Although situation is improving as the ruby-doc project gained more momentum. Any “teach yourself how to clean dog poop in 24 hours” guides are useless because it’ll take 10 years to learn howto program effectively.

Coming back to Drupal, this issue of having the freedom to modify anything ‘cos it’s all PHP should really not be an issue but experience suggest otherwise. Having restricted access to Drupal core files is also of limited success. Remember, I’m not talking from an outsiders perspective where you worry about world readable files and whatnot, this is from the developer perspective who has full control over making a code level change. A set of people maintaining the site doing continuous modifications.

If you’re just running Drupal as a blog and you’re the only one who makes changes to it, then there are no issues. In a team environment sometimes you assume that something like a change to a core file should not be done unless you have 1) googled 2) RTFM (thrice) and there’s no other way to do it, but surprisingly people overlook this fact and do change the stuff that should not be changed. Usually these kind of shit happens when you cut your software engineering lectures and go collecting meadow muffins on perfectly bright and sunny days.

Close examination suggest legitimate reasons such as,

1. It’s easy to customize, say, include/common.inc rather than reading the API doc, which is comparatively harder and takes more time
2. Naming conventions. common.inc. “I need to display the top most blah blah blah nodes on these set of pages, it’s a common feature to all these so common.inc is the right place to do it”.
3. You do need to get something displayed, quickly, you know it’s not the right way to do it but since time is more important you decide to change a line in a core module which is trivial.

All goes well for a couple of years until someone else takes over and use the universal language to communicate with your entire genealogy.

Those 10 second hack jobs will stack up with time and by the time shit hits the fan, no amount of version control could save you. Problems arise when you have to update your CMS. Files such as common.inc belongs to the Drupal core and will be updated. So if you have modifications in those files you now have to get those to the system. If you’re really unlucky and the API has changed now you have to substitute the new functions. This will become tedious when you have to go through each and every file to see what has been added/modified. Things get more vexing if you have nodes embedded with PHP code. These are nodes with Input type PHP. If the API has changed now you have to go through those pages and see what breaks.

So what are the possible solutions for this mussed up state of affairs?

1. Making it hard to modify the core files which will be replaced during an upgrade.
2. Enforce an internal policy regarding the modifications so that changes happen in either the theme used or in a separate module.

Making everyone aware of the extension mechanisms available and doing changes in a disciplined manner will save you when you have to upgrade. Also this will make the life of the maintenance programmer easier. This does have one drawback. Turnaround times for features/changes will now take a bit more time than earlier but the big upside is the whole thing could be rapidly updated (if there’s a security vulnerability or a newer version have a killer feature, makes it faster etc…) and someone else could take over without much effort.

Posted in drupal, php · August 23rd, 2008 · Comments (2)