As the title says - Does ClasicPress and/or Classic Commerce use Action scheduler?
I recently migrated from WP/WC to CP/CC.
Can I remove those tables from the database?
I looked at the code and changelogs but can’t quite spot when action scheduler was introduced or if it’s being used right now… Cron seems fine and actionscheduler seems unnecessary. But some confirmation would be nice
ClassicPress doesn’t include or use Action Scheduler.
Action Scheduler was included in WooCommerce starting with version 3.5.0: “Dev - Include Action Scheduler v2.1.0 and use it for the default job queue. #21424 / #20030”. So Classic Commerce should include Action Scheduler since it was forked from 3.5.3.
Hmm, so I’m stuck with 2 scheduling systems.
Still, if I look at the tasks and things in MySQL. Nothing is being scheduled in it, not for the last 2 weeks or so.
What a pointless feat…
Dunno, and that confusion is why I made the topic, heh.
I’ve removed some other bits from the database as they aren’t used in CC.
And for Actionscheduler the last activity seems to be 2-ish weeks ago, about the time I switched to CP/CC. See attached -
My site has daily activity of several thousand pageviews and multiple orders per day. So if CC is using it, it should be scheduling several things a day I’d say.
On the other hand, everything wp-cron/cron does works perfectly fine.
As you can see, a bunch of new tables were added. This didn’t concern us greatly as it had no effect on CC. But more concerning was a table that was altered. wc_product_meta_lookup
We looked into this and it didn’t have any effect on CC.
This puzzled me for a while, but I think that although action scheduler was introduced way back then (and is part of CC) it never had its own database table until WC4.0.
One of the underlying technologies that enabled WooCommerce Admin is Action Scheduler—the background job runner already used in WooCommerce core. The 3.1 version that we’re including in WooCommerce 4.0 is a new, more performant version of Action Scheduler which utilizes custom tables to provide a great experience even on stores with large volumes of orders and posts in the database.
Perhaps added in 3.5 to accommodate and prepare for a future move… Adding it early makes sense if you want plugins to start using it.
If I search for actionscheduler in the CC files there are a few mentioning it
But I can’t find any reference to the database tables, hence my confusion.
If at all possible CC may as well not use it and remove it’s code, from a technical point it adds nothing extra or special that wp-cron can’t handle. And even if wp-cron is not 100% accurate, just schedule a cron job to trigger wp-cron every N minutes to fix that. Any serious website admin should do that anyway… Which makes actionscheduler even more ‘useless’. IMHO.
Then, if it should be required to use WC plugins in the future, add a translation/conversion layer in the fake WooCommerce that catches actionscheduler things and puts it into cron or something.
I’m not at all familiar with actionscheduler, but I can’t imagine that being very hard.
You have mentioned a few times adding extra functions into the “fake WooCommerce”. This is not feasible. The WooCommerce compatibility plugin has one job, and one job only… to trick plugins into thinking WC is installed. It is only used on a site if this requirement is a necessity. I run half a dozen CC sites and none of them need the compatibility plugin, so it is not installed on any of my sites. It you want to expand functionality it would need to be through a separate plugin.
Sure, but if the plugin exists to trick plugins into thinking there is a WC present but those plugins then fail to function because they expect certain functions. That’s not right. Basic as it is, the plugin provides a form of compatibility. It stands to reason to also add (basic) functions to actually make things compatible other than “WC exists, come at me!”. This idea of compatibility is not unique to actionscheduler of-course.
Anyway, not my plugin, I’m just giving ideas and input on what I think is logical or makes sense for certain use cases.
The statement about CC is the same as for ClassicPress ie
If it works on WP4.9 then it should work on CP
If it works on WC3.5.3 then it should work on CC
Hey @arnandegans - thanks for raising this point! It got me thinking that there should be a way to easily check what will and won’t (or might not) work when moving from WC to CC. It’s actually quite difficult for the average user to dig down and find the minimum WC version a plugin will handle.
I have made up a prototype that does what I want but it needs a plugin dev to “adopt” it, so if you feel like taking it on as a project that would be great.