Your first step is to be able to easily list the installs you have on your system. You could maintain a list but it’s easier to let MySQL do the hard work for you. Make sure your WordPress databases identifiable by name alone.

The following Perl snippet illustrates how you might list all your WordPress installs.

$sql = "show databases like 'wordpress_\%'";
$sth = $dbh->prepare("$sql");
$sth->execute();
while($row = $sth->fetchrow_arrayref){
	($name) = @$row;
	print $row , "\n";
}

It’s useful to be able to map your WordPress installations to their location on disk. You could record the location of each installation, but it’s probably better to have a standard location. For instance, each install could be found under /home/<sitename> or /var/www/<sitename>.

Here’s the Perl I use to map my database names to directories. The hash allows me to override the standard mapping for a few exceptional installations.

my %dir_exceptions = (
    "foo" => '/var/www/foo/wp',
    "bar" => '/home/bar/public_html/blog',
);
sub wordpress_location {   
    my $name = shift;
    $name =~ m/wordpress_(.*)/;
    $name = $1;
    if(defined($dir_exceptions{"$name"})){
        return $dir_exceptions{"$name"};
    } else {
        return "/var/www/$name/";
    }
}

Tripwire is available as a package for most Linux distributions. Assuming you’re using Debian, Ubuntu or something similar, simply:

# apt-get install tripwire

We’ll not go into full details on how to configure Tripwire, you should read the documentation and manual pages provided with Tripwire for more information. Let’s concentrate on the important part, a policy that monitors your WordPress files. In my case I’ve edited /etc/tripwire/twpol.txt to read.

#
# Global Variable Definitions
#
# These definitions override those in to configuration file.  Do not
# change them unless you understand what you're doing.
#
@@section GLOBAL
TWBIN = /usr/sbin;
TWETC = /etc/tripwire;
TWVAR = /var/lib/tripwire;

#
# File System Definitions
#
@@section FS

#
# WordPress Files
#
(
    rulename = "WordPress Installs",
    severity = 100,
    emailto = james@freecharity.org.uk
)
{
        /var/www/main  -> $(IgnoreNone);
        /var/www/main/wp-content  -> $(Dynamic);
        /home/james/public_html  -> $(IgnoreNone);
        /home/james/public_html/wp-content  -> $(Dynamic);
}

This policy protects two WordPress installations. One in /var/www/main and another in /home/james/public_html (in reality my configuration file protects over fifty similar installs).

The policy reports on any change to the core WordPress files. For the wp-content directories we use the Dynamic keyword. This tells Tripwire to be less concerned with minor changes such as file sizes (see the twpolicy man page for more details). You might wish to ignore this directory entirely. Change the line to read something like.

        !/var/www/main/wp-content;

Compile your Tripwire policy with

# twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt

and initialise your Tripwire database with

# tripwire --init

To check the integrity of your WordPress files you can now run

# tripwire --check

Tripwire will now check the integrity of the files specified in your policy. If you’re unlucky the resulting report will contain something like:

-------------------------------------------------------------------------------
Rule Name: WordPress Installs (/var/www/main)
Severity Level: 100
-------------------------------------------------------------------------------
Modified:
"/var/www/main"
"/var/www/main/index.php"

It looks like one of the core WordPress files, one that’s not meant to change ever, has been tampered with. It’d be best to take a look over the file and compare it with a known good copy. Once you’re happy that everything is back to normal you’ll want to update Tripwire’s database so that reported changes are ignored in future checks

# tripwire --update

That’s it. Let’s hope that you never have to make full use of the facilities that Tripwire provides. It’s no substitute for keeping your install up to date!

Hiding addresses

This is often done by writing the e-mail addresses in a form that only a human could understand; perhaps james@freecharity.REMOVEMEorg.uk, or james (at) freecharity (dot) org (dot) uk, or as an image embedded in a page. These address can’t easily be picked out as a valid e-mail address by automated software.

More recent schemes use JavaScript to hide the address in the source of the web page but reassemble it when executed in a web browser. This works as long spammers don’t execute JavaScript in the pages they crawl and we’ve no reason to suspect that some are not already doing so. These schemes don’t account for readers who can’t run the embedded script and so fails to meet the most basic level of conformance with the Web Content Accessibility Guidelines.

Your readers want to click on a link and start writing an e-mail straight away and you’ve purposely stoped them from doing so. Someone impulsively contacting you might be put off, another person might not understand your scheme.

Contact forms

Replacing e-mail addresses with server side scripts and HTML contact forms can provide a means for people to contact you without publishing an address. This seems ideal.

Unfortunately, most of your readers already have a familiar, comfortable and functional environment for sending communications – their e-mail software. It allows them to record, sort, archive and search through past communications, manage attachments, addresses and presenting all this in a format tailored to their individual accessibility requirements. By forcing the use of contact forms you take this away from your readers.

