Being a WordPress devotee, the shocking thing about Drupal is that it doesn’t have a backup utility built into the core system. Any content management system that relies upon a back-end database should provide a way to back that database up regularly.

Shockingly, Drupal doesn’t. But it does have a dedicated community, and there are a number of options out there for backing up your database. The one which I’ve been using lately is the Backup/Migrate module.

This module makes it easy to do both on-demand and scheduled backups of your Drupal installation. With the on-demand backups, you can download them to your computer immediately. The scheduled backup saves the files to your webserver for downloading at a later date, and you can specify how regularly to back up and how many backup files to keep, so it’ll do the housekeeping for you as well.

Because Drupal uses relative hyperlinks by default, you can download an entire live website to a local server and use it to test themes, modules and Drupal upgrades without affecting the live environment.

This is more useful than you’d believe. I recently upgraded a Drupal site I manage, and the upgrade failed. I couldn’t get access to the site and thought it was ruined. However, I installed Drupal 5.1 on a local webserver and restored the database backup to that. I then upgraded that installation to Drupal 6.2 successfully. With a completely recovered and upgraded database, I was able to put this on the live webserver. We were up and running again relatively quickly.

I decided after that to test all my Drupal upgrades on a local server before doing the upgrade on a live website!

What’s missing (in my opinion) is a way to back up the uploaded files, themes and modules that each Drupal site contains. I want to look at some way to set up FTP synchronisation to back up site files on a scheduled basis.

If you’ve got any suggestions, please share!

This is a redesign of the blog, which runs on Drupal 6 and features a blog and photo galleries. It’s not the first Drupal-based theme I’ve ever created, but certainly the one I’m happiest with.

If you want to know a little bit more about the process behind designing the site, I wrote about my aims for the site, then followed up today with some notes on why I made certain design decisions.

My feeling is that the design is quite unique and a good starting point for establishing an identifiable presence on the Internet. Here’s a screen-shot:

I’ll have a bit more information on this design in the portfolio in the neat future.

Drupal 6 offers built-in actions that can be performed whenever something happens on your site. Typically, you want to use this to get an alert when someone publishes content on the site, or a new user signs up.

You might even want to mimic WordPress and get an email alert every time someone leaves a comment on the site. I’m going to show you how to set this up for your site.

Defining Triggers and Actions

First, let’s take a look at what triggers and actions actually are. A trigger is an event which will happen on your site. Triggers that I can see on my site are Comments, Content, Cron, Taxonomy and Users.

If you look at the available triggers for Comments, you’ll see various trigger types. The one we’re interested in is “After saving a new comment”.

Before you can activate a trigger, you need to specify an Action. This is the action you want to happen each time a trigger is ..er.. triggered. You can do a number of things with actions, such as redirect users to a URL or give them a message on the page. However, we’re mostly interested in the Send Email action.

Step By Step Instructions

OK. So let’s set up a simple action and trigger combo to send us an email each time a comment is left on our Drupal site.

• Before you start: Make sure you’ve got the trigger module activated. Browse to Administer -> Site Building -> Modules and check that Trigger is enabled. If not, switch it on, obviously!
• Now, let’s set up our action - browse to Administer -> Site Configuration -> Actions. Drop down the Make a new advanced action box and select Send e-mail. Click Create.
• Set up your alert email with an easy to recognise Description and Subject - I used “New Comment on [Sitename]” for mine. Enter the email address of the person who’s supposed to receive the alert (probably you) and then enter a short message - you should see some variables underneath the text field showing variables you can use.
• Save your changes et voila, your action is configured. Now to attach it to a trigger…
• Browse to the Trigger page in Adminster -> Site Building -> Triggers. Click the Comments tab and drop down the list underneath After saving a new comment. You should see your email in the list - select it and click Assign.
• Job done - your action has been configured.

Don’t Forget To Test

You didn’t think we were finished yet, did you? Now you need to test that the triggers are working correctly.

Just to approach this as a regular site visitor, log out of your Drupal site. Or, if you’re smart like me, just fire up another web browser where you’re not logged on to the site (that way, you can still use the admin part of Drupal in your main browser and test the average user experience in the other).

Simply visit any blog post on the site (or any node that allows comments) and leave a comment on that post. Now, head on over to your email inbox and wait for that alert to arrive. Mine arrived in just a couple of minutes.

Developers Dries Buytaert and Benjamin Schrauwen have announced the release of an all new anti-comment spam system called Mollom. Since Dries is the mastermind behind the community-building CMS Drupal, Mollom seems to have a wider remit than you might find with comparable systems like Akismet.

They’re not just going after the usual automated comment spam that most anti-spam focuses on. Mollom allows you to look at the entire spectrum of user contributed content and analyse it against a number of factors: spam, offensive/inflammatory content, aggressive content, etc.

