Skip to main content

DrupalCon 2010 in San Francisco

I'm on a plane back from San Francisco this morning, after 3 days of DrupalCon, the annual gathering of Drupal people in North America (there's another one in Europe each year as well). At the first day's plenary -- the traditional State of the Drupal address by Drupal's founder Dries -- we saw pictures from ten years ago of Dries in his university dorm where he first created Drupal, and then another picture from five years ago at the first DrupalCon in Amsterdam with 40 people. Last year's DrupalCon in DC had about 2000, and this DrupalCon was over 3000 attendees. So Drupal is still growing.

I went to DrupalCon last year as well, and I valued it because I learned some things that are hard to learn from just reading websites, I got to know some of the personalities of the project, I met some useful people to know, and I generally got re-inspired about working with Drupal. Still, I'm mostly an introvert and had decided not to go this year until I found out it was in San Francisco, and the added attraction of visiting my brother who lives in Palo Alto tipped the scales for me. So, following are my loose collections of notes from the sessions I attended. 

Fusion and Skinr

This was a presentation by two of the TopNotch themers. I've used their premium themes in almost all my recent projects – it's a great way to get a nice looking theme easily and not very much cost. It seems they are now converting entirely to using Fusion and Skinr for all their themes, so it seemed like a good idea to try and understand what that means.

It turned out to be mostly understandable. Skinr is a module that enables “skinning”, which is how most applications (not just websites) choose to expose themselves to visual design changes. That means, being able to change a limited number of pieces of the design, typically colours and fonts, sometimes limited layout things. My understanding of how Skinr works is that it just injects divs around html elements, allowing the theme to apply collections of css to multiple elements.

So Fusion is the base theme that does this, by using the theme settings stuff to allow an administrative interface that is pretty point and click, where you say “apply this skin to this element” kind of thing. The goal here is to have some easy ways of doing standard things reliably and repeatably, so that's a good thing. It also implies and strategy with html/css that isn't semantic, which isn't great, but maybe isn't so bad. In any case, it looks like it's fulfilling a particular use case that is true for most of my work, so I'm pretty convinced so far. 

Ajax and Javascript in Drupal7

I've been evolving a lot with my use of Ajax and Javascript since learning Jquery, and wanted to keep up on the latest. Drupal likes to add yet another layer on top of jquery's already complex API, and it's usually a good thing. From this presentation, it looks like it's getting even better, and worthwhile to learn. I'm particularly loving that most of the functional bits (i.e. the difficult juggling between server script and client script) is getting easier, by pushing it into the server script and getting the client script generated by Drupal. I'm going to guess that debugging it is going to get harder... 

CiviCRM for Developers

I went to a “Birds of a Feather” meeting for CiviCRM developers. It was excellent to finally meet the core CiviCRM team (minus the famous lobo), and find out what David Greenberg really looks like (younger and more handsome than you might think). The session was mostly introductions, a little confusion, and then some breakout sessions where I learned some useful things. 


The Chaos Tools Suits (ctools) is a helper module created by Earl Miles (also known as Merlin of Chaos, of views and panels fame), that he created to be able to share some of his techniques that he uses in those two modules. It's actually a suite of tools that live in separate files and are loaded conditionally, so it's not a bunch of dead weight even if you're only using some of those tools. The presentation was not by Earl, but by one of the modules co-maintainers and documenters, which is a nice example of how the Drupal community works well. The module comes with an examples module to help understand the various pieces, which you should check before believing any of my notes below.
  1. CSS Tools. This is a handy bunch of functions that can analyse style sheet content. It can read, parse and filter stylesheets and then output style sheet content based on that, so you can use it to do super overrides. For example – you could convert all the Arial fonts on a page to Verdana...
  2. Dependent fields. This looks like a better way to do what I've done with custom jquery in themes before. It allows you to dynamically (i.e. via AJAX) modify a form based on the user's entries. So for example, you can modify the list of provinces available based on the selected country.
  3. Drop-down menu links. This is just a simple, handy theme function that allows to stick little drop-down menus (say, to little configuration icons, like gear wheels).
  4. Exportables. This is the engine for being able to export/import views, i.e. a way of encapsulating database settings into a php array representation that can be copy/pasted and put into revision control.
  5. Multistep forms. This works differently from other multistep forms in that it's tying together separate forms with state information.
Challenges of hosting Drupal on AWS.

Barry Jaspan is a big guy at Acquia, who's responsible for designing their systems of hosting lots of big commercial sites on Amazon's web service (AWS) intrastructure. One reason they do that is so that they can actually provision a server capable of lots of traffic, in about 20 minutes. He was talking about some of the specific issues/solutions that relate to this platform. What I found most interesting was:
  1. Acquia uses AWS for almost everything
  2. the challenges and solutions were quite understandable
  3. it's in use on such a big production environment (though only in the past year, how things have changed from a year ago!).
It also convinced me that I don't want to use AWS too much, there are a few funky proprietary issues that I feel claustrophic about it. Funnily enough, one service they don't use (S3, for static file serving) is the one that I do use. The one practical idea that I came away with was the use of “puppet” for configuration management. I also found it reassuring when he noted in reply to a question that in cases where there were performance issues for his clients, they usually boiled down to Drupal, not infrastructure problems – e.g. views with no index, or custom modules.

