However, if you recently tried to upgrade to the latest version using the instructions at the WordPress Codex, you likely ran into a problem with an error mesage like this:

$ svn sw http://core.svn.wordpress.org/tags/2.8/ .
svn: 'http://core.svn.wordpress.org/tags/2.8/'
is not the same repository as
'http://svn.automattic.com'

This is because sometime between the release of 2.7.1 and 2.8, the URL of the WordPress SVN repository changed from http://svn.automattic.com/wordpress/ to http://core.svn.wordpress.org/.

The fix

To properly update WordPress after this change in the SVN repository location, we need to first run the svn sw –relocate command to relocate or point the checkout to the new repository URL:

svn sw --relocate http://svn.automattic.com/wordpress/tags/2.7.1/ http://core.svn.wordpress.org/tags/2.7.1/ .

Note that we are just changing the checkout’s repository from the old one to the new one – we aren’t yet pointing to the new version. (Note – this assumes you are currently running version 2.7.1)

After this, we can now we can switch to the new version.

svn sw http://core.svn.wordpress.org/tags/2.8/ .

Additionally, it’s worthwhile to run an svn up after this, just to make sure externals (like Akismet) are properly updated as well.

Note that this overall process has two steps – first pointing the checkout to the new repository URL, without switching to the new version, and then switching to the new version. I am not sure if you have to do it in two steps like this, but I can confirm this worked for me, and judging by the instructions in the SVN documentation, this is likely the correct way.

Thankfully, following the well-written guide on the WordPress.org Codex was easy and straightforward – both for changing this existing installation over to SVN and for setting up a new blog for RunTrackr. I now look forward to updates, just so I can relish in the ease of upgrading.

SVN is a powerful tool (I use it both at work and for personal projects) and is a great SCM tool for small-to-medium sized projects. The command-line tool is easy to use, and for Windows, the great TortoiseSVN tool can’t be beat. (It integrates nicely with the Windows explorer and is compatible with the Eclipse Subclipse SVN integration plugin) Additionally, the integrated Apache HTTP server lends itself nicely to many web-based applications that not only enable browsing but also form the basis for some remote backup/file-sharing/synchronizing services out there.

One thing you’ll probably want to do after switching WordPress (or any web application) to a SVN checkout is to protect the .svn metadata folders from public access. These folders are used by the Subversion client to keep track of changes and determine what files need to be updated when getting the latest versions. They also contain information about what SVN server you are using – in some cases you don’t want to reveal these details, and in any case it’s always best practice to deny access to anything except for that which you explicitly want to make public.

Doing this is fairly straightforward with Apache. All you need to do is edit your .htaccess file in the root of your web directory. Add an entry like this:

# SVN metadata folder protection.
<IfModule mod_rewrite.c>
  RewriteRule ^(.*/)?\.svn/ - [F,L]
</IfModule>

This works for me, though some have used other regular expressions to accomplish the same task.

Props definitely go out to Automattic for creating such a reliable and accurate service. When I first wrote about it over a year ago, I was very impressed with its precise filtering of spam and non-spam (aka ham) comments along with its unobtrusiveness. Akismet truly makes spam filtering transparent to the end user, unlike other methods such as CAPTCHAs.

Of course, I can’t forget thanking the developers of WordPress as well. Without them, I would have no site from which I’d have to protect from spam.

Check back later when this site surpasses the 1,000,000 mark for spam.

Share This is an excellent WordPress plugin written by Alex King. The plugin provides a neat and customizable pop-up menu for allowing readers to easily share one of your blog posts using many of the social bookmarking or social websites out there. It’s an intelligent solution to the problem of having too many sharing icons that may potentially distract or irritate readers.

Since launching, Share This has become very popular, with many blogs using it. I recently began using the plugin for a site of mine, and was impressed by its usefulness. (And the icon project it launched) However, I had also decided to use the jQuery JavaScript framework (and its plugins) for this site, and since Share This uses Prototype for its JavaScript functionality, there were some conflicts.

