Read this as you were a TV commercial anchor: Does your WordPress blog have images attached? Do your users suffers form slow page load times? Fear no more. The client image caching tutorial is here. 🙂

I used Google Page Speed and WebPagetest to analyze the performance of “my” blog. The things I found out are:
– WP Minify, which joins different CSS and JavaScript files is working as expected;
– page requests do not send cookies only to HTML/PHP pages but to images also (not good);
– loaded images do not get cached by the browser and they are reloaded every time the user refreshes the page (very bad);
– ETags should be left alone – Google wants them, WebPagetest doesn’t.

Sending cookies to images is not a big problem, because the only thing that suffers is a little slower sending of requests to the server. This can be fixed by setting a new domain name (let’s say content.domain.com) pointing to the same server, and setting a “Full URL path to files” in Admin panel, Settings, Media. It should look like “http://content.domain.com/wp-content/uploads”.

The really bad thing is, especially for a blog with lots of photos, that the images the WordPress blog server sends to the user, aren’t cached by his browser. In my case that means almost a megabyte of extra content sent to the client with every page refresh. If you want to get around this, you must create a “.htaccess” file directly in the root folder of your WordPress installation. And then add the following content:

# Add expire headers
<FilesMatch "\.(txt|js|css)$">
Header set Cache-Control "max-age=3600"
</FilesMatch>
<FilesMatch "\.(gif|jpg|jpeg|png|swf|ico)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>

The JavaScript and CSS gets cached a little shorter, only for an hour. The images are cached for a week, as Google recommends. If you want to change a image, that was already distributed to the user, make a new upload and redirect the old links to the newly uploaded file. Do not just replace the image, as users, who already viewed the photos, would not see any changes.

If you create “.htaccess” in “wp-content/uploads” the caching time can be made even higher (let’s say a month):

<FilesMatch "\.(gif|jpg|jpeg|png|ico)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>

Same as before, upload a new file and change the links, do not replace the content.

In this post I’ll write about another problem with a WordPress plugin. Blogger, for whom I’m managing the WordPress installation, had another wish for plugin customization. The installed WP-Table Reloaded plugin enables the user to create a table and add contents to it’s cells. But it isn’t able to sort the already added entries in the table or shifting the entries for inserting a new cell.

So the choice was to write another plugin or make a script that rearranges the entries by a specific condition, because the plugin supports the exporting and importing the HTML tables. I chose the letter one and wrote a Python3 script.

The exported HTML file can be reorganized in this ways: specify the new number of wanted columns, choose a horizontal (same as an input file) or vertical rendering and specify a regular expression for sorting the entries. Specifying “0” for sorting disables it and putting “(a)” for regular expression option sorts the elements by text between [a] HTML tags.

Here you can download the Table reorganization for WP-Table Reloaded WordPress plugin script.

Update on 6th of August: Corrected the rendering when multiple [a] tags exist in a single cell. Fixed vertical rendering when there the number of elements didn’t fill the whole columns*rows box.

On the 15th of May my girlfriend started complaining abut the number of new users with suspicious data that have registered on her blog. Looking at the Apache logs:

111.94.XXX.XXX – – [15/May/2011:07:48:57 +0200] “POST /wp-login.php?action=register HTTP/1.1” 200 2857 “http://www.domain.com/wp-login.php?action=register” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB6 (.NET CLR 3.5.30729)”

I found out, that all visits came from different IPs and didn’t have the referral specified.

The captcha under the registration form didn’t seem to stop the spammers. I had to find the quick fix, until the registration stops and spam starts to roll in. The closest solution I found was four years old, so I had to do a little update with the help of Apache documentation.

# Disable spammy registrations
RewriteCond %{REQUEST_URI} “^/wp-login.php$” [NC]
RewriteCond %{QUERY_STRING} “action=register” [NC]
RewriteCond %{HTTP_REFERER} “!^http://([^.]+.)?domain.com/.*$”
RewriteRule (.*) “/wp-login.php?” [L,R]

What that means is: if a user doesn’t visit “/wp-login.php?action=register” through clicking on a link on “domain.com”, he will be redirected to “/wp-login.php”.

Update: And don’t forget to delete the spammy users form the database. Backup your data and run select, before you use the delete query. I executed this through phpMyAdmin:

DELETE u, um
— SELECT distinct u.*
FROM wp_users u
left join wp_usermeta um on um.user_id = u.id
WHERE u.id between X and Y
— and u.id not in (‘A’, ‘B’, ‘C’)