Website Development Process

During the afternoon, I was visiting the sponsors and had a nice conversation with a shop owner in Texas, who was a big fan of scrum. After that I went to a talk called “Defining and Pitching your Process”, and it made me want to read more about scrum, but reassured me that what I thought I know about the client end of the development process might still be true (or at least, shared by enough other people to pass as true).

Fields in Core

The last session I went to was by Karen Stevenson, who's responsible for the date module and maintaining cck. She was talking about the process of moving fields into core. Unfortunately, it's not looking very clean or easy, sounds like there's still a lot of little pieces to finish before the D6 → D7 migration paths are sorted out. But the abstraction of the concept of fields is pretty great – it means:
  1. you can attach fields not just to nodes, but to any 'entity' (user, comments, but potentially other entities).
  2. Field content doesn't have to be in the database, it can be stored anywhere.
Coming out of that session had me in awe of the huge risks the Drupal community bites off in re-inventing their code base, and reminds me again that I love Drupal because it's still driven by dreams, not dollars.  

Advanced Drush

I caught most of the “advanced drush” session in the overflow lounge – showing that drush is alive and well (or at least still fascinates lots of developers). There were a few presenters, and it had the feel of a “look at all the cool things drush can do” show. In any case, Drush is the way to do all things command line, and it can do a lot more than you might expect. Two of the cool features I didn't know about (maybe because they're only available in the latest 3.x version that just came out) are:
  1. The “shell” - you can run a little command that just defines a bunch of shell aliases, so that you're back in a shell, but with your various site configuration stuff set and all your favourite drush commands now available via unix-like commands that you can mix in with your normal shell commands.
  2. Aliases. One of the hassles of using drush is having to tell it the different configuration variables each time (i.e. document root and site). I currently do this by having a drushrc file in my current directory and accessing drush via a shell that automatically pulls it in, but the canonical and presumably better way is to use aliases that live in your .drush directory. I'll have to see whether this really makes my life easier ...
The White House on Drupal

The last session I went to was the plenary by David Cole, a young guy who's on the new media team at the white house, and who helped get to use Drupal. He was pretty inspiring in showing that young, idealistic people can still have a remarkable impact on government, and it was a proud moment when some of the authors and maintainers of Drupal modules got credited with helping it all happen – an open source contributor's dream.  


I don't like conferences, but DrupalCon is pretty worthwhile. I'd been a little jaded of late about the enterprise emphasis of Drupal as led by Acquia, and it might still derail and distract from the community-driven open source ethos of the project, but it hasn't yet. So I'm still in.


Popular posts from this blog

Orchestrating Drupal + CiviCRM containers into a working site: describing the challenge

In my previous posts, I've provided my rationale for making use of Docker and the microservices model for a boutique-sized Drupal + CiviCRM hosting service. I've also described how to build and maintain images that could be used for the web server (micro) service part of such a service.

The other essential microservice for a Drupal + CiviCRM website is a database, and fortunately, that's reasonably standard. Here's a project that minimally tweaks the canonical Mariadb container by adding some small configuration bits:

That leaves us now with the problem of "orchestration", i.e. how would you launch a collection of such containers that would serve a bunch of Drupal + CiviCRM sites. More interestingly, can we serve them in the real world, over time, in a way that is sustainable? i.e. handle code updates, OS updates, backups, monitoring, etc? Not to mention the various crons that need to run, and how about things like…

Building and maintaining Drupal + CiviCRM application containers

In my previous two posts, I provided some background into why I decided on using containers for a boutique Drupal + CiviCRM hosting platform, and why Docker and its micro-services approach is a good choice for building and maintaining containers.

Although I promised to talk about orchestration, that was getting ahead of the story - first I'm going to look at the challenge of keeping your application containers up-to-date with OS and application-level updates. There's a fair amount of work in that, but the tooling is mature and there is lots of good documentation.

A great place to start is to visit the official Drupal docker hub page. From there, you can pull a working Drupal code container, and it gets re-built frequently with all the OS and Drupal-code updates, so you just refresh your containers whenever you want (i.e. whenever a security release comes out, or more often to stay up-to-date).

A nice thing about that project is that it demonstrates a technique for maintaining …

IATS and CiviCRM

Update, Nov 2009: I've just discovered and fixed a bug I introduced in the 2.2 branch for the IATS plugin. The bug was introduced when i updated the API files from IATS and failed to notice that the legacy method for C$ one-time donations was no longer supported.
If you're using a version greater than or equal to 2.2.7, and are using IATS for C$, non-recurring donations, then you're affected.
To fix it edit the file : CRM/Core/Payment/IATS.php, and remove the line that looks like this:

$canDollar = ($params['currencyID'] == 'CAD'); //define currency type The full fix removes a conditional branch based on that value a little further on, but by removing this line, it'll never actually use that branch. Drop me a line if you have any questions.
Update, May 2009: This post is still getting quite a bit of traffic, which is great. Here are a few important things to note:
The IATS plugin code is in CiviCRM, you don't need to add any code.You do still …