(Not that web forms don’t have their place. They’re great for ensuring that people send you precisely the information you require from them).

Summary

Publish your addresses and deal with spam as it arrives. Spammers use other sources of e-mail addresses over which you have no control. The limited reduction in spam that these methods provide comes at a burden upon your legitimate readers. You should design your website to be usable for them; not convenient for yourself.

Know your audience: people working for charities aren’t always computer experts and are likely to have been volunteered into being the organization’s accidental techie. They might not have had any choice over what software tools they use for practical, political and financial reasons; don’t criticize them for it. Most people are going to have a pragmatic approach to IT; they have problems and need them solved now. It’d be nice if everyone could share your view of ethics but the practical benefits are more important now.

Use positive, vigorous arguments. FOSS has far more to offer than simply being a better alternative to Microsoft. Great sales messages don’t focus on how better your widget is than all previous widgets (many technically superior products have failed) but by concentrating on what instant benefits using your widget will bring. There’s no need to refer to Microsoft as M$ or otherwise insult them; it’s unprofessional.

Be consistent, but more importantly be realistic and correct. Here are some common mistakes.

• FOSS is not without costs. Even GPL licensing can cost.
• Commercial software and FOSS are not mutually exclusive. The most important projects are worked on by multinational companies.
• No software is without problems. FOSS has bugs and usability problems too.
• Open standards are not exclusive to FOSS. Proprietary software often makes good use of open standards to exchange data with other applications.

It’s easy to think that the world is against FOSS; especially when the facts seem to fit that view. Some people are hard to win over, some you can’t. Accusations of conspiracy will not help your case and make you look unprofessional. Expect people to have different opinions and viewpoints to yourself.

Don’t get personal: ignore others when they do. Be prepared to apologize if you accidentally offend someone. Knowing when not to advocate and when to back down is more productive than trying to grab even the smallest opportunity.

I’d love to hear, by e-mail or in the comments, if there’s anything you think that could be added or removed from this short list. It’s a tricky subject.

1. Disable comments completely
2. Allow only registered users to comment
3. Install a spam fighting plugin – Spam Karma 2

Disabling comments completely

If you don’t want people to be able to comment at all this is a quick, easy and straight forward method to stop the spam. In the administrative interface for your WordPress installation, select Options -> Discussion. Uncheck “Allow link notifications from other Weblogs” and “Allow people to post comments on the article” and click “Update Options”.

After you’ve done this, you could go a little further by removing references to comments, and the comment form template from your theme. This will avoid some themes needlessly announcing that comments have been disabled.

Allowing only registered users to comment

Allowing anyone in the world unrestricted access to comment is a fast route to spam. If do allow online discussion, ask your users to register first. Once logged into the administration pages, go to Options -> General. Tick the boxes for ‘Anyone can register’ and ‘Users must be registered and logged in to comment’. You may also wish to investigate the ‘An administrator must always approve the comment’ or ‘Comment author must have a previously approved comment’ options under Options -> Discussion.

Installing Spam Karma 2

Spam Karma (SK2) is a WordPress plugin that monitors comments and scrutinizes them before allowing them to be published. Every comment is scored against a number of tests such as where the comment was posted from, is the poster known to be good, does the content look like spam? Posts with a high enough score will be published, posts with low scores will be held for approval and posts with very low scores will be swept away. Each day an e-mail is sent to you with a summary of what actions SK2 has taken.

Download SK2 from it’s website and upload it to your plugins folder in your WordPress installation. Enable it in the ‘Plugins’ administration page. SK2 can now be configured from the “Manage -> Spam Karma 2″ page. Although the default settings should suit most people, you can tweak the tests the plugin performs. Further pages allow you to release comments from moderation, or remove spam comments that slipped through.

Further information can be found in the SK2 FAQ.

Read more about how to use WordPress for web publishing.

This one step will have you using WordPress to manage a traditional website.

Unfortunately the recording software I use, xvidcap, doesn’t come included with Ubuntu but there’s a Debian package available which worked just fine for me. It’s not as sophisticated as many of it’s Windows counterparts but you could be able to use the accessibility features of your desktop to compensate for features such as magnification. I’ve created a short meta-screencast giving a brief tour of xvidcap.

Once you’ve finished with xvidcap you’ll be left with an MPEG video file which you could upload straight to YouTube or another hosting service. I’m happy with this informal style of short screencasts as single takes but the video editing software Kino comes with Ubuntu for your basic editing needs.As is usual for free software there are many alternatives, this was the selection of software that worked best for me as a complete beginner to screencasting and video in Linux. You might also wish to look at ffmpeg and Istanbul for screen capture and Cinelerra and LiVES for editing.Take a look at the WordPress screencasts I’ve produced, or read about how to use WordPress for web publishing.