Anyone who has worked with Drupal much knows that one of the platform’s greatest strengths is its community.  With 3,100+ attendees and overflowing conference rooms the size of football fields, the recent Drupalcon Denver 2012 was probably the greatest gathering of drupalistas the world has ever seen.   Attending the conference was a real treat and I learned a ton.

While the pure scope of the conference was impressive, the quality of the sessions was the most impressive thing about Drupalcon Denver.  I took around 20 pages of typed notes during the conference, and have countless things I want to experiment with and follow up on.  Since no one is interested in reading my twenty pages of notes, I want to break out my three key takeaways from the conference.

1. Mobile

Everyone knows that mobile is becoming a more and more critical part of website development.  Drupalcon Denver really drove the point home for me.

In his keynote, Luke Wroblewski argued for developing for mobile first, desktop second.  In addition to the obvious fact that if you do that your website will work on all devices, mobile first development forces teams to focus on only critical functionality instead of bells and whistles.  This makes everything a bit simpler and more usable. The examples he gives in his presentation really demonstrate the positive impact a mobile first approach can have on a website.

It was also encouraging to hear that mobile is the #1 priority for Drupal 8, which Dries Buytaert talked about with the first keynote of the conference.

2. Drupal Security

It was very interesting to learn about Cross Site Request Forgery attacks at the Drupal Security for Coders session. But what really stood out to me at this session was how bad of an idea it is to use the PHP Filter text format in the Drupal admin. The biggest reason not to use this is that it opens the site up to possible attacks if user supplied php variables are used in insecure ways, which can be easily done by designers or site users. Not only that, but it prevents that page or block from being able to be cached and it slows down the processing of that element. Going forward, we are going to avoid using this as much as possible.

3. Features Module

I’ve heard about the features module, but I hadn’t used it or seen it in action before this session. This module allows you to take all of the pieces of an area of your Drupal site, and create a “Feature Module” that you can then download and upload to another site. This is practical for designers, site builders and coders, as it allows for easily transporting updates or whole areas of a site from one Drupal site to another. You put all of the configured fields, required modules, content types, tags, etc… into the feature module for that area, export it and then upload it to the new site and enable it like any other module.

Without using the features module, the process of transporting features like this is a tedious and time consuming process. Now it is just a matter of exporting the feature and uploading it.

There are many other things I could talk about, but this covers what I consider the big things I’m taking from the conference. I was already excited for DrupalCon Portland before leaving the conference!