WordPress Missed Schedule Posts

I just discovered that scheduled posts on my Riddles and Brain Teasers site hadn’t been working as far back as last year. Whoops! On the bright side, today saw a flurry of additions.

It’s a little odd that WordPress can tell you it missed publishing a scheduled post, but still doesn’t publish it. It’s like a butler coming upstairs to tell you he forgot to bring you something instead of just bringing it.

I spent quite a bit of time digging in to why it wasn’t working and eventually discovered the culprit was W3 Total Cache’s database cache. Disabling it solved the problem.

But I had already started using a real cron job on the server and I chose to leave it. It means WordPress doesn’t have to check for scheduled tasks on every request, speeding up page loads a little.

To recap, if your scheduled posts aren’t publishing and you’re using W3 Total Cache, you can just disable the database cache. Or, if you want to use a real cron job (which I already do for numerous other tasks), follow the steps below.

1. Add this define to your wp-config.php file.

Anywhere will work. I added it after the DB_COLLATE define, around line 36.

define('DISABLE_WP_CRON', 'true');

2. Create a cron job

If you’re not familiar with cron, it’s a task scheduler on Linux / Unix systems. Most web hosts will have it somewhere in their control panel. If not and you have shell access, run cron directly with crontab -e and add these two lines.

# Run every hour on the hour
0 * * * * wget --quiet --output-document=/dev/null "https://example.com/wp-cron.php?doing_wp_cron"

This will load WordPress’ wp-cron.php file every hour.

And now you can can get back to scheduling your posts.

Friendly Neighborhood Reminder To Optimize Your Images

My daughter is a big fan of Daniel Tiger’s Neighborhood and today I was curious who the voice actor was. I found the answer on Angela’s Clues (an 11-year-old named Jake Beale). I also found some pages loading really slowly.

I clicked my Google Pagespeed bookmarklet on the projects page and it got the lowest score I’ve ever seen.

12 out of 100 on Google Pagespeed

The #1 suggestion was to optimize images, claiming the images could be reduced by a stunning 3.8 MB. Sure enough, I tried optimizing one of the files. It started at 765 KB and after PNGGauntlet finished, the image was a mere 106 KB, 14% of its former size.

And there’s even better news if you use WordPress. Instead of optimizing images manually, install the EWWW Image Optimizer and it will not only optimize images you upload, but it can also optimize all of the images you already have on your site.

Speedy delivery isn’t just for the mail. Make Mr. McFeely proud.

Go vs Node vs PHP vs HHVM and WordPress Benchmarks

I have been impressed with the performance I’m seeing with Vultr VPSes, so I decided to do an experiment to see what the maximum performance could be.

I created a simple Hello world program in Go, Node.js and PHP, then tested them with ApacheBench 2.3.

Here are the three programs I used.

Go 1.4

package main

import (

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprint(w, "Hello world from Go")

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":4000", nil)

Node 0.10.33

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World from node');
}).listen(3000, '');

PHP 5.6.6 with Opcache enabled

echo "Hello world from PHP";

These benchmarks were run on a Vultr server with 768MB of RAM and a single 3.4MHz CPU with nginx 1.6.2. To perform the benchmarks I ran the following ab command three times to warm up, then I ran three more runs and averaged the second group of three.

ab -q -n 5000 -c 25 localhost/

WordPress had WP Super Cache enabled. Without it WordPress was getting around 30 requests/second.

Without further ado, here are the results. Higher is better.

Benchmark Results

Here’s the data in tabular form

Test TypeRequests per second
WordPress (PHP)854
WordPress (HHVM)1,259

Go is the clear winner, but I was surprised to see how close HHVM was to Node. I was also impressed that with HHVM, WordPress was approaching a simple PHP script. Of course that was with the caching plugin in place.

I planned to include the results of nginx serving a static file in the chart, but it made the other results hard to distinguish at a whopping 17,791 requests/second.

Lastly, I was concerned to find that sometimes the HHVM results went into the toilet. Most of the other benchmarks were fairly stable, but HHVM would average over 3,000 on the first three runs, then drop off on the next three. In one case it hit around 700, so something was clearly wrong, but I’m not sure what. I had already fixed the nf_conntrack_max issue, but it could be something else along the same lines.

