Closed JanThiel closed 2 years ago
Wow ! Thank you so much for this so well-formed issue :) It must be fixed in the next release. Feel free if you want / have time to submit a PR. If no, I will do it after reviewing all "alternatives" to wp-cron (you're the first one I know who use Cavalcade). Many thanks for all this feedback, it's great help!
A well written issue is the least courtesy to make when adding work to someone elses schedule ;-)
To update you on my current knowledge and research:
is_plugin_active
)class_exists
check not so simple anymore ;-)
shell
. But my "real world" experience with Namespaces is limited. So Maybe it's easy and I just didn't know how:class_exists('HM\Cavalcade\Plugin')
=> `false´class_exists('HM::Cavalcade::Plugin')
=> false
wp-content/mu-plugins/Cavalcade/plugin.php
yet it feels a bit ... fishy. The file might be there but the plugin does not have to be active. As mu-plugins are actually only loaded as php files in /mu-plugins/ as you might know. We use a mu-autoloader
script to solve this for example. Guess this is what most serious installations will do. But no guarantee. Also the folder might be named differently. Not really reliable.wp_cache_get( 'installed', 'cavalcade' )
get_site_option( 'cavalcade_db_version' );
I cannot give you any promisses on a PR as we are going on vacation next wednesday. I will be (hopefully mostly) offline for two weeks. Yet let's see how far we can come up with a solution till then.
I would propose to add a check that determines, based on coded conditions, whether a wp-cron replacement is running or not. For now, that would only check for Cavalcade. When other systems raise the need to be added, it can be done easily.
I would then add an If block around the add_filter / add_action calls registering the listeners. If a replacement is detected, then seperate functions should be used. They could be identified by a suffix like <hook-name>_external_cron
=> pre_clear_scheduled_hook_external_cron
. Those functions could then implement the alternate mode as described in the docs.
What do you think?
Hello Jan!
I've made a new listener specifically for Cavalcade as it was too specific to be managed by core listener. Cavalcade events will appear as "library" class events in DecaLog 3.3.0.
I would like to thank you for the invaluable help you give on this issue. Without it, I could not have done this. 🥇
I'm closing this issue, even if 3.0.0 is not yet released... Don't hesitate to re-open if needed.
Thanks again.
Thanks @Pierre-Lannoy! One remark: Shouldn't the default listeners be de-registered? Wouldn't both listeners fire now?
Hello Jan! Yes, the default one is not registered when Cavalcade is detected ;) See https://github.com/Pierre-Lannoy/wp-decalog/blob/6565218ef5dd3bb0f26ad4015a7b432aee916994/includes/listeners/class-corelistener.php#L186
Ah, that code was not in the referenced commit 😊 Thanks for pointing it out to me ☺️
Describe the bug If pre_clear_scheduled_hook returns anything other than
null
the logger logs:Yet this message is wrong. In our case we replaced wp-cron with Cavalcade. The WordPress Docs states:
Thus an INT return value indicates that there is some wp-cron replacement running. Thus the Log message is misleading.
This kind of has to be considered for all schedule related hooks. If an external cron system is running, many filters / actions behave slightly different. This are the relevant hooks: https://developer.wordpress.org/reference/files/wp-includes/cron.php/?post_type%5B%5D=wp-parser-hook
To Reproduce
wp_clear_scheduled_hook( 'wp_version_check' );
Expected behavior One of the following:
Environment (please complete the following information):
Best regards,
Jan