I’ve installed the Mollom module on my personal Drupal website and I’m thinking seriously about installing it on a couple of other Drupal sites that I’m working on that are getting hit heavily with user account spam*. There’s an option in the config page for Mollom that indicates it can watch out for spam user accounts, which will be a godsend for anyone who runs an open community.

What Does Mollom Protect?

Well, looking at the configuration page (in Drupal 6), you can protect all your contact and comment forms, user registration and password request forms and input forms for any node type, such as blogs, pages, polls and stories. That’s pretty cool and covers all the possible ways a user (or a spam-bot) might try to enter spam on your site.

Effectiveness?

It’s too early to say. Give it a couple of days and we’ll see. My personal blog isn’t very heavily trafficked, so I may install it on another community site I’m working on to see how it handles user account and content spam.

Mollom works on three classifications: good content, bad content and content it is unsure of. When it’s unable to make a classification, Mollom will present a CAPTCHA box to the user to verify their input.

Getting Started With Mollom

There’s a fairly comprehensive post about Mollom over on Dries Buytaert’s blog that should get you up and running in no time. Unlike Akismet, which allows you to use the same key across multiple websites, Mollom requires you to create a key set for each website you plan to run it on.

It only takes a moment or two to get up and running, so visit the Mollom website for more information.

* User accounts that are created by software for the purposes of spamming.

The theory behind this is that you protect your site from linking to ‘bad neighbourhoods’ an possibly incurring penalties with Google for spammy links. Rel=”nofollow” is your way of saying - as the site owner - that you can’t vouch for the quality of those links.

Anyway, you probably already know the reasoning - let’s show you how to set this up.

Configuring Nofollow On Input Filters

Yes, that’s right. The “nofollow” attribute is configured on Input filters. Go to your Drupal administration pages and browse to Site Configuration -> Input Formats.

Normally you want the default Input Format set to Filtered HTML for user-generated content. This allows your users the ability to use HTML formatting without having access to insert scripts or other disruptive things on the site.

1. Click on the configure button for Filtered HTML. You’ll see under the Filters heading that a number of filters are activated. If the HTML Filter isn’t activated, then activate it and save your changes.
2. Click the Configure button at the top of the page and you’ll see how the filter is currently configured.
3. Activate the option for Spam link deterrent and save the settings. All outgoing links will now have rel=”nofollow” applied to them.

Refining With Access Permissions

If you want to be especially clever about it, you could modify permissions so that regular members and anonymous users get the Filtered HTML input by default but set your ‘trusted members‘ up with access to a less restrictive Input Format such as Full HTML.

But that’s a conversation for another day, folks…

Basically, in contrast to previous editions of Drupal, comments are now configured by content type - allowing you to permit comments on blog entries, but not on image nodes.

Finding The Configuration Pages

To find the configuration page for each content type, browse to Admin -> Content Management -> Content Types and click Edit on the content type you want to set up comments on.

My reason for wanting to configure comments was to allow comments on my blog and image content types (on my personal blog), and to allow people to enter contact information. I’m also testing Drupal’s new anti-spam system called Mollom, which seems to be similar in concept to Akismet, the anti-blog spam system from Automattic.

If you want some pointers on how to set up comment configuration there are some good comments and discussions over on Lullabot.

Why? Because if you’re managing a community site, the administrator account has ultimate power. You only want to be using this where absolutely necessary. In fact, I’d suggest you have 3 user accounts:

1. The Built-in Administrator Account: In Drupal, the built-in admin account has total control to manage the site’s features.
2. Your live account: Your own identity on the website that you use when posting content and interacting with other members.
3. A dummy account for testing permissions. An account whose permissions you can alter to test menus and access rights.

The Administrator Account

I use the admin account for high-level tasks like activating/installing modules and configuring forum features. The admin account has total control of the site by default, and needs to be managed carefully.

By not using it as my primary account, I’m not tempted to go in and make tweaks to the configuration on an ad-hoc basis. This sometimes prevents rash changes that might affect the way the site works.

The Live Account

I keep a live account for posting and interacting on the site myself. My permissions are still higher than a normal user, but only allow me to carry out moderation tasks. This way, I get roughly the same user experience that other users get, which is useful from a site design and usability perspective.

I add myself (and other high-level users) to a Trusted Members group which has the appropriate access permissions granted in Drupal.

The Dummy Account

Keeping a ‘dummy’ user account is useful when I want to test permissions in Drupal. This can be useful to test everything from basic ‘authenticated user’ permissions through all of the tiers of user access I’ve created for the site. You just use your administrator permissions to grant the appropriate level of access to the dummy account, then log on with that account and check the menu structures and what features you have access to.

This can be helpful, as I discovered today that one of my sites had image uploading permissions for authenticated users, but didn’t have blog/forum posting rights. Likewise, I discovered my ‘trusted member’ group had access to the page and story content types. I didn’t want this, as I wanted to restrict trusted members (including myself) to using the blog/forum/image content types.

