user9723764

Thank you @emrevona . Yes, I’m using AIOS. I disabled it temporarily and attempted to removed/edit the rule and I was able to complete the action successfully.

What action is your plugin taking when performing this action that AIOS would be blocking it. I assume it’s just removing or adding something to the WP Scheduler, which would be odd for AIOS to be blocking. Can you please share some details, so I can disable that feature in AIOS. I wonder if it’s also related to the preloader scheduler issue I’ve reported. I can update that support topic if it’s also the fix.

UPDATE: Oddly, that worked, but once I reactivated AIOS plugin and it’s PHP firewall. I attempted to change the time out rules again, but had no problem. So I was able to change the rules with AIOS enabled. This I find odd. But at the same time, immediately after disabling AIOS, I was able to change the rule, but not before disabling. What does that mean?

Thanks!

• This reply was modified 6 months, 2 weeks ago by user9723764.

I was working with ChatGPT to confirm all settings are configured properly. Below is the final output. It even referenced this thread (crazy to see how ChatGPT references both it’s internal data and live website data now that is somehow already indexed).

—–

Ah, got it, thanks for the extra detail and the screenshot. You are absolutely right, my earlier assumption about it “just finishing” was wrong. With 5,600+ CPTs and a batch size of 10 it should be busy for a long time, and your / ?action=wpfastestcache&type=preload output clearly shows it is not complete when the cron job has already disappeared.

What you are running into is almost certainly a bug in WP Fastest Cache’s WP-Cron based scheduling for Preload, not a problem with your WP-Cron setup:

• WP-Cron itself is fine (other jobs run and you have a proper Hostinger cron hitting wp-cron.php every 5 minutes).
• The plugin’s own preloader works perfectly when you hit the preload URL in the browser.
• The wp_fastest_cache_Preload event is being unscheduled while the internal preload state still shows customposttypes: 0/5626 and page: 10/22.

That matches exactly what you described in the ww.wp.xz.cn thread, and the plugin author’s only “solution” there was to use the manual preload URL via cron instead of relying on WP Schedule. ww.wp.xz.cn+1

So, I would treat the built-in WP Schedule hook as unreliable in your case and shift to a host-level cron that calls the preload URL directly.

—–

I think I will just go with ignoring the plugin’s cron hook job and setup a manual cron job on Hostinger to call the preload URL. However, I wanted to inform you that it does seem as though there is some bug in the plugin code for how it’s handling the cron preload hook, which I assume you expect to be working. Prior to posting this last comment. I also completely uninstalled WP Fastest Cache, removed the cache folder and checked wp_options table to ensure nothing was leftover from WP Fastest Cache. I then reinstalled the plugin, enabled the same settings. Preload ran for about 5 or 6 times and then disappeared from the Cron Events scheduler. This happened, even before it started preloading the custom post types (it was in middle of Page content type). So something definitely appears to be broken with the preload cron job scheduler.

I hope this detailed information is helpful to identify the cause and solution. Thanks!

I can of course setup a manual cron job to call the preloader URL every 5 minutes by using this: wget -O – “https://www.YOUR-URL.com/?action=wpfastestcache&type=preload” >/dev/null 2>&1

But I believe your plugin is using WP Schedule to add the hook to call preloader every 5 minutes via Cron. Your documentation states that the WP Schedule should handle it. That’s what I’m trying to say. It seems the preload job does not stay scheduled by WP Schedule. If this feature is broken and does not work anymore, then yes, I guess I will need to call the preload URL by setting a a manual cron job.

Just a custom post type managed by the theme. The preloader works just fine to cache them. The issue is that the cron scheduler appears to be missing the wp_fastest_cache_Preload job. It only shows wp_fastest_cache_0 and wp_fastest_cache_1. The preload job seems to fall off after it has done the first few content types to cache.

Then, the only thing left is these two:

wp_fastest_cache_1

[ “{\”prefix\”:\”all\”,\”content\”:\”all\”}” ]

and

wp_fastest_cache_0

[ “{\”prefix\”:\”homepage\”,\”content\”:\”homepage\”,\”hour\”:\”7\”,\”minute\”:\”0\”}” ]

So it seems there was an issue. For some reason, the preload cache job wasn’t getting added to the WP Cron scheduler. I confirmed it by installing the WP Crontrol plugin. Having a quick look at that, confirmed that the job was not in the event list.

I went back into the WP Fastest Cache admin page. Unchecked the preload checkbox and saved the settings. Then checked the preload checkbox again, the settings window popped up, I clicked through and then saved the settings.

Went back to the WP Crontrol plugin’s event page and filtered on “cache” which then showed that the preload job was now scheduled. like below:

wp_fastest_cache_Preload Edit | Run now | Pause this hook | Delete
NowToday at 7:11 pmOnce Every 5 MinutesWpFastestCache->create_preload_cache()

So it seems for some reason, the scheduler didn’t get added when it was previously shared. Must be some bug, but I have no idea how to reproduce the issue. But now that the job is scheduled, it’s getting called every 5 minutes when I run cron.

Had I not installed WP Crontrol, I would have not been able to confirm this. If you run into the issue I describe above, try disabling preload, saving, re-enable, save, and then check to see if the cron action is scheduled.

One more piece of information. I’m pulling my hair out over this and can’t make sense of things.

When I attempt to do the above steps via Chrome (standard), when it launches the Google authentication via this URL: https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?response_type=code&client_id=

When I do the same attempt while in incognito mode, it launches the Google authentication via this URL: https://accounts.google.com/v3/signin/accountchooser?access_type=offline&client_id=

Why is one using the v2 version and the other is using v3. v3, appears to be the one that gives me consistent results. When attempting in v2, it will do the other issue (where it seems as though it properly authenticates and then passes me back to the website, but the user doesn’t appear logged in).

Thanks Emre! That’s unfortunate, but I appreciate your help. Is that just a normal practice now, or is there some alternative (meaning, could the plugin creator have coded it definitely so that this isn’t an issue, or this is an issue with simply AJAX and WordPress’s nonce system. And its just something that needs to be done if you are going to use Ajax and caching?