Additional crons scheduled for single event about slickstack

[jessuppi]

Tell me how having an additional database call per page load is better than having a single scheduled event which runs once and only when it's meant to?

Simply put it's more moving parts and it's adding unnecessary cruft to the database. Those cron jobs are also not deleted when your plugin is deactivated or deleted; consider autoloaded options which are going to be loaded and cached by WordPress anyways, regardless of if you hook into that or not.

If possible maybe you can test your plugin more with object caching enabled, I'm wondering if that is perhaps why the cron was being added over and over again.

Many "shared" web hosts don't use object caching, its possibly why most users haven't seen this. Many web hosts also limit resources per cPanel user (etc) which can "hide" abusive scripts.

As I mentioned, this code has been in place since 2017, it's actively working on 10k+ installations. Your platform is the only one that has had this issue where it reschedules itself over and over. It happened on two of this client's website both hosted on your platform.

"Other sites are using it" is not the best way to debug, surely. On the contrary, I've never seen a plugin besides WWP that adds thousands of cron jobs (wwp_cron_request_review for Google) to the database, esp for a trivial task. But if you prefer the cron method, that's okay but keep in mind that it's not improving performance and is creating more potential conflicts, etc. Hope this helps, thanks ~

[jessuppi]

Thanks Josh,

I can confirm that SlickStack does not alter the wp-cron scheduling mechanism. After briefly looking at your (our) client's site the WWP cron events each had a different future timestamp, so I think the review request feature you mention sounds like the cause here. The issue was that somehow your plugin was adding thousands and thousands of cron jobs to the schedule ("thrashing").

TL;DR = I'd recommend doing away with adding unnecessary cron jobs to WordPress. Instead, you might look at setting a timestamp in the database for when plugin when activated, and simply re-display the review notice after X months or whatever:

https://github.com/littlebizzy/plugin-boilerplate/tree/1.2.0

Or better yet, just ditch all that to keep the plugin as lightweight as possible. A lot of agencies are now just hard-coding a "Review Now" type of link on the Plugins page itself = zero queries, etc.

[jkohlbach]

Hi Jesse, sorry but that doesn't make sense.

Tell me how having an additional database call per page load is better than having a single scheduled event which runs once and only when it's meant to?

It's orders of magnitude worse from a performance perspective and the whole point is that this is code that doesn't need to run all the time.

If you check back on WordPress trac, it's literally why this single event scheduling functionality was made in WordPress, in order to run one-off events!

As I mentioned, this code has been in place since 2017, it's actively working on 10k+ installations. Your platform is the only one that has had this issue where it reschedules itself over and over. It happened on two of this client's website both hosted on your platform.