Meet Drupal

Last month, I looked at the real-world problems of maintaining a traditional static HTML website and decided that the best solution for most users is to turn to a scalable CMS (content management system). So, this month, I’m going to look at how to implement Drupal (http://drupal.org), generally recognised as the most powerful open-source CMS. Get ready for a bumpy ride.

Meet Drupal

The first hurdle is the name Drupal; pronounced ‘droo-puhl’, it’s as bad a brand name as you could devise, suggestive of gentle decline at best, while its slogan ‘community plumbing’ just makes things worse. The origin of the name is hardly confidence-inspiring either. Drupal was created in 2000 by Dries Buytaert as a small news site with a built-in web-board so a group of University of Antwerp students could discuss which pub to go to. After graduating, they decided to put the site online and Dries registered the domain drop.org after mistyping his intended choice of dorp.org, Dutch for ‘village’. The Dutch for drop is ‘druppel’, which Anglicised becomes drupal.

A more serious hurdle is installation. Drupal, like all CMS solutions, is dynamically data driven, which needs dedicated server-side support and a reasonably advanced database setup – in stark contrast to the simplicity of posting static HTML pages. Ideally, you’ll need an Apache server supporting PHP 4 or 5, with MySQL, ModRewrite and local HTACCESS files (IIS and PostgreSQL are also supported to a lesser extent). You’ll need to be able to set up your own database, load the Drupal database schema and edit the settings.php file to connect to the new database (full details and links to OS specific guidelines at drupal.org).

If your eyes have already glazed over, don’t be embarrassed and don’t stop reading. If there was no way to get Drupal running without becoming a MySQL guru, it would be doomed to niche status, but there are alternatives. For dedicated Drupal hosting, turn to Bryght.com, which will set up everything for you and offers expert support. Or you can now do it yourself using any server provider that offers Fantastico support. This third-party script installer works with the popular cPanel site administration system and lets you install Drupal with a couple of clicks.

A host such as Bluehost offers Fantastico support along with 10GB of storage, 250GB of transfer and up to 50 MySQL databases for $8 a month, so there’s nothing to stop you. And if you prefer to dip your toe in the water first, visit opensourcecms.com, which lets you explore a clean installation that’s refreshed every two hours.

High on success with Drupal up and running, what to do next? With commercial software, the answer would be to read the manual or online help, but for constantly changing open-source software you visit the website – and prepare to crash back down to earth. It isn’t that the necessary information is missing or inaccessible; quite the reverse. Drupal’s various hypertext ‘handbooks’ cover everything you could possibly want to know (and PDF versions are available at www.puregin.org). But Drupal is a complex system with its own jargon – ‘blocks’, ‘nodes’, ‘modules’, ‘taxonomies’, ‘vocabularies’, ‘terms’, ‘snippets’ and more – and the handbooks have been written in ad hoc fashion by multiple authors who are mainly addressing expert users. The first-timer is in danger of drowning in a sea of information, but the following basic steps should get you started.
After installing, visit your new homepage and log on. As the first user, you’ll automatically be granted full administration rights to change whatever you want and set the permissions for all other users. Once logged in, the side menu presents just four links – My Account (where you change username, email address and password), Log Out, Create Content and Administer – which should all be self-explanatory. Kick off by creating some sample pages using the Create Content link.

You’ll be offered two choices: Page, for static content like an About page whose time of posting is irrelevant, and Story for everything else. Click on Story and you’ll be taken to a new page where your username and the current date and time have already been entered, and you can set publishing details such as whether the page needs to be approved before publication. Below this are the two main text-entry boxes where you enter the title and body copy. By default, the text you enter is treated as Filtered HTML, which automatically takes care of paragraph breaks and allows you to enter a few basic tags such as , and . Alternatively, as Administrator, you can choose full HTML or PHP input (the scripting language in which Drupal is written) for maximum design control. Once you’ve made your choices and entered your text, hit Preview to check the appearance of your pages and Submit to publish them.

It’s certainly simple, but your first reaction is likely to be, is this all there is? Now log out and visit your homepage and you’ll begin to see the benefits of CMS compared to traditional static HTML publishing. Each of the stories you just added automatically appears as a headline and cut-down teaser linked to the relevant page. Better still, at the bottom of each content page, there’s an Add Comment option – a massive advance that makes web publishing no longer a one-way street but instead an ongoing dialogue.

Drupal takes this fundamental shift to its logical conclusion, where users aren’t just limited to commenting on existing articles but can publish new ones. No longer does all content have to be funnelled through a reluctant and/or expensive webmaster. Instead, you can extend publishing rights to all members of your workgroup or to anyone who visits the site.

Of course, such power needs to be managed, and to do that click on the side menu’s Administer link, which opens up a hierarchical list of further associated links. First is the Access Control page, where you set permissions for Anonymous and Authenticated users and any other roles you specify. Other core Administer pages include Settings, where you specify the site name, page caching options and switch on Clean URLs to omit the search engine-unfriendly ‘?q=’ from URLs (which is why you need ModRewrite support). Using the Themes page, you can swap instantly between various preset designs and set up a list of primary and secondary links that will automatically appear in the banner area at the top of every page.

Static, theme-based links are fine for the main site section links, but what about links to each story page? Turn to the Administer | Blocks page and you can create and control ‘blocks’ that appear in columns at the left or right of each page. Surprisingly, there’s no option to automatically list the most recent stories, nor an obvious way to add links apart from manually in HTML, and the data-driven URLs such as ‘/node/3’ aren’t exactly user-friendly (‘node’ is Drupal’s catch-all term for customisable page types). And beware that if you create two blocks with blank descriptions, you’ll raise an SQL error.
The implementation of navigation blocks looks disappointing at first sight, but Drupal more than redeems the situation with its ‘taxonomy’ system for tagging, classifying, organising and accessing content. This is managed via the Administer | Categories page, where you set up either hierarchical or freeform lists, known as ‘vocabularies’, of organisational keywords known as ‘terms’ – for example, Holiday Destinations: Spain/Greece/Italy, Hotel Type: Luxury/Romantic/Family. These lists are then automatically presented for selection whenever users add content, so that each page is tagged as it’s created. Each term that’s been applied to a page then appears in a list of hyperlinks under its main heading. Click on one and you’ll be whisked to an automatically generated homepage for that term, which lists teasers for all the nodes that have been tagged with it.

Drupal’s unique taxonomy system is immensely powerful. It enables end users to intuitively drill down directly to those areas they’re interested in and makes setting up traditional sidebar menu blocks much easier. It’s great for the publisher too, as once set up taxonomy-tagging creates multiple routes through their content automatically – this is what hypertext should be about. Drupal’s taxonomy also provides the necessary organisational framework for building more traditional sidebar links. You can automatically list recently added nodes for any given term or group by inserting a PHP-based MySQL database query into a block. Insert a what? Again, that assumption that even new users are already SQL experts. Don’t panic; you should be able to achieve what you want by customising one of the many ‘PHP snippets’ that existing users have posted to the Drupal site.

With blocks, categories and snippets, the main building blocks are in place to produce a well-organised, scalable, accessible, centrally controlled site complete with community-based features such as commenting and distributed authoring. However, there are still many things on the wish list when it comes to basic site organisation, like some way to add and control hierarchical menus and meaningful URLs. In fact, all of these functions and more already exist in Drupal, but you need to find them and unlock them.

To do this, visit the Administer | Modules page, where you’ll see a list of those Drupal components or ‘modules’ we’ve already seen in action – Story, Page, Comments, Blocks, Taxonomy – plus more modules that are switched off by default. Simply tick their checkboxes and you can instantly enable new node types such as Book, Blog, Forum and Poll plus other modules that manage features such as Archive, Search and Statistics. Most impressive has to be the Aggregator module, which automatically aggregates incoming RSS feeds.

The two most immediately useful optional modules are Menu and Path. Switch on Menu and you can add and edit your own new menu blocks, complete with collapsible lists of sub-items. Switch on Path and you can provide human and search engine-friendly URLs such as ‘/Spain/Alicante’ rather than ‘/taxonomy/term/8′. These keyword-based URLs not only aid site usability but also boost your pages’ Google rankings and so traffic. Menu and Path also offer a good example of modules that work together to be more than the sum of their parts. By creating directory-based URL aliases, you can then use wildcards to target your menu blocks and give each effective section of your site its own customised menu.

Switching on these optional modules takes your site up to another level, but you’ll soon start wishing Drupal could do even more. During site setup, for example, it’s disappointing that you’re still expected to laboriously add individual aliases and menu items by hand.
Moving beyond organisation and navigation, there are other crucial areas of functionality that still have to be tackled: how to enable contributors to format their copy and to include images; how to create and style your own customised node types; how to move beyond the basic layout; how to take more control of teasers and how these are presented; how to handle events; how to enable form-based feedback; how to tackle spam posting; and so on. The wish list seems almost endless, and the chance of getting your site running the way you want virtually nil.

But this is where the true beauty of open-source development is revealed and where Drupal’s developer-friendly system of modules, APIs and hooks – that ‘community plumbing’ – comes into its own. If you need a particular feature, the chances are someone else has wanted it too, developed a solution and donated the resulting module back to the Drupal community. Look at drupal.org, where you’ll find lists of these ‘contributed modules’, divided into tabs for each recent release of Drupal.

The number of contributed modules available is mind-boggling, with more than 250 available for the current 4.6 release at the time of writing. They address all the omissions mentioned above, in most cases comprehensively. Pathauto automatically generates URL aliases; Taxonomy Block, Taxonomy Context, Taxonomy Menu and others automatically generate category-based links; TinyMCE, BBCode or FCKEditor format text during content creation; Images and Img_Assist handle images; FlexiNode creates custom nodes; FlexiBlock and Dashboard produce custom layouts; Excerpt, Front Page and Views offer closer control over teasers and listings; Event handles time-based data; and there are Feedback, Mailhandler, Spam, Simplenews, Voting and literally hundreds of others.

When I first saw this list of free contributed modules, it felt like all my Christmases had come at once, and that’s after a decade of reviewing professional design software. That’s still my main feeling (along with humble gratitude to all the contributors), but Boxing Day reality dawns and brings major indigestion and a series of headaches. The obvious first stumbling block is the sheer amount of functionality on offer; so much so that it’s virtually impossible to take it all in.

As you begin playing with all these new toys, further problems appear. Most of the developers seem to have forgotten to document their modules, as if they were self-evident. They certainly aren’t, and getting to grips can take anything from a few hours to a lifetime. Moreover, getting each module up and running isn’t necessarily plain sailing. Most just involve unzipping and FTPing the result to your site’s Modules directory, but some require adding new tables to your database. This is another hurdle for the beginner to overcome, and a bit of Fantastico-style magic for painless script-based installation would be welcome. However, if you have access to PHPAdmin or have installed the Database Administration module, it’s usually just a question of running the provided MySQL file.

Once you’ve installed your modules, there’s another potential problem: they don’t necessarily play well together. For example, to get automatic URLs and an automatic taxonomy-based menu system, I installed Pathauto and Taxonomy Context, only to find that the automatically generated menu used the ugly node-based URLs rather than their Google-friendly aliases. And there are plenty of similar but more serious clashes.
An even more central compatibility issue is the imminent arrival of a new version of the Drupal core itself. To work with the new 4.7 release, every contributed module will have to be updated or else fall by the wayside. I have to admit that once the significance of these compatibility issues dawned, I began to have serious doubts about Drupal’s fundamental viability as a platform. It’s like trying to build a model railway with sections of track from different manufacturers and with the underlying gauge changing every year or so.

Integration and upgrading remain important concerns, but on reflection I’ve decided they’re not insurmountable. At the time of writing, Drupal 4.7 is still in beta, but there are already more than a hundred 4.7-compatible contributed modules available on the site, and that’s more than enough to be getting on with. Moreover, as these early-adopter modules are clearly being actively developed, this should mean they’re good bets for release 4.8 and onwards. By the time the version after that is released, I hope to have picked up the necessary PHP and MySQL skills to upgrade modules myself where necessary and to enhance them where possible. After all, it’s this open-source ethic, the combination of Drupal’s community-plumbing architecture and a massive amount of communal effort – that’s the ultimate secret of Drupal’s success.

Getting to grips with Drupal has certainly been an emotional rollercoaster, and in some ways I’m at the lowest point: over the minor hurdles but fully aware of how much needs to be done before any site can go live. On the other hand, I’m more excited than ever about the heights I can achieve with Drupal and the very different experiences it can provide for both site visitors and webmasters. Yes, its name is dreadful, but I’m confident you’re going to be hearing a lot more about Drupal in the years to come.

Disclaimer: Some pages on this site may include an affiliate link. This does not effect our editorial in any way.