WordPress has a Global Translator plugin, which – among others – uses Google Translate service.

If someone uses Google Translate (e.g. using Global Translate’s mini-language-flags), and goes back to your blog – that someone might get banned by fail2ban (especially if you have set maxretry to 1), as the referrer will contain the php-URL-fopen attack signature. The bad thing is that you will not realize that until after you check one or several translations yourself, as a random site visitor experiencing the problem is highly unlikely to bother reporting this problem – especially when your blog’s Contact page is also inaccessible.

Clearly, Google Translate is not the only legitimate service which will trigger that rule.

Solution: The only solution I have found is to specify the whitelist regex for the php-URL-fopen rule.

I’ve installed and then tested one-by-one a series of WP plugins designed to make your blog mobile-accessible. Testing was done using ready.mobi; all plugins were using default settings – except for viewMobile, which had Images option set to Resize, not Keep As Is.

On Mobilize by Mippin plugin ready.mobi exited with error “Could not retrieve page content”, which is no wonder as Mippin plugin redirects the handheld device’s browser to mippin.com, which converts the page into mobile-accessible form (however, it is indeed strange that mowser.com plugin worked fine, though it is also a redirector). I’ve used mippinmaker to estimate what would my blog look like via mippin – and it appears to me that mippin is using my RSS as the source of content; actually, plugin description explicitly states that. I’m sure this would get real high scores on ready.mobi, but I can’t find the way to test that; thus Mippin plugin didn’t participate in the final feature-based comparison.

viewMobile plugin is a clear winner best by score in “plugins” group – it has the highest scores in the feature table (well, after mowser plugin, which is not a plugin but a redirector to an external service). Also, in addition to “keep as is” and “downsample”, there is an option to “strip” images – I presume that would bring the page size further down. However, viewMobile removes comment forms from posts; at the same time, PDA & iPhone plugin preserves comment forms – thus it is better for my purposes.

The mowser-based service has even higher scores than viewMobile – but is an external dependency. For my blog, I decided to stick to PDA & iPhone plugin. Also, such a low page size (see table) is due to mowser splitting the tested main blog page into two pages – and ready.mobi then only weighs the first (much smaller) page; so there is no benefit in page size when using mowser.

Please comment to share your experience of turning your blog mobile-accessible, or of reading my blog from handheld/mobile devices.

P.S. If you are used to visiting websites and blogs from your handheld device, and those sites/blogs are not optimized for mobile devices, I’d recommend using the free mowser service (though Opera Mini is easier, I guess).

P.P.S. This post wasn’t sponsored by mowser or any other mentioned services

Important update: clearly, viewMobile and any other PHP-level mobile accessibility plugins are incompatible with SuperCache. So either (super) caching, or mobile version – but not both. I’ll have to look into possible solutions.

Update 2

A “clever” solution would be to have a subdomain or even a different TLD domain for the mobile version of the blog (to avoid SuperCache interference – ideally, both database and files would be the same, but some tiny bit of configuration would make all the difference; the easiest tiny bit would be a mod_rewrite rule). Another good solution would be to modify SuperCache’s mod_rewrite rules, so that mobile User-Agents aren’t fed cached versions – and thus viewMobile has a chance to trigger and serve correct version (this solution doesn’t require another domain or subdomain, but is less reliable).

I’ve tried mowser plugin, but it suffers from the same cache interference problem (because it is also PHP-level, and SuperCache works at apache and mod_rewrite level). For the same reason, PDA & iPhone plugin wouldn’t work as well.

For now, I’ve disabled SuperCache (leaving WPCache on), and turned on PDA & iPhone plugin (unlike viewMobile, it does show the comments form below each post). Seems working. Will look into domain/mod_rewrite solutions.

Update 3

SuperCache is back on, except for a list of mobile User-Agents; those User-Agents were also added to SuperCache’s UA exclude list. Thus now if a “normal” browser requests a page, such a request is cached, or a cached page is fed to the browser. If the mobile browser requests a page, it is not fed a cached page even if one exists, and cache page is not created while running WP’s PHP engine. Tested using both built-in browser (I could even fill in captcha while commenting) and Opera Mini on a Samsung phone: seems to work fine. However, all of ready.mobi’s phone emulators for some reason choked on the comment form’s textarea, refusing to display the page. I ignore this but if compliance is important then viewMobile will be a better choice than PDA & iPhone.

