A Mind @ Play

Spam

If there’s one jargon term that every user new to the Internet soon becomes acquainted with, spam must near the top of the list. Its prevalence and virtual ubiquity through many forms of online communication have generated miniature industries devoted to dealing with it, and the science of spam detection, prevention and treatment almost resembles the tactical skirmishes of biological immune systems.

Spam exists in many forms, from bogus guestbook entries to elaborate instant messaging robots, but the variety which prompted this post was that classic form - unsolicited email. The level of penetration of spam illustrates itself in the number of systems put in place to combat it as standard on the vast majority of websites, including of course authentication emails and the ever evolving captcha. I use a small combination of plugins on this blog to block out most of the spam, and given the extreme sparcity of genuine comments, the potential for inconvenient ‘false positives’ is rather slim. Nevertheless, even the cursory inspection I tend to make over Akismet’s latest haul becomes tiresome for all the size of this blog - spam comments to date outnumber genuine ones by a factor of almost 500 (and that only counts those caught and tallied by Akismet). Quite how larger, more popular blogs deal with searching for false positives, I don’t know, but the task must be fairly time-consuming.

Wordpress

With the news that WordPress Photo Album plugin potentially contains a security vulnerability , I decided it was probably time that I took stock of my increasingly long plugins list and removed some of the outdated and superfluous items. One of the greatest improvements to WordPress of late has been the automatic update checks provided for plugins listed on the official site , which whilst by no means universal does at least mean that updates for many popular plugins will automatically be reported without the need to check up on each one manually. This little list of what remains represents some of the better plugins I’ve encountered.

foods_1.jpg

This idea is one which keeps popping up from time to time, normally on those occasions when it would actually come in useful, only to be thrown on the backburner for another time or a more talented author. Well this time I’ve decided just to throw the idea down on electronic paper for anyone with the skills and the time to make it work have a go. Of course, it’s quite likely that such a website already exists and that I just haven’t yet been able to find it, but if anyone knows of such a place, let me know!

Ostensibly the website is aimed at those allegedly few remaining people who cook, though it would appear equally useful to people planning dinner parties, students looking for something to go with their pasta, or just about anyone curious enough to experiment with a few different ingredients. In its essence, the website would be nothing more than a large recipe repository, with everything from snacks and sandwiches to stews and casseroles, with anything in between. Recipes would be submitted by users, moderated and standardised, but the slightly clever part is that these recipes would not be displayed as flat text files—it’s 2007 after all—but would be cross-referenced in such a way as to make the whole collection completely accessible.

For those upgrading their WordPress powered blogs to 2.2, just a word of warning regarding the new character encoding options available in the wp-config.php file.

The standard file should have a section which reads:

// ** MySQL settings ** //
define('DB_NAME', dbname// The name of the database
define('DB_USER', 'dbuser'); // Your MySQL username
define('DB_PASSWORD', 'dbpassword'); // ...and password
define('DB_HOST', 'localhost');
define('WP_HOME', 'http://www.yourblog.com/');
define('WP_SITEURL', 'http://www.yourblog.com/');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', 'utf8');

Note the new options added at the bottom regarding the codepage used in the blog’s database. If these are set incorrectly they may make your blog unreadable, else prevent special characters from appearing correctly. I personally found that commenting these two lines out left the blog functioning as before, but for people wishing to change the codepage of their database, WordPress has a rough guide available, originally written for the beta testers.