So, I decided to do a minor re-write of Share This, altering only the JavaScript portion to use jQuery instead of Prototype.

jQuery?

I wanted to stick with jQuery for a variety of reasons, but mainly because I have more experience with it than with Prototype. I won’t get into an argument over which of the frameworks is better, and will instead stick to the “Unto each his own” line of thinking.

While jQuery generally works well with existing JavaScript, as it doesn’t alter the global namespace, and additionally has a “no-conflict” mode, some of the plugins that I wanted to use (specifically Thickbox) weren’t written for the no-conflict mode. The issue stems from the use of the “$” variable name. In jQuery, it’s a shortcut for the be-all-end-all function jQuery(), while in Prototype, it’s a shortcut for document.getElementById().

Share This in jQuery

Before I offer the download, I want to make it clear that this was a very minor change – no functionality was added or removed, as just the JavaScript portion was re-written (quickly) to support jQuery instead of Prototype. Again, it’s not better than the original Share This, only different. Furthermore, 100% full credit still belongs to Alex King, as this is barely a derivative work.

In order to use this version, you will need the jQuery framework as well as the Dimensions plugin. Their cumulative compressed sizes are comparable to the compressed size of the Prototype framework. You will need to link them to your site in your WordPress theme’s header.php file by adding lines like these, preferably between the head tags.

<script type="text/javascript" src="/path-to-jquery/jquery.pack.js"></script>
<script type="text/javascript" src="/path-to-jquery-dimensions/jquery.dimensions.pack.js"></script>

You can then replace the original share-this.php with the jQuery version in the zipped download. (You may want to backup the original file first, as always)

Download

• Share This 1.4 for jQuery

Credit and Misc.

As mentioned before, all credit still belongs to Alex King for writing Share This in the first place. I haven’t really changed anything, just adapted it to work with jQuery and thought I’d like to make it available for everyone to use. It still works exactly as before, so configuring options and so forth isn’t any different.

What I changed was just the part of the plugin that outputs the JavaScript necessary to make Share This work. It’s just been changed to use jQuery instead of Prototype. I also commented out the parts of the plugin that link the Prototype framework (from WordPress) into the header. As mentioned before, you’ll have to link in the requisite jQuery script files yourself. Since it looks like WordPress will be moving over to jQuery, at least for the admin pages, this might be something worthwhile.

The JavaScript has been written in jQuery’s compatibility mode (using jQuery() instead of $), so you can continue to use Prototype on your site if you wish. As mentioned, this was a very quick rewrite, so not much has changed.

Some people have pointed out that Prototype is a lot larger than jQuery in terms of file size. This may be somewhat true, but when Prototype v 1.5.0 is packed, it comes in at only around 27 KB. jQuery packed is about 21 KB, but with the Dimensions plugin needed to make Share This work with jQuery adds another 4-5 KB, bringing the total size close to that of Prototype. So why use jQuery? Again, it’s just because I’m more familiar with it and like how jQuery expressions are formed, particularly with the ability to chain function calls.

Update

Bennett McElwee, author of many nice WordPress plugins (including some that I use on my own site), has already released a version of Share This in jQuery, seemingly two days before I published this post – what a coincidence! His appears to be more polished, though, as it doesn’t use the extra Dimensions plugin and also includes some nice effects. Definitely give it a try.

As expected, a lot of the plugins I was using needed to be upgraded, which was somewhat of a tedious process. Most of them now work, though for some of them I was unable to find updated versions. However, they all seem to be working. Please let me know if you see something that isn’t working.

So, with the seemingly troublesome upgrade, why did I bother go forward with it? Well, it wasn’t that bad. Besides, I like messing with stuff. But the real reason was that WordPress 2.1 adds some nifty new features, such as auto-saving of your post as you’re writing it, similar to how Gmail saves your messages as you’re composing them. Anything that makes computers easier to use, and less of a headache, is worth upgrading to. WordPress is already one of the easiest (if not the easiest) systems to use, and this only makes it even better.