My takeaway is it’s a great time to be a web developer. Getting WordPress to hit over a thousand requests a second on a $5/month server is impressive. And it’s only getting faster!

Wildcard Site for Laravel Homestead

Laravel is a fantastic PHP framework. Homestead makes it even easier to do Laravel development. It’s basically a prebuilt Vagrant VM so you can build Laravel projects without having to worry about setting up the server environment first.

If you’re not familiar with Vagrant, it’s another extremely useful tool to create easily reproducible development environments. You create a Vagrantfile, which serves as a recipe for a virtual machine. You can give that single text file to another developer or copy it to your laptop if you’re traveling, then run vagrant up and you will get an identical environment.

Now back to Homestead.

A minor nuisance with Homestead is that you need to configure a new site configuration for each project you’re developing. You can do this in one of two ways. First, you can add them to the Homestead.yaml. Second, you can run the serve script in a running Homestead VM. In either case, you also have to add an entry for the new site in your hosts file.

Before I started using Homestead, I used a vagrant box that I had configured to use regular expressions in nginx. This allowed me to have a single nginx configuration for all my projects. It was really convenient, but I thought it wouldn’t work with Homestead. I was wrong.

Let’s say you use the format of project_name.app for your Laravel projects. For example, if your project was named waldo, you would browse to waldo.app (after having updated your hosts file) to see the site. Normally, you’d need to have something like this in your Homestead.yaml:

    - map: (path to your Laravel projects)
      to: /home/vagrant/Code

    - map: waldo.app
      to: /home/vagrant/Code/waldo/public

    - map: franklin.app
      to: /home/vagrant/Code/franklin/public

    - map: henry.app
      to: /home/vagrant/Code/henry/public

    - map: phil.app
      to: /home/vagrant/Code/phil/public

And so on, for each project. Instead, you can use this:

    - map: (path to your Laravel projects)
      to: /home/vagrant/Code

    - map: '~^(?<project>.+)\.app$'
      to: /home/vagrant/Code/\$project/public

And it will work for any number of sites as long as you use the same project_name.app format.

The file that’s created in /etc/nginx/sites-available won’t look pretty, but it removes a step from your development process. And if you’re anything like me, efficiency is bliss.

Windows 7 Showing the Wrong Thumbnail

I have a few avatar pictures that I use for web sites I join. We had some new family pictures taken for Christmas, and I cropped and resized some of them to make new avatar pictures. But whenever I used them, Windows Explorer continued to show the entire image as the thumbnail. Windows caches thumbnail images for performance reasons, so it doesn’t have to regenerate them every time you visit a folder of pictures. I assumed the cache was out of date.

One deceptively simple solution was to open Windows Explorer to the folder containing the images and change the view. You can do this by right-clicking inside the folder and selecting View, then Large or Medium icons (whichever one isn’t already selected). This worked, but when I switched back to the previous view, the outdated thumbnail remained.

So I took a more severe approach. According to this Microsoft Answers post, the thumbnail cache is stored in %LocalAppData%\Microsoft\Windows\Explorer. To clear it out, I deleted all of the thumbcache_*.db files.

But this didn’t solve the problem either. When the thumbnail cache was regenerated, it still had the older image! If I had kept reading the thread I linked to above, I would have realized this sooner. JPEG files can store a thumbnail in the EXIF data. And the thumbnail wasn’t updated after I cropped and resized the image. I confirmed this using MiTeC’s Photo View application.

Don’t forget about this embedded thumbnail if you ever post a cropped photo that has anything sensitive or private. In 2003, Cat Schwartz made this mistake, posting a headshot of herself that happened to be cropped from a photo of her sans clothes.

But back to the problem at hand. The final solution was to use Stripper (great name) to remove the EXIF data. Just so you’re aware, when you drag an image onto the Stripper window, it will overwrite the original image with the stripped version without any confirmation. If you want to keep the original, make a copy first.

And the way to stop this from happening in the future is to use an image editor that updates or removes the EXIF thumbnail when you crop the image. I emailed FastStone Image Viewer support to see if there’s a way to do this that I’m not seeing, and if not, to fix it.