Summary

I hope this is helpful for Drupal administrators. If there’s one thing I would do again on some of my early Drupal sites it would be to set up better segmentation between my administrator account and my live posting account.

When I installed the Unreality TV Forum, the first thing I did was to make the layout fixed-width for better legibility. The liquid layout of most forum themes results in long lines that are difficult to read without getting cataracts or worse! But that’s a usability thing.

The first thing I’m tackling for SEO reasons is titling. The page title is correct - it follows the format of the topic title. But on-page, the title is repeated loads of times, but not once with any sort of semantic meaning. I’m talking about the H1 tag here.

How do we tell Google what the page is about? Kick it off with a title wrapped in <h1></h1>. The problem with SMF themes is that they’re badly commented and hard to navigate. So here’s how I do it.

Theme Inheritance

There is a default theme included with SMF that all other themes derive from. The template that handles topic display is called display.template.php. If you want to customise this template, never do it to the default version - always copy the file to your custom theme folder.

The way inheritance works is that SMF will look for a customised display template first. If it doesn’t find one, it’ll revert to the default. So, bearing that in mind, let’s begin.

Take a copy of the display.template.php from the default theme folder and copy it into your current theme folder. We’ll edit this file to override the default forum topic display.

Hacking The Topic Display Template

Round about line 208 on the display template, there’s a bit of code that displays the topic title and the number of views that topic has had.

<td valign="middle" width="85%" style="padding-left: 6px;" id="top_subject">        ', $txt[118], ': ', $context['subject'], ' &nbsp;(', $txt[641], ' ', $context['num_views'], ' ', $txt[642], ')</td>

What I did was to take out the number of views and put that piece of code elsewhere. Once that was done, I wrapped the resulting code in <h1> tags, giving some semantic richness to the topic title.

The modified code (minus the page views) is this:

<td valign="middle" width="85%" style="padding-left: 6px;" id="top_subject">        <h1 class="topictitle">', $context['subject'], '</h1></td>

Now, I made this change to our forum less than a week ago. I want to give Google a bit of time to reindex the site and take into account the new page structures. It’ll be interesting to see if this relatively simple change makes a long term difference to ranking on the forum.

Hacking The Forum Users

One of the biggest problems in running a forum is that you give up control over input to your members. And your members are probably not SEO aware.

I had a word with some of our power members and asked them to be more thorough with their titles - including full names and details where possible. I didn’t approach this as an SEO issue - I approached it as a usability issue. Because we republish our latest forum headlines on the Unreality blogs, it was important that those topics made sense to any readers browsing the website.

So, we approached this from a usability point of view, which is correct. But we also hopefully gain SEO benefits.

Other SMF Hacks

There are a couple of other things I’d like to hack in SMF if I could. One is the poor URLs the system generates. The other is a full semantic reworking of the topic display template so that it’s not completely dependent on table-based layouts. If anybody’s done any work on this kind of thing, I’d love to hear it.

Currently, I’m using Yahoo! for my everyday searches, supplemented by Microsoft’s Live.com.

One of the biggest benefits of using alternative search engines is seeing different results. I’d gotten tired of Google showing Wikipedia as the first result for virtually everything. Yahoo! and Live don’t give Wikipedia nearly as much weight as Google does, so that’s a major bonus - other sites manage to rise to the top of the results pages.

Anyway, since I’m using Yahoo! much more, I was pleased to come across this guide on the Yahoo! search blog which shows you how to get better results out of your search queries. Here’s an overview:

1. Advanced search queries: terms you can add to your search to filter for specific results. You can use square brackets to specifiy the order of words in the search. For example [gerard mcgarry] will find "Gerard McGarry", but not "McGarry Gerard".
2. Package tracking: Tracking UPS, FedEx and USPS deliveries directly from the search bar.
3. Definitions & Synonyms: Type define or definition along with your query to get a dictionary style definition of a word.
4. Exclude terms: This works in the standard way - if you want to exclude a term from your search type the word with a minus sign in front of it.
5. Travel information: You can get a host of travel information including a flight tracker, traffic status and maps.
6. Quick links to Yahoo! services: Type the name of the Yahoo service you require and an exclamation mark immediately after to visit that Yahoo! service. For example, a search for ‘news!‘ will take you directly to Yahoo News.
7. Open Shortcuts: Similar to the technique in point 6, you can automatically search a specific site using this. Search Wikipedia for information about The Wombles by using the search ‘!wiki The Wombles‘. To search for variations on this type of query, do a search for ‘!list‘

Not a bad set of tips for getting the most out of Yahoo!. The one thing I’ve noticed is missing (to my knowledge) is the calculator and currency converter functionality. If I find a way to do this, I’ll let you know!

So, I’m officially an…

SEO Professional - 74%

I’m feeling a little smug about that news. Understandably.