As a last note, I’m looking to upgrade the “related posts” part of my blog, which is the part that displays similar entries to the current one at the end of a post. Currently, I’m using the related posts functionality of Category Tagging Plugin, but I think it just looks at posts that have the same category/tag. I’ll probably move over to using the Related Entries Plugin, which actually uses a full text index to do comparisons to find similar posts. It’ll probably be a little more accurate.

I wonder if this is related to the recent update to the system (as it’s a centralized service), or something else. The update seemed to be only related to improving the statistics tracking of the service, and not something related to the spam-detection algorithm. I’ve tried disabling/enabling the plugin, so we’ll see if that helps – has anyone else been having these problems?

However, this can create problems if you want to create password-protected directories. Accessing them sometimes doesn’t work because of WordPress’s .htaccess file, however this isn’t a WordPress problem per se, but rather a problem with how Apache has been set up. I ran into this problem – I tried accessing a password-protected directory that I knew had been set up properly, but I kept getting a 404 error and was redirected to my WordPress theme’s 404 page. After a little bit of searching over at the WordPress support boards, I found some solutions that were sort of messy, involving editing WordPress files or adding a lot to the .htaccess file.

However, after looking for a bit more, I found this page, where the author outlines his fix; but later on a comment posted to his site provided me with the fix I wanted – something simple. Though that site deals with TextPattern, another blogging platform, apparently it handles requests in a similar manner to WordPress.

The problem lies with improperly set (usually non-specified) ErrorDocument directives. In this case, the responsible error codes are 401 (Unauthorized) and 403 (Forbidden). These directives are used to tell Apache what document to send or display to the user when each of these error codes are encountered. If these are set to point to a non-existant file, WordPress ends up handling the request – which in these cases, it treats just like a 404. When you try to access a password-protected resource, Apache first sends a 401 (Unauthorized), as a challenge to provide the proper credentials (login/password); if the error directive for this points to non-existant file, then the request is improperly passed on to WordPress and then treated like a 404 here.

To fix it, you need to specify the error directives in your root .htaccess file, which if you have WordPress in the root, is the same file that WordPress uses. If you open it up, you should find WordPress’ rules in there, which will look something like this

# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress

Add the following lines to the .htaccess file.

ErrorDocument 401 /<PATH_TO_ERROR_DOCS>/401.html
ErrorDocument 403 /<PATH_TO_ERROR_DOCS>/403.html

Where 401.html and 403.html are the pages you want shown when each of those respective errors are encountered. These should be static pages. (eg. not server-side scripts) This fix worked like a charm for me.

In the old days…

Back a few years ago, the big thing was e-mail spam. It’s been around so long that almost anyone who’s used e-mail knows about it. All those e-mails telling you how to re-finance your mortgage, get low-cost prescription drugs or how to grow a certain appendage longer tended to fill up one’s inbox, making it a pain to delete all of them and find the real e-mail that you needed to read.

For those of you thinking that e-mail spam was big annoyance, recent polls have shown that people apparently do make purchases from spam e-mails, making it a viable direct marketing tactic. However, server-side e-mail spam filters have greatly increased in their ability to weed out junk e-mails in the past few years, so for many people, spam is not as big of a problem as it once was. Unless, you’re using Hotmail.

Adapt or die

Faced with the prospect of decreased income thanks to e-mail spam filters (or just wanting to make more money), spammers began a new front in the war of direct marketing. They began to spam forums, guestbooks and most recently, commenting systems on various systems in the hopes of drawing attention to the products they were advertising. The purpose was the same – to encourage people to buy products, mostly the same ones they had been sending out in mass e-mails. So, while e-mail spam has not gone away in recent times, alternative forms of spam have increased many times.

In fact, spamming online communites with message may even be more effective, since a spammer needs only to get their message on one site in order for it to be viewed by many. However, since spam tended to be easy to distinguish from comments posted by humans, it was relatively easy for developers to combat this by building in anti-spam features to weed out spam. Spammers responded by making their “bots” – the automated programs that sent out the spam messages – better and trying to make the “quality” of their messages seem more “human”.

A personal experience

