Autarchy of the Private Cave

fail2ban has a php-url-fopen rule.

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.

Since some WP release, the comment author’s link in comments is broken – it has ‘ external nofollow’ attached straight to the href attribute (which breaks the link).

I assume that the problem is caused by Google Analytics, namely the “track outgoing clicks” feature (as recalled, might be inaccurate feature name). “Track outgoing links” adds some JavaScript code to all outgoing links, and that script has tick characters like this one ‘ which, incidentally, are also used for delimiting the values of comment anchor tags.

To fix:
Read the rest of this entry »

I’ve seen someone reading my blog from a 320×240 handheld device, and realized that it must be pretty inconvenient. Testing my blog with the help of ready.mobi confirmed my worst expectations with a mobile-readiness score of 1.

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.

Is that only me, or WordPress is really leaning towards the Drupal ideology?

Here’s what I mean:

• user levels were changed to user roles – just like in Drupal
• now, instead of categories and just recently introduced tags, the word ‘taxonomy’ is used – which is a Drupal slang
• ‘widgets’ work just like ‘blocks’ in Drupal – even style IDs are assigned the same way, e.g. id=”widget subscribe_to_comments_widget”
• (add here the similarity you found yourself)

I wonder, what will be next. PHPTemplate support, as default theming engine?
Or no-backwards-compatibility policy?
Or, best for WP users, advanced Drupal-like caching and throttling techniques?

Get it here.

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).

Today I moved my blog and gallery into MySQL5 databases from an elderly MySQL4. Also, both WP and gallery are now updated to the latest versions. Soon I’ll change the WP and G2 themes – for the lighter, less cluttered – and will remove some ads… and will also add some others instead

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!

I stumbled upon a good tiny widget which allows to “rotate” chunks of HTML code in your sidebar (using wordpress widgets plugin).
You may set up a couple of this rotators for different content types (e.g., text links, banners, google ads), and within each block put a number of alternatives, separated with a standard < --!more-- > tag (with no spaces, of course). Now each time when your page is shown, each instance of AdRotator will show one of the alternatives you put into it. Pretty simple and useful!