Do you hate it as much as I do when you are writing some PHP (or Python or whatever) code in your favorite editor, hit 'save', reload the page in the browser in the hopes that you will see the new most awesome feature you ever wrote, but instead you are greeted by an unfriendly PARSE_ERROR_YOU_FORGOT_A_CLOSING_BRACKET_YOU_STUPID-error? Right, it feels like you just built a rocket, but upon launch you discover you didn't foresee a doorknob and can't get in anymore...

Luckily, if you are using Vim there is a nice plugin to quickly catch these errors (and more). The plugin I'm talking about is Syntastic. The plugin is built as a generic framework to run and process the result of a syntax checker. The syntax checkers themselves are specific for each language. Most of the syntax checkers start an external syntax checker or linter and return the output to Syntastic, telling it how to parse it.

By default Syntastic will automatically run the correct checker every time you save the …

This is the second part of a series on how I upgraded my website from Drupal 6 to Drupal 7. The sources for my website are freely available on my github account.

• Introduction: the site and what I wanted with the upgrade
• Automation with scripts, drush and drush make
• Installing from scratch: the installation profile
• Upgrading from Drupal 6: upgrader module and update method

Automating as much as possible

When I started working on the new version of the site, I did not only want to be able to install the site from scratch. I also wanted the one-time upgrade from Drupal 6 to Drupal 7 to be as smooth as possible. However, the life of a website doesn't stop once the initial deploy (or 're-deploy' in this case), is done. In fact, it only begins at that point. You will need to keep the site updated with new functionality and, more importantly, with security updates. Sadly, this deployment and updating is often an afterthought, or not done at all …

This is the first part of a series I plan to write on how I upgraded this site to Drupal 7. I have made all the sources available on my github account, as it can serve as an example on how to do Drupal development without database dumps. These are the parts I plan to write:

• Introduction: the site and what I wanted with the upgrade
• Automation with scripts, drush and drush make
• Installing from scratch: the installation profile
• Upgrading from Drupal 6: upgrader module and update method

Introduction

Nearly 1,5 years ago I decided that I wanted to migrate my Wordpress blog and two other custom sites into a single Drupal based website. At that time Drupal 7 was not yet final (or just a few days, can't remember exactly) and was not yet really in a usable state for a regular site without too much difficulties. So I went with Drupal 6 and I decided …

I finally took the time to make my 'drupaldev'-repository available.

First a short introduction: It is my strong opinion that Drupal modules which are only used during development, such as devel, diff, etc, should never be deployed to production. They shouldn't even be in the repository. Instead, I keep a personal collection of development-modules in a separate repo. Thanks to the fact that Drupal recursively searches for modules inside the modules folder, I can simply create a symlink to my collection of development modules. This allows me to use my preferred modules, even though they are not in the repository for the project.

For Drupal7, I usually just create a symlink, named devmodules7, in sites/all/modules. Like this:

# from the drupal root of the project
ln -s ~/drupaldev/devmodules7 sites/all/modules/

The repository itself contains a collection of modules, for both Drupal 6 and Drupal 7, and some utility-scripts. After experimenting with copies of the modules and git submodules, I finally settled on drush make to manage the …

Today I'm happy to launch the new version of my weblog. (Oh and also the rest of the website, although some content still needs to be updated.) This is version 3 of the weblog, not counting my very first weblog at blogger.com. Although it's only been 1.5 year since I switched from Nucleus CMS to Wordpress, I once again switched over to another CMS: Drupal. Not because I was unhappy with Wordpress (it's a really nice system), but Drupal gives me a lot more flexibility. Flexibility which I needed to implement some new ideas I had for this version of the weblog and my website in general.

I have always maintained a few different sites, running on a plethora of applications. I had my photo website (fotos.budts.be), which ran on ZenPhoto; I had lightyear.be with the activity stream, running on Gregarius with some self-hacked ruby code to write the final stream; Then I had my cv-site (budts.be/jeroen), which was mainly just static html …