My site, unitstep.net, is far from a popular site. However, spam bots have still managed to find this site and I’ve logged 104 spam comments in just over two months’ worth of operation. That’s quite impressive, and shows that spammers are actively searching for new blogs to spam. As I mentioned before, some comment spam is aimed at promoting other websites in order to increase their ranking in SERPS (Search Engine Results Pages), thus drawing unsuspecting visitors to their sites, where they are served up advertising that looks like regular content. (WordPress and most blogs add an attribute of rel="nofollow" to comment links to defeat this, but they still try.) Most of the spam I’ve got, has been of the direct marketing variety, though.

If you haven’t seen the comment spam though, it’s because of Akismet, a truly kick-ass plugin for WordPress, written by the same team. It basically uses a central authority to check on every comment that’s submitted, and analyzes its content to determine if its likely to be spam, or likely to be real. Comments that are marked as spam aren’t shown, and are instead put in a moderation queue, for me to look at and delete or, if it’s a false positive, allow it through. Akismet appears to learn as well, so it’s success rate increases the longer it’s been in use. I apparently joined relatively late in the game, as I have yet to find Akismet report a false positive or let a spam comment through.

Until today.

However, I don’t blame Akismet for this one, as I was almost caught off guard. Here was the content of the comment:

Plato learning…

I am Karin, very interesting article that contained the information I was searching for in Google, thanks….

Upon closer inspection, the comment does look like a spammer’s, since it didn’t specifically relate to the post’s topic, instead using a generalized statement. The first sentence also made no sense. But, what threw me off was the lack of links in the post – the spam bot had just instead used the regular “homepage” field to fill in the URL of their spam blog – or splog – in the hopes that someone would visit it.

In fact, due to my curiousity, I had to visit the site to see what was on it. (This was, of course, how I determined it to be a splog) The splog consisted of a load of nonsensical posts, and of course, lots of ads, by Google no less. Since it’s against the terms-of-service of Google Adsense to make a site for the direct purpose of displaying Google ads, this spammer is obviously in clear violate of the program. The spam blog wasn’t littered with links though (besides the ads), and the posts would look human after only a quick check – a closer inspection reveals sentences merged together into nonsensical, run-on paragraphs.

The Turing test

All of the efforts by current spammers reminded me of the Turing Test. Basically, it’s a concept that if a person communicating with a computer cannot reliably tell if they are communicating with a computer or a human, then that computer system is said to have passed the test. Turing thought it was a better way of evaluating a computer over the question of “Can a computer think?”

In a way, spam and anti-spam techiques are engaged in some sort of Turing test. Except that it’s a computer system (the anti-spam system) that is trying to determine if an entity is a computer (spambot) or a real human. The anti-spam techniques described above have typically been widely used, along with CAPTCHAs or other “tests” that the typical human can easily do, but are relatively hard to design into a computer program or system.

However, as programming techniques and algorithms advance, the spam/anti-spam war is sure to heat up. As seen by some of the comment spam I’ve started to get, spammers are getting better with the bots they produce. They’re moving away from posting messages that are heavily-laden with links to gambling/porn sites that are obviously spam, to posting messages that could have conceivably come from a human, with only the regular home page link that any curious visitor might click. As these techiques advance, it’s entirely possible that a spam bot could read a blog post, analyze the content, and post a reasonably-specific message that contained a few links here and there to spam sites. The same goes for CAPTCHAs as well – advances in image processing are making optical character recognition more and more accurate.

The end result is, as I mentioned at the beginning, a lower SNR and lower quality of information on the web. Not only will more useless spam information be disseminated, making it more likely to find crap rather than helpful information when doing a search – but it’ll also be harder to post actual information that isn’t incorrectly labelled as spam. For example, if spam bots were able to post vaguly post-specific comments to sites, then quick remarks by people, such as “Thanks for the useful information!”, might also get labelled as spam. Same goes for CAPTCHAs – if we make the images more distorted and the characters harder to read, people might also have trouble – I know I do on some of them – and this creates another problem of accessibility for the disabled.