Drawbacks of this solution: 1) mobile requests are not cached, 2) if the mobile browser’s User-Agent is not in the list, then it will be fed a standard-looking page, 3) hard to maintain – need to update both the list of UAs in .htaccess and in the configuration of SuperCache.

Better solutions are welcome.

And SK2 still works under WP 2.5! (SK 2.3 was released to support WP 2.1)

Kudos to Dave!

It would be a pity if this excellent plugin is abandoned and stops functioning in one of the upcoming WP releases.

Update: SpamKarma is now GPL (at google code).

It adds Referrer of the person who’s leaving comment on your WP blog. May help to take the right action for seemingly legit, but really spam comments (e.g. if someone was just searching for blogs with enabled commenting to leave a comment with name linked to their biz-website).

Update generally went well, except for the message I got on the main page:

Sorry, but you are looking for something that isn’t here.

It was quite easy to figure out that new WP conflicts with an elderly “Sideblog” plugin – so I had to deactivate that one, and will have to update all the active plugins to avoid some other less evident problems… (actually, just completed updating all the plugins… quite a time-eater, that was.)

Also, there will be a slight change to what and how I write. No other details for now – but stay tuned! All the changes with no exceptions are planned for the good of readers, and for the users’ benefits!

One could think that as the spam-problem is fairly well known, there should be reliable methods to get rid of spam. However, the spam problem is like the “weapon-shield” competition: the stronger the weapon, the thicker the shield. Spammers adapt, unfortunately.

Getting down to business. In this post I’ll describe how I am solving the spam problem in my blog.

The first plugin is Comment Policy. It adds a required checkbox below the comment form, which needs to be checked in order to successfully post a comment. Checkbox field name is auto-modified by JavaScript, which means that clients (preferably spam bots) without JavaScript support will be unable to post a comment. Thus, comment policy stops non-JavaScript spam bots.

Note, that this plugin defends only the comments, not pings/trackbacks.

It can be argued that JavaScript requirement might prevent people from posting comments – true, but with all those Ajax interfaces only the tiny percent of visitors would have JS disabled. Visitors with text browsers (lynx, links, etc) would be the only group unable to post… which is bad.

The reason I keep this plugin is the presence of the actual comments policy, which clearly states what kinds of comments will not be allowed. Overkill, I know

Another plugin is email immunizer. It is supposed to protect mailto: links from harvesters. Never tested it, though: I do not post mailto: links. This is a just-in-case measure.

Peter’s Custom Anti-Spam is a Captcha plugin, i.e. it displays some text as a picture, requiring the text be input into the provided field. Evidently, protects only comments. Not 100% efficient, as there are bots able to read images. Fortunately, the majority cannot :). This plugin is only one from many, and I chose it for no specific reasons – except that it is “fresh”, requires no additional accounts hosted somewhere, and is rather small. You can extend the list of captcha words with your own, which can be fun if used properly :).

Simple trackback validation checks if the referring page exists and contains a link to your blog. If it doesn’t – the trackback/ping can be held for moderation, added to the akismet’s spam queue, or simply deleted. This is a good one to have.

WP-ContactForm is not really spam-protection, but it helps you avoid publishing email address in any form, but people can still contact you. Note, that my contact form is protected by a “math captcha”: there is a trivial math question, which requires a single numeric answer. This is also good protection – not a single spam message from the contact form after protection was installed!

Corrections, questions, additions and comments on what you’re using are welcome.

Update: since I started using SpamKarma2 plugin, all other plugins nearly lost their usefulness. SpamKarma2 is excellent – try it! Since mid-late 2007 by Jan 2008 over 100000 spam comments were discarded on my blog by SpamKarma2, which has gone GPL way.

The Snap Preview Anywhere is a WordPress Plugin to display those previews. The actual service, providing the previews, is snap.com. They also offer the FireFox Snap search engine (top-right in FF), though I don’t quite get it’s intended purpose…

The plugin page has all the necessary instructions (and even more), so won’t copy-paste here.

The only unanswered question is “Does my blog really needs this?”.
I’ll let it be for the time being… if it gets too annoying, will remove. Please comment if you think that snap previews do help somehow, and if you think that “useless” is not about snap previews.

