Git-updater: How often does cron run?

[uturnr]

I saw mention in an issue that refresh cache needs to be used sometimes as the cache is only updated if there were changes in the last 12 hours. Is this correct?

I thought it would be very useful to include this information in the wiki, on the Background Processing page, but I wasn't sure if this number was correct or how to word it ("The cron runs every 12 hours"? or "The updater cache only updates if there were changes in the last 12 hours"?)

[afragen]

The cache lasts for 12 hours before it expires. WP-Cron runs all the time, or at least every several page loads. The expired cache is refreshed via WP-Cron.

I added that info to the wiki.

[afragen]

https://github.com/afragen/github-updater/wiki/Settings#refreshing-cache

[chesio]

WP-Cron runs all the time, or at least every several page loads. The expired cache is refreshed via WP-Cron.

Since this boggled me a bit recently, I'd like to ask for a clarification: what if I don't log into the WP admin at all? Is the cache refreshed anyway? I ask because from what I have observed the cron jobs that refresh the cache seem to be set only when one of the whitelisted pages is visited. Or if there is any interaction with WP-CLI.

It boggled me, because this works slightly different from how WordPress checks for new plugin/theme/core versions in the background - the related cron jobs are set to run every 12 hours regardless of any admin activity. Is there a reason why GitHub Updater does not check for updates the same way?

[afragen]

GitHub Updater only runs for privileged users. This is a security measure as many of it's functions are not appropriate for non-privileged users.

I will look into whether the update checking is sufficiently separate from other functions to allow this to run outside of this check.

[afragen]

@chesio I am testing locally allowing GitHub Updater to run all the time but only show the Settings page as appropriate. So far, so good.

I will push this to the develop branch and you can use the branch switching to test.

[chesio]

@afragen, sorry for the delay and thank you! I'll test the develop branch and report back.

[chesio]

So I had a look and it works differently from what I was hinting at.

My idea is to have a cron job that runs periodically (let's say twice a day) and updates the remote plugin/theme cache and does so independently from any backend or WP-CLI interactions. So even if I do not visit backend of my website for a week, the caches are kept up to date.

Why I'm interested in such functionality:

1. It mimics what WordPress does - WordPress checks for plugin/theme/core updates in the background.
2. I can be notified when there is a new update to GitHub hosted plugin.
3. I can let the GitHub hosted plugins auto-update using auto_update_plugin hook.

The points 2. and 3. above already work fine, but I have to visit the backend first to poke GitHub Updater to update the caches, which kind of defeats the purpose.

I had a look in the code and I see that this would be rather different use of WP-Cron than what GitHub Updater does now. I understand that current use of WP-Cron has been added as replacement to real-time requests that can inherently be too slow for smooth backend experience.

Anyway, it would be a nice improvement :-)

[afragen]

Unfortunately WP-Cron isn't a real cron. It is dependent upon a user, I believe any user, visiting your site so that it can be triggered. If no one ever visits the site, WP-Cron will never be triggered.

The latest changes in the develop branch should allow GHU update checking any time WP-Cron runs and there is a waiting event. The changes should mean an admin user doesn't need to visit the site, anyone visiting the site should work.

I'm hoping the current changes in develop solve all of the above issues.

[chesio]

The latest changes in the develop branch should allow GHU update checking any time WP-Cron runs and there is a waiting event. The changes should mean an admin user doesn't need to visit the site, anyone visiting the site should work.

Sounds like this should solve my issue, I'll check again and get back to you.

[afragen]

Question: I've added in an early exit so that if the site is set to bypass wp-cron by using the github_updater_disable_wpcron filter, non-privileged users won't see a huge impact by only checking API calls for privileged users. Using the support plugin will invoke this.

This will mean that the API will only get called if an admin user is on the site.

Does that seem reasonable?

https://github.com/afragen/github-updater/commit/eb47e816c90d32b2150a01d563ee5b69be72f986

[afragen]

Or should I just check for is_admin() and not a privileged user?

https://github.com/afragen/github-updater/commit/4efccf8afd7013b771165e1fc7242f8c9e5b3014

[chesio]

I think WP-CLI users that have the filter github_updater_disable_wpcron set to true won't be able to run the method because of is_admin() check, but I'm just guessing here...

EDIT: Running is_admin() within WP-CLI shell returns false.

[afragen]

Back to only impacting _privileged_ users if bypassing WP-Cron. I think this is an acceptable compromise.

[afragen]

Fixed in https://github.com/afragen/github-updater/tree/9.1.0