🔔 Please Note: iCal Importer is no longer actively maintained, and has been replaced with Event Aggregator.
Most folks with an iCal Importer license will have an Event Aggregator license in their account for free automatically.
To learn more about Event Aggregator, check out FAQs here. There’s a general guide about moving to Event Aggregator here, and a collection of more specific guides here. You can also drop by our help desk any time with questions.
We previously looked at saved recurring imports with the iCal Importer, which is where you tell the plugin to periodically and automatically import events from an iCal feed.
Essentially this is what might be described as a background task and it frees you from the burden of manually triggering further imports from the same feed.
In this post we review how this works and what to look for if you fear that these scheduled tasks are not actually running as expected.
Behind the scenes, we use the scheduled event facilities provided by WordPress to handle these background tasks or “cron jobs”.
In most cases this is perfectly reliable – but on occasion they may appear to run marginally later than expected or not at all. To understand why, let’s look at two of the most common ways WordPress scheduled events actually run:
- They may be triggered by a “true” cron job, managed by a job scheduler bundled with your server’s operating system – this is by far the most reliable setup
- Or, in the absence of the above, WordPress may attempt to simulate cron tasks
Setting up the first method is beyond the scope of this post, but many guides exist on the internet describing the basic process: if in doubt, ask your web host for help!
The great advantage of a “true” cron job is that these generally run like clockwork – it is all but guaranteed that WordPress will run at whatever interval you dictate when using this method.
In the second method, every time WordPress loads (such as if a visitor to your website comes along) it checks to see if any scheduled events are waiting to run and – if there are – it then attempts to process them.
This is essentially a just-in-time approach and works well so long as you have a moderately busy website – in fact, even if you have almost no traffic it still works in a tolerable fashion, since as soon as someone does come along and access the site, it will process the waiting tasks at that point.
This system isn’t always ideal, but in this case – where we are importing from an iCal feed – it will generally suffice. However it does mean that there may appear to be a delay before the events appear on your site. Here’s why:
Let’s imagine you’ve asked the iCal Importer to run every half hour and WordPress is using simulated cron jobs. You might expect that by the time 5hrs have passed, the importer will have checked the iCal feed something like 10 times. In fact, if the site received no traffic, the importer will not have run – but, as soon as you (or someone else) does visit it, it will run the import task at that point.
How quickly an iCal feed can be loaded and new events imported depends largely on how quickly the source website responds so, in this scenario, it may seem like there is a further delay taking place. This is to be expected and if it proves to be too much of a problem the best advice is to investigate moving to use of “true” cron jobs.
It still isn’t working!
WordPress scheduled tasks, not surprisingly, run within the WordPress environment. That means they are potentially subject to some of the same problems that can impact regular page loads, such as plugin and theme conflicts. Regardless of which way your WordPress site is implementing cron jobs – simulated or real – it is often worth testing for conflicts if you are positive that saved recurring imports are not taking place.
If you’ve ruled out a conflict and are using a “true” cron job, it is further worth investigating how that is actually implemented and, once again, this may be something where it is worth checking in with your web host and working with their own support gurus.
For example, it is not uncommon for the cron job to work by firing off a new HTTP request (a bit like trying to access example.com/wp-cron.php from your web browser) and there are cases where servers are configured to block these requests when they are made from the same machine.
I’m still stuck
There are a number of useful and freely available plugins which can help to tweak, tune and generally manage WordPress cron tasks, so you might investigate adding one to your site.
If even those don’t help – fear not! You can always approach our own support team for further assistance!
Good luck 🙂