Why automation in WordPress is unreliable and how to fix it
The limitations of the WordPress wp_cron() function are well documented, but instead of just ‘piling on’ I’m going to explain in detail how WordPress handles automation, why it took so long for any Rocket Apps product to have any sort of automation, and how you can easily fix the automation on your own website.
How a typical cron job works
A cron job is supposed to happen at the operating system level, like a unix based OS for example, to perform specified tasks at a specified time or regular intervals.
However, because your typical WordPress instance doesn’t (and shouldn’t) have the required privileges to the OS it’s installed on, the WordPress Development Team have had to come up with their own solution – enter the much derided wp_cron() function.
What the WordPress Dev Team has attempted is admirable: provide an agnostic solution to web based automation regardless of if you’re hosted on a Windows or Unix server. However without access to the OS cron functionality they have had to get creative, with the result being this ironic limitation: in order for any automation in WordPress to work, it needs to be triggered by something that is not automated (the luck of having a random person hit your website). And this is where wp_cron() gets its ‘notoriously unreliable’ reputation from.
To demonstrate: If your website has low traffic, and you’ve got a post scheduled to get published at 6am, wp_cron() won’t trigger and publish your post unless someone hits your website at 6am or later. If your website did not get any traffic until later, let’s say 7am for example, then wp_cron() will be triggered and publish any posts that were scheduled (an hour late in this case). This might not be such a big deal for some websites owners who are happy to have a post automatically publish ‘roughly’ around the time they wanted. But for others, particularly where timing is critical, this might not be acceptable.
In the context of Rocket Apps products this introduces some obvious problems.
For Task Rocket users you may want a task to be scheduled for one or more team members at a particular time, but the task may not even get sent to them simply because nobody was logged in and navigating from page to page at the scheduled time. My personal workflow is similar, and I could be on a single view in Task Rocket (often it’s a project or single task page) for days before I need to navigate elsewhere.
For Invoice Rocket users, you may want to have a recurring invoice sent to a client on the last day of every month for example, but unless someone has actually logged in on (or after) that day then the invoice won’t get sent to your client until later, who in turn may miss out on paying you on time.
How to get around this limitation
There have been many work-arounds proposed to this problem, some involving disabling the wp_cron() function entirely and following up with some server side configuration. While this is fine for some, thankfully there is an easier solution that requires almost no technical knowledge, can be achieved in a few minutes, and with absolutely no changes to your WordPress website.
As I’ve mentioned earlier all that is required for wp_cron() to fire is for anyone to visit your website near or at the time you have something scheduled, in other words, a HTTP(s) request. With this in mind all you need to do is use a 3rd party service that checks your website for downtime. I use Uptime Robot which is free (for up to 50 websites) and simply sends a HTTP(s) request every five minutes to the domain I have my instance of Invoice Rocket hosted.
With this in place, the Email Report add-on I use with Invoice Rocket that is scheduled to email me a report every day at 10:30pm, actually sends me an email report 5 minutes later even if I’ve never logged in or visited the website in days. This is easily acceptable. I’ve been using this solution for about 3 months now without fail, and am now confident to start introducing more automated functionality into Rocket Apps products, with the caveat that a solution like the one mentioned above is in use. As an additional bonus you’ll also get notified if your site goes down, because that’s what the service is actually intended for.
Speaking of recurring invoices
I mentioned recurring invoices in the example earlier as a lousy segue into this announcement: recurring invoices is next on the road map for Invoice Rocket.
Right now I’m finishing work on the Vehicle Log and eWay Payment Gateway add-ons and once they are out in the wild work will begin on recurring invoices, which – just thinking out aloud – could possibly lead to recurring expenses for the Expenses add-on.
If you’re an Invoice Rocket user and would like to get in on a beta build during development when that time comes, you know where to find me.
wProject has launched and you can get it right now
As of today wProject is available for purchase, and there are implications for Task Rocket.Keep reading
wProject feature demonstration
Subtasks are arguably the biggest deal. As is often with any task, there can be a number of smaller tasks that need to be accomplished within it.Keep reading
Introducing wProject and what it means for Task Rocket
It’s been is a long time coming. Specifically, wProject is intended to be the successor to Task Rocket.Keep reading
Open Graphite Pro now has an enhanced Slack sharing option
With the release of 2.0.0 today, Open Graphite Pro has a new option to enable enhanced Slack sharing.Keep reading
When responsive design is not enough, wp_is_mobile() to the rescue.
While using responsive design for mobile presentation is the default philosophy for any web developer who cares about the web, it doesn’t solve some of the other problems.Keep reading
Task Rocket June Updates (v188.8.131.52)
Task Rocket has received an update to the contextual secondary navigation user interface. It’s about time.Keep reading