[Ed Beck]

Hi Everyone,

Last week, one my pilot instructors told me that emails from OpenLab were being sent out late or not at all. This led me down a rabbithole that I wanted to share, but it also left an important question. Has anyone turned off WordPress’ Auto Cron Job, and instead created a real Cron job that runs on a schedule.

WordPress is designed in a hacky way, so that it can run on any type of hosting including hosting where the site owner can’t created an automated task. Instead of having automated tasks that run every 15 minutes, WordPress created a loophole where everytime someone visits the site, the cron would be forced to run. That means for sites with very low usage (like a Commons in the Box pilot that is only being used by a few classes!) the cron might not be running enough, and for a very busy site (like a mature Commons in a Box OpenLab) the cron might be running too often!

What happened to my instructor, is that she was using her external WordPress site that she had connected to Commons in a Box OpenLab. CBOX is supposed to check the RSS feeds and send out emails on a cron job. But since noone was creating foot traffic over on the main site (because they never got an email that there was a new post) things were just kind of breaking down.

I read a couple articles about disabling the automatic cron through a simple command in the WP Config, and this article seemed to have the best advice for MultiSites, because it explains how to run the cron not only for the main site, but also to collect all of the child sites as well and add them to the recurring job.

https://sabrinazeidan.com/fixing-wordpress-multisite-cron/

I just wanted to ask the community before I tried anything like this. Has anyone done this before with their OpenLab? Any advice before I start?

[Ryan Seslow]

Hi Ed,

Thanks for this! WordPress certainly has a few e-mail related issues, this is the first that I have read about this particular issue, Im going to default to Bree and Boone on this but will also see what I can find in the interim –

Ryan

[Boone Gorges]

> for a very busy site (like a mature Commons in a Box OpenLab) the cron might be running too often!

This isn’t quite true. WP’s pseudo-cron is throttled in such a way that it can’t be run “too often”, and in any case, the individual jobs will only be run on schedule. But your general point is correct: on low-traffic sites, certain jobs may not be triggered often enough.

It should be the case that RSS feeds across all sites are imported every hour, even if the individual group is not visited. See https://github.com/cuny-academic-commons/external-group-blogs/blob/master/loader.php#L31. There is additional code that triggers a refresh for a specific group when you visit that group, but it’s only used as a fallback. You might consider using a tool like WP-Crontrol to see whether the bp_groupblogs_cron job is scheduled and running properly. https://wordpress.org/plugins/wp-crontrol/

As for the specific suggestion about system cron, I have a couple of thoughts:
– The blog post you’ve linked is about multisite, and it works by sending regular pings to each site on the network. But the problem you’ve indicated here doesn’t have anything to do with secondary sites; instead, it’s related to traffic on the *main* site, and in particular, traffic to groups. So it doesn’t really address the underlying problem (though it does ensure that, at the very least, the *main* site’s cron jobs will be run once per hour – far less frequent than WP’s default, which is every couple of minutes, but important if you have a very low-traffic site)
– I have some concern about how the trigger.php script in your linked post will work at scale. It pulls up a list of all sites on a network, and pings each one, with a three second pause between loads. If each wp_remote_get() ping takes another 3 seconds, then on a 1000-site network we are looking at 6×1000 seconds. This is nearly two hours. So an hourly cron job will result in a never-ending ping cycle that only gets more overlapping as your network grows. In addition, most hosts will kill script execution after a certain amount of time, so your 6000-second script is unlikely to complete, and many sites will never be pinged.
– There’s a more sophisticated replacement for WP-cron called Cavalcade, which stores all tasks from across the network in a single queue (rather than separate queues for each site) and then uses a systemctl daemon to monitor and run these tasks. It scales very well and is resilient for just this sort of situation. However, it may not be compatible with all hosting setups. See https://github.com/humanmade/Cavalcade/

[Ed Beck]

Hi Boone,

I just wanted to let you know, that at least for external sites, that is not our experience at all. Specifically for external sites that are syncing through RSS, our lived experience is that until someone specifically visits that group, no emails or notifications go out.

For example:

geneseo.sunycreate.cloud is an OpenLab running the most recent version.

https://geneseo.sunycreate.cloud/groups/ed-beck/ is the url of a portfolio group.

Instead of subdomain, this group is connected to an external wordpress site. When I read your comments, I visited that site, and immediately 2 emails were sent out, my two most recent blog posts. Those posts were dated January 13th and March 7th. So I don’t think that group cron ran once between January and now until I visited that group page.

I will install the plugin you recommended, and see if there is another issue going on, but I wanted to let you know that we are seeing similar behavior on multiple OpenLab sites running the most recent version.

[Ed Beck]

Hi Boone,

After installing WP Crontrol, there are only 12 cron jobs on my OpenLab site:

Hook, Recurrence

wp_privacy_delete_old_export_files,  Once Hourly

wp_version_check, Twice Daily

wp_update_plugins, Twice Daily

wp_update_themes, Twice Daily

update_netowrk_counts, Twice Daily

ass_digest_event, Once Daily

wp_site_health_scheduled_check, Once Weekly

recovery_mode_clean_expired_keys, Once Daily

wp_scheduled_delete, Once Daily

delete_expired_transients, Once Daily

wp_scheduled_auto_draft_delete, Once Daily

ass_digest_event_weekly, Once Weekly

 

Can you confirm that I should be seeing more. All but two are the core wordpress jobs, and I do not see any Buddy Press jobs added.

[Boone Gorges]

Thanks, Ed. It looks like the cron job is not scheduled. It would be called bp_groupblogs_cron. If you want to create it manually using wp-crontrol, it should work. /wp-admin/tools.php?page=crontrol_admin_manage_page&action=new-cron. Set it to ‘hourly’.

[Ed Beck]

Do you need a separate bug report or issue on Github that this particular cron job isn’t working by default? Are there any other OpenLab cron jobs that are missing from this list?

For the short term, I will add it manually from WP Crontrol.

[Boone Gorges]

Thanks, Ed. I’ve created a ticket to track the issue. https://github.com/cuny-academic-commons/commons-in-a-box/issues/347

[Author]

Posts