To get the numbers for X and Y, use Browse on ‘wp_users’ table to get the first and the last unwanted registration. If you find a legit user (A, B, C, etc.) in this range, exclude it with appropriate filter.

Running a WordPress blog, with lots of plugins installed, requires a reasonably capable server. Running a custom theme and multiple plugins makes the response times skyrocket on an old processor like AMD Sempron 2600+. In my case, the time to generate a page, took from about 2 seconds. Looking at the performance monitor, I found that CPU is to blame. This can be mitigated my installing a cache plugin, but response to the visits, which create the cache files, are still slow.

So a new server, which is not already aged, must be bought. But which one to choose? Expensive server platform of cheaper desktop system? Intel or AMD? I was not looking for a high performance server for lots of simultaneous visitors. To process a few thousands visits per day it is only vital to process the PHP code for a single request as fast as possible. The 10 Mbit/s internet line, which I have, can never fully utilize a common hard drive or any other component.

For a server, certain hardware specifications must be met. That is hard drive redundancy (in my case RAID-1) and ECC memory for detecting/correcting memory faults. I rather be safe then sorry.

I decided to test different platforms by installing a backed-up blog on different computers I have access to – one installation was on the hosting server and others by installing a VirtualBox guest, running Ubuntu Server.

Here are the times (I made this calculations at the end of summer 2010), that it took generate the first page (monitored through Firebug):

Comparing the measured times of those three CPUs, I noticed the Core2 has much more cache available. So I measured the memory speed of Athlon X2:
L1 = 6688 MB/s, 64 kB
L2 = 3747 MB/s, 512 kB
RAM = 2607 MB/s, 2015 MB

This looks like a bad joke, comparing this to Intel’s Core2 Duo. So to stay on the safe side, I decided the CPU must have a lot of L3 cache. And the cache is a lot faster on the AMD Phenom II – measured on a friend’s computer:
L1 = 33000 MB/s
L2 = 10000 MB/s
L3 = 7000 MB/s
RAM = 4000 MB/s

Unfortunately, Intel i CPU doesn’t support ECC. And the Xeon was too pricey – as mentioned, at the end of summer 2010. And because of L3 cache and budget, Phenom II stays as the only choice. I have chosen a 6 core CPU, because of the web crawlers. But it seems that wasn’t necessary, because you can set the time between a “crawl” in robots.txt file. Looking a the statistics, using “atop”, a dual to quad core CPU would be enough. If I’d make a choice now, I would go for Intel Xeon E3 series – it’s relatively cheap, supports ECC and is probably significantly faster. This way you can enable more plugins. And how does the new Phenom II CPU perform? The page is generated in 370ms. Even better then I hoped it would.

If you look into the WordPress database, table wp_posts, you’ll see lots of records … much more then the actual displayed posts and attachments combined. The reason lies in revisions.

Among others, by default, every post save creates a revision. For the blog, I’m managing, the statistics are: 809 posts and 6287 revisions. And I must mention that I already deleted the revisions for first 391 posts. That means above 15 revisions per one post.

This does not present a big problem if you do not use a plugin such as Yet Another Related Posts Plugin. These related-posts plugins create a fulltext index on post title and content. And that means, if you want speedy searching for the related posts, big indexes – in my case 55 MB. And of that size, 75% is never used. And if didn’t have deleted some revisions before, the MBs and percentage would be even higher. And on webhosting servers this can present a problem because of high memory usage.

Unfortunately MySQL does not (yet) support partial indexing with which you could disable indexing of the revisions. Because of this revisions must be deleted. Some plugins are addressing this problem, but I was unable to find one, which deleted records older than certain number of days. It’s only all or nothing.

Searching the web (I’ll include the link if I stumble upon it again) I found a deletion code and added a time filter (use at your own risk):

DELETE p, tr, pm
-- SELECT p.*, tr.object_id, pm.meta_id
FROM wp_posts p
JOIN wp_posts pp ON pp.ID = p.post_parent
LEFT JOIN wp_term_relationships tr ON tr.object_id = p.ID
LEFT JOIN wp_postmeta pm ON pm.post_id = p.ID
WHERE p.post_type = 'revision'
AND pp.post_type = 'post'
AND pp.post_status = 'publish'
AND p.post_date < ADDDATE(CURDATE(), INTERVAL -2 MONTH)

This can then be used to make a cron job (Linux) or schedule (Windows) to periodically delete old revisions. Linux example: 'mysql --user=? --pass=? --execute "INSERT CODE HERE" DATABASE'.