Auto-cache cron event removed?

[MarioKnight]

I just updated to ZenCache pro v151114 earlier. As I have done with any plugin updates, I went to call the manual cron event _cron_zencache_auto_cache to rebuild the site's cache following the cache being cleared after plugin updates. I did this today for the first time after installing the new version, and I received the following message:

Error: Invalid cron event '_cron_zencache_auto_cache'

I was thinking/hoping this may have moved to a different event, however I only see the _cron_zencache_cleanup event associated with ZenCache Pro where a direct call does not rebuild the cache. It has also been a few hours, and I am not seeing the cache in a status I would expect to see following a rebuild.

[MarioKnight]

This seems like #603 could be related, however this also seems to be an isolated incident. I only rolled this on my main personal site yesterday which is why I reported, however today I started rolling this out to the other sites on my personal server and a couple of servers with client sites at work, and all sites I randomly checked had the _cron_zencache_auto_cache cron event intact after the update. Would there be another way to get this event re-listed without restoring the default settings that the linked issue report suggests?

[MarioKnight]

To add, when I attempt to re-create the cron event in two different scenarios (WP-CLI and a PHP script), while I can get _cron_zencache_auto_cache back in the event list, actually running the event does not have the cache actually being rebuild, even though I get a success message. I've removed it pending any advice that can be given.

[raamdev]

@MarioKnight Interesting. Thanks for the report. This does sound like #603 might be related, but it could also be something else. Here are a few questions:

• How did you install the update? Via the built-in Pro Updater? Is this how you updated the other sites as well?
• Are all these sites running the same version of PHP? (You mentioned the cron event showing up fine on "other sites on my personal server", so I assume they're running the exact same PHP/server config, but I want to be sure so we can rule out a server config. issue.)
• Are you running a lot of other plugins on your personal site? (It's possible a plugin conflict introduced this issue--or even a theme conflict.)
• Are all the sites running the same version of WordPress?

Note that you can backup your ZenCache configuration via ZenCache → Plugin Options → Import/Export Options, then click Restore to reset your configuration and see if that makes the cron even reappear, and then reapply your configuration by importing the saved options.

[jaswrks]

@raamdev I think this issue (and perhaps #603 too) are both related to the bug I outlined for Kristine in this PR. I just stumbled into this while reviewing her work. See: wpsharks/comet-cache-pro#174 (comment)

In short, __NAMESPACE__ in the CRON event schedule should be set to GLOBAL_NS.

[MarioKnight]

I'm sorry for the delay, it's been a hectic couple of days.

• All updates were installed via the Pro Updater. I hope to script something at some point, but have not started to do so yet.
• My personal server and the newest work server run 5.6.15, two of the other work servers run 5.4.45.
• I have tried to not use too many, I don't believe it is a conflict, but I won't rule it out just yet.
• Yes, all are on the latest 4.3.1 core release.

Other tidbits that may or may not make a difference include me going from 5.4.45 to 5.6.15 on my personal server same days before the update. The week before, I followed the guide on your site to use RAM for the cache files, so this was the first update done following that change. I attempted to use the export/import described, which did bring back the event, but did not work when called, which I am doing via WP-CLI. At one point in the update, I got a message about my .htaccess similar to #617, however that only happened once and I have not been able to get that to come up again to add anything worth mentioning in that issue report. I also noticed that most of the time I click to save changes, I am now getting a generic 500 error, however the changes seem to save.

[raamdev]

I'm copying @patdumond's comment from #603 so that we can keep all reports for this in one place (this issue has more updates, so I'm favoring keeping this one open):

---

@patdumond writes...

Reference: https://websharks.zendesk.com/agent/tickets/9223

If ZenCache Pro is deactivated from the WordPress Plugins panel autocache job is removed from WP-Cron, disabling Auto-Cache.

Steps to reproduce:

1. Install WP-Crontrol plugin.
2. Wait about 5 minutes to be sure you see the cron job for the Auto-cache WordPress Dashboard → Tools → Cron Events.
3. Deactivate ZenCache Pro from the Plugins panel.
4. Wait to verify that Autocache entry did not reappear in the Cron Events panel.

I waited an hour and it didn't reappear. So I went back into ZenCache Options, checked that the Auto-Cache was enabled and "Saved All Settings" just to be sure. Waited another 15 minutes and nothing. It only took 5 minutes for it to disappear so 5 minutes should have been enough for it to reappear.

*** Temporary Workaround

From WordPress Dashboard → ZenCache → ZenCache Options click the Restore button at the top of the screen to force the CRON to be reactivated properly.

[raamdev]

@jaswsinc writes...

I think this issue (and perhaps #603 too) are both related to the bug I outlined for Kristine in this PR. I just stumbled into this while reviewing her work. See: wpsharks/comet-cache-pro#174 (comment)

In short, NAMESPACE in the CRON event schedule should be set to GLOBAL_NS.

That bug did not exist in v151105, so this issue must be the result of something else.

[jaswrks]

Copy that. My mistake. That bug was introduced while working on a PR, never in the official copy.

[raamdev]

@patdumond writes...

If ZenCache Pro is deactivated from the WordPress Plugins panel autocache job is removed from WP-Cron, disabling Auto-Cache.

Are you saying that the Auto-Cache Engine is disabled if ZenCache is disabled? That is the expected behavior. If you disable ZenCache, the cron job that runs the Auto-Cache Engine should be removed.

[patdumond]

I'm saying that it is removed from we-cron when ZenCache is deactivated and is not recreated/turned back on when ZenCache is reactivated.

[raamdev]

@patdumond Do you still have a site where you can reproduce that behavior consistently? If so, I'd like to send you a copy of the latest dev build to see if the recent work that went into the dev branch fixes this issue.

[raamdev]

I was able to successfully reproduce this bug following these steps:

1. Install + activate ZenCache Pro v151114 on a clean installation (no prior ZenCache options in the database); cron jobs are added as expected
2. Enable ZenCache, Save All Changes
3. Deactivate + Delete ZenCache from Plugins page; _cron_zencache_cleanup is left behind (expected, as we did not disable Deactivation Safeguards), but _cron_zencache_auto_cache disappears! Not expected.
4. Install + activate ZenCache v151114 again (previous database options will be used), _cron_zencache_auto_cache is not recreated because http://wsharks.com/1YReX4Y fails (because of the existing database options...)

So, the bug appears to be with _cron_zencache_auto_cache being removed on an uninstallation when it should not be (i.e., when Deactivation Safeguards are enabled).

Still investigating...

[raamdev]

Another datapoint that adds to the difficulty of reproducing this bug:

• After following the steps that I outlined above, you may notice that after Step 4 the _cron_zencache_auto_cache still exists (i.e., what you would expect). However, if you simply wait until that Cron is scheduled to run again (every 15 minutes by default), you'll notice that it does disappear the next time it runs. (Note that ZenCache has been uninstalled at this point, so whatever _cron_zencache_auto_cache hooks onto will not exist.)

My first thought would normally be, "okay, well maybe WordPress is cleaning up that cron when it finds the thing it was hooked to no longer exists...", except that _cron_zencache_cleanup does not disappear the next time it runs when ZenCache has been uninstalled...

Why does _cron_zencache_auto_cache disappear and _cron_zencache_cleanup stay behind?

[jaswrks]

Referencing: this file in WP core. I'm reviewing that file to see if I can help answer your question.

[jaswrks]

I haven't been able to pin this down yet, but I am almost sure that the reason for this disappearance is the schedule that the auto-cache engine runs on. It's a schedule that only exists so long as ZenCache is an active plugin; i.e., it runs on a custom schedule of every15min, which ceases to exist once the plugin is inactive. I'm seeing these lines that look suspect. https://github.com/WordPress/WordPress/blob/77e365efbf2e499e2ed11d29c101ea466cf1ceed/wp-includes/cron.php#L126-L137

[jaswrks]

So I think you've discovered a WP core bug. We just need to find a way to prove that now. ha

[raamdev]

@jaswsinc You were right. This is related to WP Core, but it's not a bug as far as I can see (unless we're supposed to be able to schedule events with schedules that no longer exist). 😄

Here's what's happening: When wp_schedule_event() is called via wp_reschedule_event() (after ZenCache has been uninstalled: remember, this only occurs when rescheduling the event after the plugin has been uninstalled), it passes the custom every15m schedule to wp_schedule_event(), which then gets a list of schedules via wp_get_schedules() and since ZenCache has been deleted and no longer adds the custom every15m schedule via add_filter('cron_schedules', ...), the wp_schedule_event() function finds that every15m no longer exists and doesn't reschedule the _cron_zencache_auto_cache event.

As an aside: I learned how to use XDebug to debug WP Cron API code without triggering XDebug from the browser (i.e., auto-triggering it whenever cron runs): xdebug.remote_autostart=1. Fun!

---

Reviewing the WP Core code, I think the current behavior makes perfect sense. (How can WP 'remember' the custom every15m schedule if the plugin that adds it, via add_filter(), no longer exists?)

In fact, I was surprised to see the _cron_zencache_cleanup event still existed after I had uninstalled ZenCache, with deactivation safeguards enabled yes, but the plugin had been removed so it made sense to me that the cron event, which belongs to that now uninstalled plugin, would be removed too. The fact that it still existed seemed odd to me and that is probably the unintended and unexpected behavior here.

[jaswrks]

When wp_schedule_event() is called via wp_reschedule_event()

Makes sense. I see exactly what you mean.

(i.e., auto-triggering it whenever cron runs): xdebug.remote_autostart=1. Fun!

ha. That's awesome! I'll have to try that out some time.

Reviewing the WP Core code, I think the current behavior makes perfect sense. (How can WP 'remember' the custom every15m schedule if the plugin that adds it, via add_filter(), no longer exists?)

I mostly agree, but what makes me feel that this is a bug are the comments in these lines of code. See: https://github.com/WordPress/WordPress/blob/77e365efbf2e499e2ed11d29c101ea466cf1ceed/wp-includes/cron.php#L126-L137

As it exists, a CRON entry is self-contained, and it should not need to depend on the schedule once it has already been configured at least once, because the interval is known.

It appears to me that whoever authored wp_reschedule_event() had that in mind, but later someone added this block to wp_schedule_event() and it broke that behavior.

So I still feel that this is a bug (very minor), but I call it a bug, because the array of schedules should be reserved almost entirely for a UI-based approach to WP Cron. The schedule itself should not have any impact on the integrity of the underlying array, because all the schedule does is set an interval anyway. Once that interval is known, the dependence on the original schedule should end.

[jaswrks]

but it's not a bug as far as I can see (unless we're supposed to be able to schedule events with schedules that no longer exist).

I agree with you there, we shouldn't be able to create a CRON using a non-existent schedule, because the interval would be unknown. However, once an event has been scheduled it shouldn't disappear simply because the schedule it was connected to is gone. It shouldn't even be connected to the original schedule at all, in fact.

Once the event is set, the interval is known. The interval (as it exists now) is even saved as a part of the CRON array, so it seems that what I'm saying, was the intention all along, it's just not being handled in this way with respect to recurring events that are being passed through wp_reschedule_event() again and again.

So the bug is not with wp_schedule_event(), the bug is related to the strategy that WP_Cron uses, which requires an event to be rescheduled, in such a way that it requires the original schedule to exist, which may or may not be the case. That dependency is causing a loss of data, as we are seeing here with ZenCache. The schedule was set, but data loss occurs when the schedule is dropped.

That means that all of your configured CRON jobs are susceptible to this magical disappearing act when/if you happen to deactivate any given plugin which filters the array of known schedules.

[jaswrks]

Another example of how (what I consider to be a bug) could cause problems...

We recently made it possible for you to schedule the cleanup process in a custom way; using one of the configured WordPress CRON schedules that is available in your installation of WordPress. But what happens if you choose a schedule from the dropdown that is exposed by a plugin other than ZenCache? If, later, you deactivate that plugin, the ZenCache cleanup task will magically disappear due to this bug.

[raamdev]

@jaswsinc writes...

As it exists, a CRON entry is self-contained, and it should not need to depend on the schedule once it has already been configured at least once, because the interval is known.
[...]
So the bug is not with wp_schedule_event(), the bug is related to the strategy that WP_Cron uses, which requires an event to be rescheduled, in such a way that it requires the original schedule to exist, which may or may not be the case.

Ah, I see what you mean. Yep, I agree that this appears to be the result of a bad strategy on WP_Cron's part and probably someone inserting code somewhere that changed the originally intended behavior.

We recently made it possible for you to schedule the cleanup process in a custom way; using one of the configured WordPress CRON schedules that is available in your installation of WordPress. But what happens if you choose a schedule from the dropdown that is exposed by a plugin other than ZenCache? If, later, you deactivate that plugin, the ZenCache cleanup task will magically disappear due to this bug.

Great point! That's a really good example of how this bug would affect other plugins in negative ways, or at the very least make it more challenging and less intuitive for them to use WP_Cron in various ways (like we are with allowing someone to select a possibly custom schedule).

---

I'll file a WP Core ticket to hopefully get some attention around this issue, but in the meantime I'll follow your suggestions in the PR to fix this for ZenCache so that we work around this issue.

[raamdev]

Next Pro Release Changelog:

• Bug Fix: Fixed a bug where the Auto-Cache Engine cron event would disappear in some scenarios. Props @patdumond, @MarioKnight. See Issue #613.
• Enhancement: Improved WP Cron-related configuration and validation of custom cron schedules. See PR #197.

[raamdev]

ZenCache Pro v151220 has been released and includes changes worked on as part of this GitHub Issue. See the release announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#613).