brandondawson.org Drupal Website Developer and Consultant

Tips for Users New to Drupal

Editor's note: I came across a post on Reddit today where the user was asking for the usual newbie advice for how to go about getting up to speed in Drupal, especially with regards to Drush, Git, development environments, and getting support. I decided to supply my advice, intending to stick to the above topics, but quickly decided just to give a fuller, more comprehensive set of tips. I've duplicated them here for posterity, with some minor grammar/composition tweaks.

You want to use drush, period.

Drush is a shell command-line utility for common admin tasks. Not only is it useful in a 1:1 CLI kind of sense, where you just need to do some task or thing, and want to do it a bit quicker than the "click menu option, wait, set options" sense, but it's also part of what makes things like Aegir possible. Get it at drush.ws or drupal.org/project/drush.

If you set up your dev environment on Debian/Ubuntu, there's a package for drush; on other distros, you'll probably have to compile from source, but it's not hugely difficult.

You want to work with Git

That's what Drupal itself and most of the shops/agencies that work with it are moving to, or already have moved to.

There is no "One True Way" to handle the "dev-staging-production" conundrum

This is aimed more at smaller shops or corporate users; bigger shops and corporations will inevitably have firm, set procedures with regards to moving code from staging to production. But, at the low end of the scale, you can pretty much do what works best for the context at hand.

Note, however, that using Git helps you get things to where you're checking-in/checking-out the sites themselves, with or without databases, such that if a buggy contrib module messes up your site, you can easily restore.

Here's one suggested approach, if you Google around, you'll find others.

(My own method is a cheat: I just develop it in-place on my server by editing my hosts file to re-point the domain on my desktops, then repoint the actual domain at the actual registrar later. I've been working on transitioning to Git, though, for the aforementioned reasons.)

IRC is the Drupal watercooler, followed closely by Twitter and Drupal.org itself.

You'll find lots of actionable info, or at the very least, lots of good conversation, in the various Drupal IRC channels on Freenode. On IRC, start in #drupal-support, and start joining the other channels as you get your sea legs. On Twitter, sort your Drupal people into a single list so you can get at-a-glance Drupal conversation and info.

Getting Help: (Remember, Nearly Everyone's a Volunteer)

On IRC, and especially in #drupal-support, remember that folks are volunteering their time, and such people are always more open to helping those who try to help themselves first. When folks mistake you for a support leech, it's hard to get help sometimes, but if you demonstrate that you've tried to self-help, and are confused or looking at seemingly contradictory support/documentation assets, you'll generally find people more willing to be more helpful.

There are LOTS of video tutorial assets floating around, both free and paid. I found Mustard Seed Media's videos particularly useful, since they're short, focused, and free. (Bear in mind that all those videos are for D6. The MSM folks, like myself, haven't made the jump to D7 yet for the reasons below.)

Get Organized (Because sometimes Drupal.org really isn't.)

I recommend using delicious or some other bookmark manager, and being religious about bookmarking anything potentially useful, because you're going to be constantly running across little docs or modules that aren't pertinent "now", but will be later or in another context.

Get involved

Joining a working group is not only a good way to learn how the project works, but also a good way to get acquainted with Drupal people.

Drupal Camps or Drupalcons are going on virtually constantly all over the world, so start watching for one in your area. Similarly, there's Drupal user groups just about everywhere, too.

JOIN THE DRUPAL ASSOCIATION. It's cheap, and gets you immediate credibility inside and outside the project, plus you get some freebies/discounts and the warm-fuzzies of knowing you're supporting a serious, enterprise-grade project with genuine momentum, populated by some of the best folks I've met or worked with in the F/OSS world.

For non-Drupal folks reading this....I came to Drupal from other projects, and the Drupal community is, by far, the most professional, egalitarian, and welcoming I've experienced.

It still blows my mind sometimes just how functional and friendly the Drupal community is. In my case, I came for the CMS, since I'd decided to move on from less-powerful PHP platforms, and I wasn't keen on changing my whole server environment around to optimize for Python or Ruby.

But I stayed for the community. There's some great people and some real characters out there bleeding Drupal blue.

Environment/Servers/Distros/Profiles/Technical

Servers: There's a lot of folks that run Drupal on nginx and lighttp, but running it on Apache is best from a "getting support" perspective.

"Distros" or "Profiles": There's a lot of Drupal "distros" or "profiles", most notably the Acquia one, but from my experience, better you start out with plain vanilla, and switch to one of those, if appropriate, after you better understand the CMS.

(I've never seen a situation, aside from the "subscription" modules in Acquia Drupal, where you can't get the same functionality by manually putting things together, and relying on a distro/profile too early stunts your growth by encouraging blind reliance on things you'll want to understand later. I personally started with Acquia's distro, but have transitioned to plain-vanilla Drupal.)

As a sub-note to that last item, you may want to pull down a copy of Commons and play with it, too, because it'll help jump-start your understanding of how the various modules interact, and is something your clients might find useful in its own right.

Being technologically current:

One thing you'll find that's a bit different about Drupal is the way older releases are still supported long after being out of currency. There are still plenty of major production sites running on Drupal 4.7 and 5.X.

As it pertains to this exact moment, the transition from Drupal 6 to 7 is still very much ongoing in terms of the ecosphere of contribued modules. While there is, oftentimes, a D7 analogue for a D6 module you might be waiting for, there will be cases where a module that's a deal maker or breaker just hasn't been ported to 7 yet. So, I would personally counsel not being fussy about the 6/7 distinction at this exact juncture. Use whichever one you need to meet the use-case at hand.

For those whose biggest draw to D7 is the "more user friendly admin panel", there are admin themes for D6, such as Rubik and RootCandy to help pretty up the back end.

That said, I would counsel continuing to check your needs every month or two, because obviously, Drupal 7 is the future, and with Drupal 8 already in pipeline, you don't want to be running too far behind, as that will make migration a bigger pain down the road.

Theming/Customization:

Get to know some of the "base themes": popular ones include Zen, Fusion, and the new Omega, which is based in part on Fusion.

You'll find various video tutorials online, but be aware that the Omega docs are in-flux and you'll get better support on IRC. I personally prefer to code my own themes from scratch, and another great thing about Drupal is that it's much more standardized, making it much easier to compile lists of selectors and classes that can be ported from site to site and changed to suit the design.

But if you do agency work, or have to work on sites somebody else created, you'll run into those three base themes, and a few others, pretty often.

I hope this helps some new folks starting out.