If SPF is deactivated, does SPF delete the cron jobs to update SPF stats (sph_stats_cron) and clean up transients (sph_transient_cleanup_cron) ?
good question… cannot remember… If you choose uninstall, then it certainly does…
Pretty sure the plugins in 5.0 do… would have to check on those core ones…
I asked the question because on one of my networks, I had SPF activated on several sites. I was doing some housekeeping and deactivated it on all but 1 site, but there were multiple cron jobs for the entries I listed above. Therefore, I suspect it isn’t stopping the jobs on deactivation.
Since SPF is still activated on 1 site, I can’t delete the plugin, so what happens on delete doesn’t matter.
the cron jobs remain in the wp list, but they wont run because their code wont be found…
I’m glad to see you’re sort of, almost back online.
It goes without saying that you have to dump your host.
my point was only that no harm would be done as nothing would run if sp was not active…
My case is a little different – in that SP is active.
If I…
1) deactivate SP
2) delete all SP-related cron jobs
3) re-activate SP
…will SP re-create its cron jobs on re-activation?
barely living! 😉 trying to get it back to normal…
no, if you reactivate it will not add any cron jobs I dont believe unless you save an option that forces that… so its one of my worries when I get a chance to handle that ticket…
I don’t see any SP options that I could save that would control when stats are updated or when transients are auto cleaned.
yes. the stats and transients crons are started at install… and only then… part of what needs to be fixed in the ticket I have referred to…
there are other crons that get activate or deactivated via selection of an option in the admin (ie user pruning, sitemap generation, etc)…
but you are correct, they need to be stopped at deactivation and check for restarting at activation…
And for multisite, you have to give thought to the site on which SPF is activated.
the transient cleanup is not something to worry about too much. wp should, but doesnt clean up transients… they stay their forever or until accessed and have expired… we decided to remove ours by ourselves to keep db clutter down…
I would have to look into how wp handles cron to know what that arg is for – its not something we supply… but, I would imagine it being the blog id is good hunch…
each multisite install is unique… the stats stuff only runs on that blog db stuff… frankly, not sure how wp handles crons but everything we do is via the wp api… as we extend the multisite integration in the future, we will have to make sure this all works… but can tell you that stats per network site on multisite seems to work already…
I will be looking into wp_next_scheduled() vs how we do it now to prevent duplicates…
1) yes, as I stated, unless you uninstalled the plugin, the crons would remain… hence the code changes I referred that were committed to 5.0…
2)