Fixing my blog robot

Marcus Wong — Sun, 24 May 2015 21:30:54 +0000

One thing you might not know about this site is that I don’t actually wake up each morning and type up a new blog post – I actually write them ahead of time, and set them up to be published at a future time. Unfortunately this doesn’t always work, such as what happened to me a few weeks ago.

I use WordPress to host my various blog sites, and it has a feature called “scheduled posts” – set the time you want the post to go online, and in theory they’ll magically appear in the future, without any manual intervention.

For this magic to happen, WordPress has to regularly check what time it is, check if any posts are due to be published, and if so, publish them – a process that is triggered in two different ways:

run the check every time someone visits the site, or
run the check based on a cron job (scheduled task)

The first option is unreliable because it delays page load times, and you can’t count on people visiting a low traffic web site, so the second option is what I put in place when setting up my server.

I first encountered troubles with my scheduled posts in early April.

Why has my blog robot been broken all week?

— Marcus Wong (@aussiewongm) April 2, 2015

My initial theory was that a recently installed WordPress plugin was to blame, running at the same time as the scheduled post logic and slowing it down.

Looks like my blog robot is working again (I think the ‘Broken Link Checker’ plugin was making the WordPress cron page time out)

— Marcus Wong (@aussiewongm) April 10, 2015

I removed the plugin, and scheduled posts on this site started to work again – I thought it was all fixed.

However, a few weeks later I discovered that new entries for my Hong Kong blog were missing in action.

Turns out my blog robot still isn’t working right, as it missed a post from April 8th.

— Marcus Wong (@aussiewongm) April 14, 2015

I took a look the the config for my cron job, and it seemed to be correct.

*/2 * * * * curl http://example.com/wp-cron.php > /dev/null 2>&1

I hit the URL featured in the command, and it triggered the publication of a new blog post – so everything good on that front!

I then dug a bit deeper, and ran the curl command directly on my server.

user@server:~$ curl http://example.com/wp-cron.php 301 Moved Permanently

Moved Permanently

The document has moved here.

Apache Server at example.com Port 80

Bingo – I had found my problem!

Turns out I had previous added a non-www to www redirect for the website in question via a new .htaccess rule – and by default curl doesn’t follow HTTP redirects.

The end result was my cron job hitting a URL, finding a redirect but not following it, resulting in the PHP code never being executed, and my future dated blog posts laying in limbo.

my fix was simple – update my cron job to hit the www. version of the URL, and since then, my future dated blog posts have all appeared on the days they were supposed to.

About the lead photo

The train in the lead photo is the Melbourne-Sydney XPT – on 11 July 2014 it derailed near North Melbourne Station due to a brand new but poorly designed turnout.

Post retrieved by 35.215.163.46 using

The post Fixing my blog robot appeared first on Waking up in Geelong.

Backup your WordPress database with a cron job

Marcus Wong — Mon, 24 Sep 2012 21:30:32 +0000

I run this blog with WordPress – today it powers one of every 6 websites on the Internet. I use a shared hosting account to run the site so I have total control, but it also means I need to make sure everything gets backed up regularly so if my hosting provider derails it, I can quickly get things… back on track.

The easiest way to backup a self-hosted WordPress blog is by using the “WP-DBManager” plugin – install it via the control panel, tick a few boxes, and a backup of your entire database gets sent to you via email every night, giving you a way to get your website content back if something goes wrong.

For me WP-DBManager did everything it promised, at least until my hosting provider changed their security settings and disabled a number of functions that the backup plugin needed to work, leaving me with a failing backup job and this error message:

Checking PHP Functions (passthru(), system() and exec()) …
passthru() disabled.
system() disabled.
exec() disabled.

I’m sorry, your server administrator has disabled passthru(), system() and exec(), thus you cannot use this backup script. You may consider using the default WordPress database backup script instead.

Unfortunately for me, I didn’t realise my backups weren’t working until a few weeks after the server config change was made, when I discovered that my nightly emails only contained an empty backup file!

With the easy to use WP-DBManager option ruled out, I turned to a cron job – a small program that runs on your server, based on a regular schedule you define. Thankfully someone had already come up with a script to do just what I wanted to do – you can find his instructions at http://www.tamba2.org.uk/wordpress/cron/.

Once I added the above cron job to my server I ran into a major issue – the ‘mutt’ command for sending email was not available to me, so I needed to jump into the world of shell scripting to find another way to do the same thing. This is the replacement script I came up with:

#Set the 4 variables
#Replace what is AFTER the = with the information from your wp-config.php file
#That's your information on the right okay ?

DBNAME=DB_NAME
DBPASS=DB_PASSWORD
DBUSER=DB_USER

#Keep the " around your address
EMAIL="you@email.com"

DATE=`date +%Y%m%d-%H%M%S`
PARTDATE=`date +%Y-%m-%d`

mysqldump -u $DBUSER -p$DBPASS $DBNAME > $DBNAME-$DATE.sql
gzip $DBNAME-$DATE.sql
uuencode $DBNAME-$DATE.sql.gz $DBNAME-backup-$DATE.sql.gz | mail -s "MySQL backup for $PARTDATE" $EMAIL
rm $DBNAME-$DATE.sql.gz

My shell script does much the same thing as the original script I based it upon, except that the email you get isn’t anywhere as nice looking – just a subject line and an attached backup file.

Fill in your own values for the first four variables, save the script as a file, and then follow the instructions back at http://www.tamba2.org.uk/wordpress/cron/ to get it running as a Cron job on your own server.

I setup my backups to run once daily, and since I’ve set it up the emails have been successfully arriving in my inbox, with a gzipped SQL script as the attachment. Let’s hope I never have a need to restore them!

And a sidenote…

The derailed V/Line train picture above was the aftermath of a tree falling over the tracks at Stonyford, Victoria back in 2009. No-one was killed or seriously injured when the leading locomotive ended up sideways, with the second locomotive and a few of the carriages coming off the rails – more details in the accident investigation report.

Post retrieved by 35.215.163.46 using

The post Backup your WordPress database with a cron job appeared first on Waking up in Geelong.

WordPress Archives - Waking up in Geelong

Fixing my blog robot

Moved Permanently

Backup your WordPress database with a cron job