This isn’t to say I’ve lost hope. Akismet, so far, has only missed one comment – and I would have missed it had I not visited the linked site. So, it hasn’t really let me down. Others have had similar success, so for now, I think anti-spam techniques have the upper hand. Spam is merely an annoyance and a statistic currently, and I hope it stays that way. What I’ve talked about in this entry could be viewed as a worse case scenario of sorts.

Now, excuse me while I press “Delete All” on the spam comment moderation queue.

The first bugs I noticed were WordPress adding backslashes (“\”) before some quotes in comments and link descriptions, either after they had been posted or edited. This appeared to be an improper call to the PHP addslashes() function, since it was translating phrases like “it’s” into “it\’s”, and is the common way to escape a string before input in to something like a SQL statement. However, it appears it was being called more than once.

I found no way to get rid of the backslashes, other than manually editing the table record, and furthermore, didn’t know how to fix this behaviour. I figured I’d just deal with it, since I don’t really blog that much, and surely a new version will be out soon.

But, while browsing one day, I found this post detailing another blogger’s experience with these bugs. Luckily, they had been more persistant than I, and had found a helpful link to a “tuneup” plugin that specifically fixed these problems introduced in WordPress 2.0.3. I just installed it, and everything appears to be back to normal. I’m not sure why the WordPress crew hasn’t decided to announce and link to this fix, as I think it’s quite essential for proper operation.

Recommended as a “must-have” plugin for WordPress 2.0.3.

Firstly, there are just so many tagging plugins out there, that I have a tough time deciding which ones are good, or even which ones have the features I want. (Or even what features I want!) Reading up on other people’s personal experiences, while useful, is also very time-consuming, but I’ve run into a few potential plugins.

Firstly, Ultimate Tag Warrior seems to be a feature-rich plugin that should have everything I’d ever need. Besides tagging support, it also offers support for weighted tag clouds, similar to what you have at del.icio.us. But, since it keeps tags separate from categories (not a bad thing), it uses its own table for tag storage, which could create problems when upgrading. But this is a minor problem, as I’m sure a writing a script for the upgrade conversion would be trivial. But, I’ve also heard some negativity about it, and from playing around with it for a bit, it seems to have almost too many features for me.

This category-tagging plugin also looks decent. In contrast to Ultimate Tag Warrior, it just uses the WordPress categories as tags, and thus shouldn’t have to rely on any other tables besides WordPress’ own. This plugin thus probably does the least modification, and this is good since less is often more. An additional benefit is that no more work would be required in order to display tags, since categories would become tags. It also includes nice functions such as a weighted tag cloud. Yet another plugin, Cat2Tag also seems to provide similar functionality to this one. These plugins would also probably be the best option in considering future versions of WordPress – I believe it’s likely that categories will be supplanted by tags in the next major version.

But maybe the main reason for my apprehension is my unnatural like of the structure of categories. You see, tags have become such a big thing because they are easy to use, and natural to most everyone. But for me, it seems to be the opposite. Despite not being able to deny the usefulness of tags, I would still like to have categories alongside them. For me, tags can be too open-ended, but perhaps this is just in the sematics of how tags are used – I suppose tags can be just as structured as categories. Perhaps a good compromise would be categories for the main subject and tagging for keywords; this would provide a good structure and still have the good metadata of tags. This would also eliminate the need for a nightmare hierarchy of categories and sub-categories. (Ultimate Tag Warrior could provide this functionality.)

But, maybe I’ll just have to learn to deal with a tags-only system if and when WordPress switches over to tags. In the meantime, I’ll probably be fence-sitting, undecided on what to do, and inevitably, stuck without tags.

Update

I’ve decided to go with the simple, but effective Category Tagging Plugin for WordPress, since it uses WordPress’ own categories as “tags”, and so integrates nicely while at the same time providing much-needed “Related Posts” and “Tag Cloud” functions. The fact that it doesn’t create another table for the tags makes it easy to switch out from using this plugin, should the need arise. Stay tuned for more details.