drupalplanet

Back in the day (only 18 months ago in fact), whenever I started a new Drupal project I would read through the entire modules list and download each module I thought could be useful for the website I was developing. Once the contributed modules grew to such an extent that it would take me half a day to read through the entire list, my method to become acquainted with the current state of modules became prohibitive. Today, it would likely take several days to read through the entire list of available modules, and it would overload anyone's brain to process the sheer quantity of information and inspired ideas of relationships between modules.

I finally decided that what I've been developing in the dbscripts module is stable and decent enough to deserve an official 1.0 release. I've written up the problem I was trying to solve with these scripts in another blog post.

So what are some improvements I've done since I first released it? Besides refactoring and cleaning up the code, I have added:

Here's a quick bash script for automatically adding and deleting files in subversion. Don't you hate having to list each one individually? Or getting all those messages that say, "the file has already been added" when you just do svn add my/directory/*. Even more of a pain if you selectively delete a bunch of files.

I use this small little script. It's a huge time saver.

For the Brown University Featured Events website, I needed to develop a means to use their events for other purposes around the Brown.edu websites. I ultimately created a basic way of exporting iCal, RSS and HTML of a selected span of events.

As I've mentioned before, version control with Drupal is tricky because a lot of configuration changes are stored in the database. Version control is vital because you should be maintaining multiple workspaces so you do not work on production. The last thing you want to do, then, is to make this worse by putting PHP in your nodes and blocks.

2bits wrote up a great post explaining that you should free your content of PHP. Yes! Read that! Follow it and add it to your Drupal bible.

As most Drupalers have realized, iCal support for Drupal is in its infancy. The first successful implementation of it was only realized at the beginning of 2007 in the calendar module. It still has a lot of limitations - there are issues with time zones, and a complete lack of customization that CCK offers.

There are virtually an unlimited amount of ways to set up a development environment, and it all depends upon your project's individual needs and your preferred workflow. Sometimes, though, it just takes experience and exposure to other ideas to figure out what would be best. So, here is a description of my development environment.

The websites Today at Brown and Media Relations, developed in Drupal, have been released and live for a few months now. Media Relations was released at the beginning of this last semester, while Today at Brown was released within the past month.

Migrating changes from development to production is particularly tricky in Drupal due to a large amount of configuration settings being stored within the database. Attendees of Drupalcon 2008 made it clear that this is a particularly annoying problem. I attended the Development / Test / Production Environments panel to learn about how the big guys (including Drupal.org itself) manage deploying their sites from one working space to the next. We were disappointed to discover that even the big guys are currently writing down all the steps to upgrade and simply performing them on the production server.

This method poses several problems due to the Human Element being involved in the entire process.

I was tasked with maintaining a Drupal website that had 44 views. The template.php file for the theme was unwieldy. I spun off all the views template code into another file for ease of maintenance, but it was still 1333 lines¹ weighing in at 36.5kb! ^{[1] Just four more lines and it could have been elite!}

The quantity of views certainly wasn't pretty, and when I had to add in another view, I decided that enough was enough. It was time to clean it up and develop a system to help keep the views under control.