Saturday, 20 June 2009

Making Drupal Your Bitch

I suspect no-one will read this post entirely unless they get here from some random Google search looking for help with Drupal. A shame, to be sure, but not unlike the thousands of lines of beautiful code poetry I've written no one will look at. Probably not unlike the rest of these post either. Still, I'mma gonna write it and call it the first page of my Drupal tutorials.

Now it's no secret that I'm building a CMS from scratch. Heck, some of you are even using the first production version of it! Well, clients have demanded feature sets faster than I can build them in the normal course of development, so in an effort to work smarter, not harder, for those few clients who wanted the moon for cheese, I turned to an off-the-shelf CMS, Drupal. IMHO, it's the best thing out there, but it's still incredibly bloated and needlessly complicated. It pains me to use Drupal for those reasons, but that said, it's still the best thing out there - for now.

So once you get Drupal installed you'll need to enable the modules you want. Don't bother configuring your site yet; we're not done installing. Most of the core modules are useful, but only enable the ones you are actually using - the more you have, the slower your site is. With today's technology even. Warned you the code was bloated and inefficient!

Now you'll need to install a whole host of 3rd party add-on modules (and a template if you're not going to build one). Right, there's a lot that Drupal needs it don't come with. Everyone has their own list of must-have modules. My essential list (based on extensive meddling) looks like:
  • Administration menu 6.x-1.4
    You want this dropdown menu; should be core.
  • Image 6.x-1.0-alpha4
    Can't upload or otherwise use images without this.
  • ImageAPI 6.x-1.6 ImageAPI supporting multiple toolkits.
    Ditto
  • FCKeditor 6.x-1.3
    A WYSIWYG editor instead of plain text fields.
  • Image Browser 6.x-1.0-beta1
    An image browser/manager for use with FCK
  • Meta tags 6.x-1.0
    Why aren't keywords core?
  • Views 6.x-2.6
    Haven't used this powerful module yet, but modules above require it.
Getting all these modules installed is not that difficult, but FCK and the image browser are a bit tricky. Go to their homepages and read carefully. FCK requires two downloads/installs! Right, the one you get from Drupal.org is only 1/2 of it.

Oh yeah, if you're going to have clients (and not just you using the system) you'll definitely want to configure Drupal to serve multiple sites from one install directory. Read the manual carefully; it's not hard. In fact, creating a new site is one of the nicest features about Drupal, even though it still requires a command-line interface and a few Unix commands. I felt a wave of smugness pass over me since my system is all web-based. I let it go, Smug is one of the leading sources of air pollution.

Time to setup your CSS. To do this, you need to create what Drupal calls a theme. You'll find no end of schizophrenic (manual) pages about how best to do this. Take my advice. Use the blank slate template I wrote. It's simplified beyond Stark. However, if you're HTML-based instead of PHP-based you can use the Stark theme; it's just got a bit more divs than it ought to have, but it's no big deal; just copy it, and then edit as you wish.

Okay, so now you got a CMS enabled with (most of) the features you want/need. Now what?

Well one would hope that the entire CMS is customisable via an online interface to control not only what modules are active, but what data each module outputs along with the accompanying CSS to handle the layout. Unfortunately, this process only works for the simplest of modules, and it's never a customizable as you'll want. Breadcrumbs are a great example. You can't just click a checkbox and tell Drupal not to print the darn things. Instead, you have to edit code. Don't even get me started on the User Login box.

But since we don't want to edit the actual Drupal source (cause we'll lose it on system updates/upgrades) we instead have to copy the php file (called a template) that Drupal uses to figure out what to display. Hmm... we might have to redo changes anyway when the new templates change from the old. You'll find in my template a file called "page.tpl.php" which gets called on every page draw. If you were to make it blank, all your pages would be blank. Seems easy peasy, but finding the module's source code can be a pain until you get intimate with Drupal.

Now the templating scheme is fairly clever - you can be as specific or as general as you want, and Drupal follows rules for which template files it uses based on the content. It would be nice if each module had a template, but alas, that would make too much sense (and too much facism).

To override some types of Drupal output, you need to figure out which PHP funciton in the Drupal source code is outputting the content, and then override that function and figure out where to put it. Not an easy task at first, especially since all you want to do at this point is to build your website. This was supposed to be easy, right?

But you're a superstar, you've gotten this far, the rest is a cakewalk right? We just edit the template to layout our <divs> and then edit our custom CSS to take care of the display. In theory. You're going to need to be quite the expert if you expect to do any serious CSS. Why? Cause Drupal litters the CSS heirarchy with all kinds of unnecessary definitions that are hidden, until you're wondering why for example, your <li> elements, which you've explicitly and clearly marked up in the CSS to not have bullets, shows bullets anyway (but only on non-IE browsers). Oh yeah, don't forget to override the background with "background:transparent" or you're going to get weird images appearing in your lists too. See what I mean? Oh yeah, be sure to have a "border: 0px;" command for any tables you want unless you like having borders. Who does that? Ya gotta be familiar with just about all of CSS2 and even then, CSS that works in isolation will often fail when inside Drupal and you'll have to figure out exactly what (and where) Drupal is mucking up the CSS with non-standard or extra inherited definitions (which IE doesn't seem to respect).

Are we having fun yet?

Well don't forget, Drupal 5 did all of this differently from Drupal 6, as no doubt Drupal 7 does too, so just because you become an expert, don't worry about the joy of learning... you'll have to do all this over again when/if you upgrade/downgrade! Whoopee!!!

PS - about the cover image: if that kind of thing excites you, try starting here.

No comments:

Post a Comment