Aug 29 2010
Aug 29

DrupalCon Copenhagen comes to an end, as does my blogging hiatus.

Two of my primary learning objectives here in Copenhagen were configuration management and deployment process. Historically, working with Drupal in these areas has been unpleasant, and I think that's why there is tons of innovation going on in that space right now. It needs to be fixed, and new companies are springing up to say "hey, we fixed it." Often, the people running the companies are the same people running the project that encapsulates the underlying technologies. I'm referring to:

  • The hyper-performant core distro, Pressflow
  • Distros with sophisticated install profiles, like OpenAtrium, ManagingNews and OpenPublish
  • Configuration externalization with Features
  • Development Seed's "for every site, a makefile" workflow using drush make
  • The different-yet-overlapping hosting platforms Pantheon and Aegir

Dries commented in his keynote that as Drupal continues to grow, it also needs to grow up. I think advances like these are part of the community's answer to that. I want to wrap my head around some of these tools, while continuing to watch how they progress. Others, I want to implement right now. What's perfectly clear though is that I have a lot of work to do to keep up with the innovation going on in this hugely powerful community. Which is actually nothing new, but reading a blog post about these technologies doesn't make my jaw drop the way that it does when I'm in the room watching Drupal advance.

Jul 31 2010
Jul 31
Printer-friendly version

Patches that we write for drupal.org modules are submitted to the issue queue, and we refer to the patch’s location on drupal.org in the make file. This has made us much better contributors to other people projects as it makes being involved in the issue queue a normal part of development, and it encourages us to only patch contrib modules where it’s likely that the patch will be accepted. When a patch gets a review, we make changes, upload a newer version of the patch to drupal.org, and update our make file.

In this particular case, using make files actually codifies the decision to integrate closely with contrib modules and actively improve them / add features as needed for a particular project.

I've followed this practice for years, albeit without make files. Patches go in a "patches" directory in version control, with the patch file named with both the name of the module and the node number of the issue on Drupal.org.

An additional process is that if a patch is needed, you run it in the issue queue on Drupal.org, but you also have an internal ticket that links to that issue. You don't close the issue until the patch has been accepted into the mainline of the module. Then you can remove the patch, update the version of the module you're using, and your clients' website is one step closer to easier long term maintenance and updates.

And yes, being involved in the issue queue SHOULD be a normal part of developing Drupal websites.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web