Why my Cron wasn’t running on Siteground

I had a lot of trouble recently scheduling a cron job using Siteground’s control console and the wget command.

In case you are unsure what I’m talking about, a Cron Job is basically a way of running a command from your computer, or in the web host’s case, the cpanel.

There are so many commands for it, but a wget is basically a way of downloading a resource online. Used creatively, it can also trigger a page visit which runs WordPress’s own scheduling system.

A wget command looks something like this:

wget https://example.com

The following command would download the index.html page of example.com to your system or the host’s file manager.

There is a lot of advice out there on how to run one, but it all came down with quoting the url to keep it intact.

If you are looking for the short answer, this is a basic command that foolproofed the url input for me:

wget “https://example.com”

You see, when the url contains numbers, the quotes become necessary.

Of course it runs deeper than that, meaning you also use parameters (optional) to suppress output.

The Scheduling Job

Let’s look at my example of why I used the Cron and why you may want to as well.

On Siteground, you can find the “Manage Cron Job” areas here:

I needed to run a command for one of my client’s WordPress sites. It is an ecommerce site and we are using WP All Import.

The plugin basically takes a spreadsheet as an input, and updates the woocommerce products based on the values in the spreadsheet.

So yes, while I could have done this manually, it would mean logging into WordPress every morning at 6am and clicking a button.

And that’s why I decided to run a cron job to automate the process – as supported by the plugin itself.

Instructions

Here are the instructions from WP All Import.

The trigger URL will look something like this:

http://YOUR-WEBSITE.com/wp-load.php?import_key=[YOUR_SECRET_KEY]&import_id=[YOUR_IMPORT_ID]&action=trigger

The processing URL will look something like this:

http://YOUR-WEBSITE.com/wp-load.php?import_key=[YOUR_SECRET_KEY]&import_id=[YOUR_IMPORT_ID]&action=processing

Of course, I added wget to the start of it to try and run it.

What I tried…

When I substituted the values in between the [ ] in capital letters, I got my url. It worked in the browser and processed it there. So I knew there was nothing wrong with the script.

But it didn’t process it when using the wget command on siteground.

The command I originally used,  going by a plethora of instructions, was:

WGET -q -O http://YOUR-WEBSITE.com/wp-load.php?import_key=[YOUR_SECRET_KEY]&import_id=[YOUR_IMPORT_ID]&action=trigger > /dev/null 2>&1

Here’s an example of what it may have looked like:

wget -q -O  http://example..com/wp-load.php?import_key=abcdefg&import_id=1&action=trigger > /dev/null 2>&1

It was frustrating. It just wasn’t running!

I knew it wasn’t the fault of SiteGround, because the php command I wrote to suck in the spreadsheet worked just fine on a cron.

And it wasn’t the fetch url that was the problem, because it worked too in the browser.

So I approached my father to ask for his advice.

My Father’s Advice

Dad said to try running the command line using SSH. That is a command line console for Linux.

Here is an pic of a windows command line. Linux has a similar thing. That big black screen where you type in your cryptic commands.

So I generated the keys using putty and logged in.

It was an eye opening exercise seeing the many failures happening in front of my eyes, and also good not having to wait until the task ran or failed via the cron job.

It wasn’t until Dad pointed out the feedback url that I realised something was wrong.

The number had been omitted.

Instead of returning http://example.com/wp-load.php?import_key=abcdefg&import_id=1&action=trigger it returned http://example..com/wp-load.php?import_key=abcdefg&import_id=

Apparently numbers on the command line need “escaping”. So I tried quoting the entire url and voila, it worked.

Incidentally, I also learned that the -O had to have a parameter or it would fail too.

So in the end the command looked something like this:

Wget -q -O”./delete-me.txt”  “http://example.com/wp-load.php?import_key=abcdefg&import_id=1&action=trigger” > /dev/null 2>&1

I hope this helps anybody else struggling to run a command after going through all the other pieces of advice online but still having trouble.

2 thoughts on “Why my Cron wasn’t running on Siteground”

  1. Many thanks for helping SiteGround customers out of their misery! While your solution helped me on the right track, my eventual solution presented itself once I learned of SG’s Caching. SiteGround caches requests, so if your cron executed wget of a URL, it won’t do so again for 24 hours. The solution is to add a timestamp to the request. So: cron.php?cronid=`date +\%Y\%m\%d\%H\%M\%S`” > /dev/null

    Hope this helps anyone else who comes across this page!

    1. Many thanks for your advice there, David.

      Ah yes. I am surprised they are caching the wp-cron file. Good catch on the timestamp.

      I also know that Siteground does not want you to run a server crontab twice within a 30min window. But I have sinced moved my clients to Cloudways. Again I appreciate your tips!

Leave a Comment

Your email address will not be published. Required fields are marked *

Download our must have tools for your WordPress freelancing business