Drupal and Front-End Web Developer

Early attempts at building with Drupal 7

Friday, June 24th, 2011

I’ve been “The Drupal Guy” since about August, conveniently they pushed out a new version in the last couple of months so there’s been some trials and tribulations in the transition process. Between August (2010) and March (2011) I launched three sites on Drupal 6. Right now I’m in the very tail end of launching my first client site and mid-stream on an internal application in Drupal 7. So it seemed like a decent time to start scratching down some thoughts on things.

The Good

The new admin interface where everything is done in the overlay is phenomenal. It really makes using Drupal as an end-user far more enjoyable. I think this is going to go a long way towards helping Drupal get taken more seriously (or, rather, more seriously than it’s already being taken lately).

There are a few modules that are Drupal 7 specific that make life in a client-based development role so much easier. Workbench and Workbench Moderate have been complete lifesavers on my current project. In Drupal 6 configuring content approval workflows was a convoluted and form-intensive process just to define a simple Draft > Review > Published process across user a couple of user roles. With Workbench Moderate it’s included out of the box and barely takes any configuration to get it running. Far better than needing to work through an entire chapter from Using Drupal to achieve the same thing across 3 different modules (but it is still a fantastic reference).

Also it’s hard not to sound overly gushy about Design Suite, but it’s wonderful for theming stuff. Yes, yes, I realize it’s been around since 6, but it’s brilliant, seriously. You should definitely check out Mortendk’s presentation from DrupalCon about it.

The Bad

The main thing that’s made it difficult to demonstrate Drupal to people who aren’t familiar with it (for me at least) has always been the need to rely on so many user-contributed Modules in the process of building out functionality for a site. In the end it keeps things super flexible, but as a “just go download it and try it for yourself” process it makes things kind of difficult. Once you get used to the nature of the contributed module world, though, everything is pretty good.

Until the modules you depend on disappear on you.

Sadly despite the long time that Drupal 7 was in development there are still a large number of modules that haven’t been ported over yet, or that have just been abandoned outright in favor of “new options” which don’t have actual releases yet (like the Nodewords to Meta Tags transition which in itself has led to a third module as an intermediate stopgap solution).

The current state of affairs unfortunately is just that for the moment if you’re going to build on 7 you’re going to be short on modules for some key tasks. For the key modules that you can find some sort of releases for most of them are going to be pre-stable releases (alpha, beta, dev, release candidates, etc.).

The Ugly

Sadly, there’s a few things out there right now that are just outright broken or running really weird. The Features module for example is displaying some highly troubling behaviors right now. Case in point: #1055460. Which points out that if you install a content type using a Features module then even after uninstalling that module (and even the entire Features system itself) your content types stay in the database flagged as belonging to a module so you can’t just delete them through the admin UI (you need to dip into the database to do it). Now, I’m sure some of you are saying “well if you missed something before just install again over the top of it” which sounds good in theory but if your content type has the same system name as an existing content type (say, the one from the last version of your Feature you installed) then everything collides and all your data fields disappear off the content type except for Title. Which is a little counter-productive.

So, what are you saying?

There’s a great potential in Drupal 7 right now, and (any day now) in the near future it’s definitely going to turn into a serious contender. But right now I’d still flag it as “for experimentation” for anything particularly complex. The flip side of that argument is “Use it for complex stuff by contributing back to those projects you need that are incomplete” thus helping the community overall, but for those of us in the (often rushed) budget+deadline=??? consulting arena that’s rarely in the cards.

Internally we’ve started to put our weight behind “We should be building on Drupal 7,” and on current projects it’s been within some tolerances for what the client (or our internal teams) have been willing to accept (some certain limits on functionality, sometimes some odd “cosmetic” error messages that don’t actually affect the performance of the site for end users, in a couple cases needing a pretty big chunk of additional RAM in order to function[1]), and for that I’ve been grateful. But for things that are complex that need to be done in a timeframe of the next few months, I’d probably still try to steer people towards 6 and then try to work out an upgrade/migration path in the future.

[1] Update 2011-08-12: Meant to come back and update this, it turns out the primary cause of a recurring “use all the RAM!” issues was really a conflict between the Token module and the Entity Token module (that’s part of the Entity API package). Point being: unless forced (for now, at least) don’t enable entity_token.

Need a developer?

Good news, I'm available! You can try taking a look at my resume to get a feel for the kinds of things I know how to do.

I'm reading...

Listening to...

Individual Member of the Drupal Association