drupal modules

Skip to video and slides

A couple weeks ago I put out a blog to garner feedback on why Drupal kicks serious a**, and a big thanks to everyone who responded. I integrated a number of the comments with my own personal experience with Drupal and presented my talk last week to a diverse group of 20 or so web tech people in the local Boise Idaho area. Judging from the audience participation, I think the presentation went really well. I recorded the talk (from two different camera angles, no less!) and am posting the video and slides for folks that are curious about what they missed, or who are interested in giving a similar talk themselves.

I did a little research before hand about how Drupal compares to popular CMSes like Joomla, Plone, Wordpress, ExpressionEngine, and SharePoint. The talk was also directed in many ways to audience members who have rolled their own CMS, because that was my experience coming into Drupal and I found that Drupal solved many of the problems I was attempting to solve myself, but in much more elegant ways.

Drupal kicking butt - Video and slideshow

The format of the talk was "10 ways Drupal (might) kick your CMS's a**", and here are the 10 things about Drupal that stand out to me as particularly steller:

#1 - The Drupal Community

The community is a big part of what keeps me involved in Drupal at the level I am. I helped found and participate in a local Drupal users group, which provides important face-to-face time with other people using the Drupal, and keeps us all abreast of important news in the project. I also talk about regional conferences and Drupalcon, IRC, and leadership in the community.

#2 - Central Module Repository

Drupal keeps all of its modules in one place, unlike many other CMSes. This has many benefits, and has helped to keep significant licensing problems to be an issue in the community. Also, a standard module release process allows both developers and administrators to have a clear path forward with module upgrades and choosing the correct module version for the Drupal version they use

#3 - Drupal is a Framework

For developers, Drupal does a lot of heavy lifting and really lets you get plugged virtually anywhere in the platform. The module structure encourages good coding practices and good organization.

#4 - Drupal is Mature

Drupal has been actively developed for 8 years, and lots of big web sites are using it, like the White House, The Onion, Fast Company, BMG Records, NASA, Warner Brothers and Yahoo Research. Even if you don't understand the nuances of security and scalability, you can point to hear examples of how Drupal must provide a solid framework for both.

#5 - Flexible Data Structures

Drupal allows you to create flexible content, much like Access or Filemaker, and even creates full CRUD (Add, edit, view and delete forms) on the fly. So, storing custom content is easy, and doesn't require any programming or touching the database. (video includes demo)

#6 - Flexible Content Feed Output

Once you have content, you have many options for how you want to output the data. You can pass content filters via the URL or even expose filters to users so they can narrow down content based on whatever criteria you specify. The ability to generate these lists of data via configuration without touching queries or code can be a powerful administrative tool.

#7 - Flexible Path Aliasing

In Drupal, you can specify how you want a path to look based on virtually any information in your content, including title, date, or custom fields. Drupal can handle redirecting duplicate URLs (also called aliases) to a single URL with a 301 redirect to prevent a duplicate content filter in search engines.

#8 - Multi-Language Support

Including another language is trivial, and you can even override content within the same language. There's community infrastructure to support translators even if they don't know how to use, install or develop in Drupal.

#9 - Making Forms is a Breeze

Creating forms in Drupal is as easy as creating content types, and can be done without any programming. If you do need to program a form, however, there is a powerful API which will allow you to generate a secure, robust form in just a couple of steps. There is also a nice utility for generating module configuration forms.

#10 - A Bunch of Other Stuff

Including distributions for intranets and social aggregation, cross-database compatibility, an active usability team, hierarchical taxonomy, a powerful theme layer and AJAX framework.

Post-presentation discussion

During and after the presentation, there were a lot of great questions and discussion about topics like:

  • How does Drupal store content types?
  • Can Drupal work with obscure databases like BDB?
  • How do you create a wiki in Drupal?
  • How much does Drupal break from one version to the next?
  • How difficult is the upgrade process from one Drupal version to the next?
  • How much of this stuff is handled by core Drupal, and how much by contributed modules?
  • What versions of MySQL and PHP are the different Drupal versions compatible with?
  • How many people non-developers use Drupal?
  • Discussion on ecommerce solutions for Drupal

One thing that's really nice about working on your own Drupal projects is that you get to share what you're working on (no NDAs, woot!). This particular project (Build a Module.com) is a video tutorial site for newer Drupal developers. For a while, I had a single product offering, but feedback made me realize that people like options. So, I decided to to offer single video purchases as well as 'collections,' or groups of videos bundled up into a single product. I also needed to make sure that customers had the right permissions set on files depending on their purchases.

Here's a video outlining the solution I came up with. Scroll down below the video for further details.

About the flow