Update: snap preview anywhere is annoying, if used on all the links. So I decided to leave SPA on for external links only, and (thanks to the new version 1.2) now the preview appears only when hovering the tiny image to the right from the link itself. This is now much less annoying, but still allows to see the preview of the linked page, if you desire to do so.

Did you think about the convenience of those of your visitors who came to your blog from, say, Google? If not – it is the time to. With the Seacrh Hilite WP plugin you can highlight search terms in your page, if your visitor comes from Google, Yahoo, Lycos or Baidu, or even your own blog’s search.

This plugin is installed and activated as usual.

I’d recommend to: go to Options > Search Hilite, set the “take CSS Style from my Stylesheet” checkbox, cut the sample CSS code from the box just below the checkbox, and paste it into your theme’s style.css file (without the lines “< style type='text/css' >” at the beginning and “< /style >” at the end). This decreases generated HTML page size, and is a proper way to handle styles.

Update:
Another tip is to edit the wp-content/plugins/search-hilite/search-hilite.php file and add the following line at the and of the file, just after other similar add_filter lines:

This will enable highlighting in the post titles, not only content. However, is the search term to be highlighted occurs within the “title” of a link, it’s display will be broken. I contacted plugin author, asking what can be done about it. As soon as there is an answer – I’ll add it here.

P.S. If you read the WP Codex, especially the paragraph on reversing page title display – please see the comments at “optimal title” home for explanations why the plugin is better.

It’s main concept is to allow WordPress administrator to use GUI in the admin panel to place new plugins in the arbitrary locations in sidebars (and not only sidebars, but that requires a bit more work), so you don’t have to modify your sidebar.php with each new plugin installed.

The actual power of Sidebar Widgets (aka WordPress widgets) is not restrained by the sidebar – the “readme” file of the plugin distribution archive provides hints and ideas on how this plugin could be used. I suspect that Widgets might become the base for the further development of many other plugins and WordPress core as well.

So hurry to the WordPress Widgets homepage, grab one, and install as usual. You might need to modify your theme, if it doesn’t support Widgets, but this process is well documented in the “readme” and should be fast and easy to complete.

You will surely enjoy this new experience, if you hadn’t yet!

This plugin automatically generates blog sitemap each time you create/update a post or a page. This is a must-have plugin, especially if you’re crazy about SEO

I can only prove the citation. So now you can contact me, too :).

Installation is as always easy. Most probably you will want to put these ‘related entries’ into yours ‘sidebar.php’ or ‘right-sidebar.php’ (if you have one), and your code may well look like this (I assume that in ‘Plugins’->’Related Posts Options’ you set the pre/post tags to ‘<li>’ and ‘</li>’):


<?php if ( is_single() || is_page() ) { ?>
<ul>
<li><h2>Related entries</h2></li>
<?php related_posts(); ?>
</ul>
<?php } ?>

The block of PHP code above the actual insert determines whether blog visitor is on the post page or blog page – this way ‘related entries’ will not be shown in listing pages. If you want, you can leave only is_single() in place, for related entries to appear only in posts, and not in pages.

Finally, plugin home is: http://www.w-a-s-a-b-i.com/archives/2006/02/02/wordpress-related-entries-20/

If you want your visitors, arriving from the wrong or just outdated links to find what they might be looking for, it will be a good idea to check Related posts for your 404. That plugin adds an extra function related_posts_404(), which you should put into your ’404.php’ template file. Now, when someone gets to your 404 page, they might as well get a list of close hits from your blog, and stay longer.

Here I will present (and regularly update) the list of plugins I looked at and installed.

The first plugin I installed is WordPress Database Backup – we all know, how painful can the data loss be. Installation is easy (copy-activate), and on-demand database backup is immediately available in Manage -> Backup menu. Plugin automatically pre-selects all default database tables, and allows you to select any other tables you happen to have in your database – these can be, for example, tables of your WordPress plugins. I would recommend saving all the database tables, except if you know that there are tables not related to your blog (you can tell this usually by the table prefix – which is ‘wp_’ by default).

After you are done with the selection of plugins, you can choose to download the backup, email it, or to store it on the server in a backup folder (plugin handles the creation of the backup folder for you).

After pressing ‘Backup’, you will see a nice progress bar, and if you had chosen to download the backup, you will get gzipped backup file.

Updates on other useful plugins coming soon… stay tuned