drupalplanet

For the past year, all of my Drupal work has been devoted to building a product on top of Drupal. In the beginning of the year, I worked with the Science Collaboration Framework to create PD Online. For the past 7 months, I have been with GoingOn building a social education platform on top of Drupal. I hope I will have the opportunity to tell you everything I have learned at Drupalcon in the Building a Product on top of Drupal session held by Tao Starbow and I.

Since I live in New England, and I adore any Drupal social events, I am of course attending Design 4 Drupal this June! I'm excited to have another large event to meet up with and talk with other Drupal enthusiasts.

I am eager to contribute what I can to help designers maximize the Drupal theme layer, so I submitted three sessions: introduction to version control, sustainable theming and image upload for content.

I've put the entire Drupalcon Schedule into a Google Calendar. This allows you to access it on your smart phone or any other internet-enabled device. I am also putting in social events, with links and addresses (which can automatically be linked to a map). If there are any changes to the schedule, I will be able to make the update through my phone as soon as I hear about it.

The URIs: iCal, HTML, XML

When it comes to using a WYSIWYG editor in Drupal, TinyMCE and FCKeditor are the heavy weights in the contributed module arena. TinyMCE seems to have more supported plugins and modules, while FCKeditor seems to have the community's love (as much as any web developer can possibly love a WYSIWYG editor, that is). To complicate things, Drupal is moving towards using the WYSIWYG API module as the future for WYSIWYG editing, requiring more to consider than simply the TinyMCE (or TinyTinyMCE) and FCKeditor modules.

Staging and deployment is a vital part of any project, Drupal or not. As I've discussed previously, staging and deploying to production is particularly difficult for all the Content Management Systems out there that intermingle content and configuration settings within the database - and Drupal is definitely one of them.

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.