I have 3 node types:

  1. Videos - Contains description and video file in a file field
  2. Single Video Product - Is an Ubercart product with a node reference CCK field pointing to a single video
  3. Collection Product - Another Ubercart product, but this one has a node reference CCK field that points to a number of videos

I didn't realize that a node reference field could point to multiple nodes before a fellow Drupalista pointed it out to me. Eesh! I really could have used that info a year ago.

So here's the flow:

  1. A user adds a Single Video Product or a collection to their cart
  2. They check out and complete the purchase
  3. They visit a video page
  4. A custom function checks against their orders to see if they have access to the video. If they do, they're in.

The function used in step 4 uses several queries to determine access. The queries check for the following:

  1. Is the product free? If so, show the video.
  2. Has the user purchased a product that includes the video file that this Single Video Product type points to?
  3. Same check for a Collection Product type
  4. If there is no product for the video, then give access (some videos, like the intro video, don't have an associated product)

In the hook_file_download, the same function is called, but I first have to figure out what node the file belongs to. In Drupal 6, hook_file_download only supplies you with the name of the file. No node associations or anything, so you have to connect the dots with your own query. I think the reasoning is that a file can belong to multiple nodes, but since my workflow doesn't allow that, it's not an issue.

There are some good things about this approach, such as when files change in the nodes (i.e. you upload a video with corrections), even though there is a new file name, the node association will remain the same and access will be granted.

For a while I was using a module called File Access, which allows you to set granular permissions for each file based on user or role, but because I would have to build a connector action between a purchase and the access, and then respond when new files are uploaded, I figured I would keep it simpler and just cross-reference the orders instead. The downside is that if my products change, so will access. Also, using File Access would enable access based on field, rather than on node. So, if I have two different versions of a file on the node (iPod version and full-size) and wanted to sell them separately, I would need something more complex.

Part of the reason I'm putting this info out there is to get feedback and see if a module that handles this type of access and setup would be a welcome addition to Drupal contrib, so feel free to drop me some feedback below.

200908131139.jpgIt recently came to my attention that there are some gaps in my conceptualization of Drupal security. I was fortunate enough to have this pointed out to me by the Drupal Security Team, and not by a DOS, CSFR, SQL injection or XSS attack. After publicly bemoaning the mild lashing I received, four members of the Drupal community suggested I read Cracking Drupal. One of them even sent me a copy. No other book was even mentioned, which says to me that - considering how recently it was released - the book fills a void of knowledge that was seriously aching for coverage, and fills it well.

Over years of developing, I've become familiar with the various vulnerabilities that make their way into code, but I've never felt like I could build a complete defense. My knowledge has been piecemeal, drawing from documentation, books, interesting conversations and other people's code. In my case, Cracking Drupal did a fantastic job of gluing these pieces together into a comprehensive frame of mind.

What becomes clear very quickly in Cracking Drupal is that Drupal is quite a wily beast that gives developers real incentive to learn security. There are few functions in Drupal whose exclusive purpose is security, and Greg makes it clear that learning how to secure your site has definite side benefits: "When developers learn and use the API, they are not only safer but more effective and more efficient." When you learn how to use different aspects of the Drupal API (forms, translations, helper functions, theming) you gain bits of security as a bonus. If you set out to learn Drupal security, you'll come out the other end with a pretty solid grasp of Drupal APIs. Either way, it's a win.

Cracking Drupal is surprisingly brief. In 134 pages, Greg covers a lot of ground including:

  • An overview of the different types of attacks one is likely to encounter, from physical to social
  • Most (if not all) aspects of the Drupal API that have security implications
  • Coverage of security-related contributed modules
  • An introduction to the Drupal Security Team
  • Demonstrations of exploiting common weaknesses in Drupal modules and how to fix them

An interesting choice is made in Cracking Drupal to keep a somber atmosphere around the subject matter. In almost any other context, this would be an immediate turn-off. I appreciate humor and optimism to drive my enthusiasm when reading. In contrast with other instructional books which end a chapter with a "go for it, get things done!" message, this book ends chapters with lines like "This paranoid perspective is a good one to maintain as you write, review, and implement features on your site." and "Remember that it is nearly impossible to fully protect yourself from a dedicated and persistent attack." and "If nothing else, I hope this chapter has scared you a bit about the realities of just how easy it is to exploit insecure code and sites".

In a book covering attacks that can result in a very serious loss of time and money, this lack of optimism is probably a good thing. And the final chapter, "Un-cracking Drupal" does leave the reader with the sense that something can be done. It's difficult work, but it's doable. Ultimately, I think the book drives home the fact that the most effective way to make a module or theme secure is to do it right from the start.

The title chapter of Cracking Drupal was probably the most lively and hands-on part of the book. I came out of it feeling like I could really enjoy exploiting vulnerabilities for the greater good. Because of this reaction, I think it would have been a good candidate for a first chapter to really whet people's appetites.

Overall, I think Cracking Drupal does a tremendous service to the community by pulling together the most important aspects of Drupal Security into one solid, compact document. While I came into the book having already been introduced to many of the concepts, it filled in a few gaps, and made the subject matter finite and approachable (albeit a little scary). I suspect this book will serve well as a guide and quick reference as I dive into identifying and patching up vulnerabilities in the modules I maintain.

A couple things I learned

While the greatest benefit to this book was the broad, sweeping overview of security, there were a few additional gems that will come in handy later on:

  • There's a lot more to hook_menu() than I was aware of. Good coverage of examples on p.55
  • I didn't realize that you had to exit after using drupal_access_denied(). p.59
  • Ah, db_placeholders() - a useful function for passing a number of variables to db_query() p.65
  • I had no idea there was such a robust node access API. Wow!

Notes in the margin

Below are a few unorganized comments that constitute my wish-list for future versions and complements to the author:

  • Good quote regarding the definition of security: "For this book I’ll define site security as follows: A site is secure if private data is kept private, the site cannot be forced offline or into a degraded mode by a remote visitor, the site resources are used only for their intended purposes, and the site content can be edited only by appropriate users."
  • I would have liked to see more AJAX security strategies and techniques covered.
  • I liked all the Drupal 7 references, gives a good feel as to the direction of things
  • I was surprised that there were not more brutal admonitions about hacking core, but suspect that's because they represent much fewer vulnerabilities than badly designed contrib.
  • I was happy to see some coverage of CVS and DRUSH, namely using CVS to keep code up-to-date
  • Nice coverage of security-related modules starting around p.41
  • A brief mention is made that using mixed-mode SSL is pretty pointless. This is a big deal, I wish it had gotten further coverage.
  • Being more of an optimist, I appreciated this particular phrase: " Every day there are more and more techniques beingdeveloped to attack sites, but every day there are also Drupal users reviewing code and providing new modules and enhancements to core to keep your site safe." Ahh, a glimmer of hope!
  • Would have liked to see more coverage on the use of form tokens. If one must step outside of the forms api, this could be very important
  • I liked that theme safety was covered, and thought the take on it was interesting: Make the theme secure by giving themers no reason to make stupid mistakes.
  • Since the 'Vulnerable' module was patched up in the end, maybe it should actually be named to indicate that it's meant to be a useful module. That would feel more like a practical example.

Skip to the video demo

Open the Drupal.org project page for Query-Based Views

One of my first Drupal modules ever was Ajax Table, which gave some rich tools to users who would would normally circumvent Views to create a report or feed by constructing it programmatically. The problem being solved was "what does one do when they need to build a report starting with a query?" The Views answer is to expose everything you need to Views through modular hooks. This is an awesome long-term solution because, once your tables and custom output functions are exposed to Views, they can be used by any other view, and you can combine stuff in really novel, nifty ways.

However, a lot of people don't have the time or expertise to do that. They need to start with a query, and they would normally create a custom function, run the query directly and then generate the output programmatically. I think that there will always be use cases for this, and even if the same report could be created in Views, some people will do it this way simply because it's faster for what they need. Ajax Table was a utility module for these use cases. By running a query through a helper function and passing a couple parameters, users could generate ajax-reloading, searchable, sortable reports with very minimal work. It was handy, and I used it all the time. I still use it for my internal time-keeping / invoicing / proposal generating system.

The functionality was useful enough that I built out a second iteration called Query-Based Views, this one using Drupal configuration instead of straight-up code. I demo-ed the module to my local Drupal User Group, and got some positive responses regarding of the ajax functionality, rapid development and in-line editing. However, the general consensus was that the functionality would make a much greater impact if contributed as a Views plug-in, or as patches to Views itself.

So I shelved the project, thinking that until I knew enough about Views to integrate this, it would be better not to fork efforts.

Then a few days ago it struck me that maybe I should ask Earl Miles (merlinofchaos), the developer of Views, if the idea of starting with a query was actually Views-compatible. I was thinking that maybe the Views query builder was just an element of the UI that could be replaced out with something supplying a raw query. He said that it really wasn't. Too much of the power of Views is derived from abstracting out the query building process into the UI that's there.

That means there's actually room for this type of module. It's true that a lot of functionality is duplicated, but Query-Based Views runs on a different paradigm that's incompatable with Views, so it's reasonable for it to do so. Some specific bits like in-line editing could be abstracted more to be able to work with Views and Q-Views, but as a first effort, I think this module should fit the bill.

So I spent a couple of days porting the Drupal 5 version of Q-Views to Drupal 6, fixed a bunch of bugs and am releasing it as an alpha. The bulk of the code is written by the Chris Shattuck of yesteryear, who was not as well versed in Drupal ways, so if the module is useful enough a code rewrite is in order for a non-alpha / beta release. But as it stands, it's functional and ready to roll.

Video Demo

Q-Views has a lot of functionality, so this is a longer video (20 min). Feel free to skip around, though.

At DrupalCamp Colorado, Stephanie Pakrul and Jay Wolf spoke about the new module Skinr and how it relates to Panels for theming, and I left the session with a few pleasant goosebumps. For the uninitiated - as I was - Skinr is a module sponsored by Gravitek Labs which allows themes to expose style presets to blocks. The upshot is that once you create a nice style, you can allow users to apply the styles to virtually any area of a page with a couple clicks. This effectively incorporates several principles that have up until this point been applicable mostly to modules, like reuse of code, config-based changes and ... well ... general modularity. I could immediately see that this was an idea with really big potential. Even in its infancy, the Skinr module can do some pretty neat stuff.

Along these lines, Top Notch Themes did a pre-release of their new Fusion theme which incorporates Skinr functionality. The folks at TNT have really been quite genius with their positioning of the Fusion theme, and I think they have really wrapped their minds around where theming is headed over the next couple of years. Their base message is that Fusion is the only theme you'll ever need - a tall order for any one theme, and an interesting proposition. The theme is grid-based and comes in fluid or fixed 960 variety, and a plethora of styles are made available through Skinr for layout and look and feel.

The main purpose of the Fusion base theme, however, is not to provide a look and feel, but rather to supply a solid foundation for sub-themes and - get this - pluggable, extensible style packs (my term). So, instead of having to cut and paste stylesheets and images from one theme to another, instead you paste these style packs in. I really like this idea. Fusion will ship - I believe - with an example sub-theme that looks pretty decent out of the box. Fusion also exposes some nice configuration options you don't see in a lot of themes, like font settings and setting the default text in several areas of the site.

Fusion will be released into Drupal contrib, and then TNT will be selling sub-themes on their site. The fact that they will be moving their themes to Fusion says something really important about Skinr and Fusion. If a leading Drupal company that needs the support of the community to survive is throwing their weight behind these technologies, it's a good indication that it's something to watch very carefully.

I think the move to create a one-size-fits-all, highly modular theme is inevitable, and comes at an excellent time considering how important it is to the Drupal community to attract more designers and themers. I also think it's a daunting task that can be accelerated if there is a model to drive the development commercially, alongside community development, so I appreciate TNT's and Gravitek's roles in this venture. The ability to create 'style packs' (again, my term), is another way that themers can contribute, and Fusion / Skinr will allow designers to do an awful lot of design without worrying about theming. That's pretty powerful stuff.

I'm really looking forward to seeing how this moves forward. TNT and Gravitek have their work cut out for them, but I hope that quickly it will become a minor movement to change the way we look at theming from here on out.

Skip to the video

To celebrate by recent release from employment, I spent several days busting my butt to put the sexy back in administration. Namely, I updated the Drupal Navigate module to include some new features, and to fix some long-standing bugs that had been making administrators feel less than sexy for the last several months.


For the uninitiated, Navigate is an administration module that works a little like Administration Menu. It loads a sidebar with widgets which allow users to search the menu, nodes or users, construct favorite lists, and load up expandable / collapsable menus. It works really well for clients who aren't used to Drupal. The newest release allows admins to set default widget sets, and adjust user sets. You can also theme it (a funky lemon theme is included as an example).

There's a video demo below, but here's a quick list of improvements made in this release:

  • Made snappier through quicker transitions and fewer ajax calls
  • Added ability to manage default widget sets for users and user roles (all ajax, btw)
  • Made theming Navigate really easy
  • Fixed compatibility issues with Administration Menu
  • Added keyboard shortcuts
  • Added XHTML compliance
  • Added import / export ability for Favorites and for entire widget sets, so you can quickly deploy a set from one site to another
  • Added 'customize' permission, to keep *certain* users from messing up their own sets
  • Added ability to search users
  • Squashed some bugs
  • Re-factored lots of code to be more Drupal-esque
  • Made some minor layout adjustments

I'm hoping to put in some work to help with the current administration tools in D7, but before that, I needed to grease my wheels a bit with some contrib work to to anchor some jQuery techniques I'd learned, and re-familiarize myself with D6. It feels good getting so much done so fast. You can do that with contrib work, but it's hard to be that productive in core Drupal. Things just move at a different pace there. Now that I've gotten a bit out of my system, I think I can crack down a bit and start seeing what I can do for core.

And here's the demo video to celebrate Issue Queue Zero (at least for the D6 version):

Syndicate content