Display Posts Widget: Properly handle situations where Jetpack is not in jetpack plugin directory or jetpack.php is under a different name.#3303
Display Posts Widget: Properly handle situations where Jetpack is not in jetpack plugin directory or jetpack.php is under a different name.#3303dereksmart merged 2 commits intoAutomattic:masterfrom bisko:fix/dpw_properly_handle_JP_activate_deactivate
jetpack plugin directory or jetpack.php is under a different name.#3303Conversation
… is not in `jetpack` plugin directory or `jetpack.php` is under a different name. The Display Posts Widget didn't properly handle situations where `jetpack` and `jetpack.php` could be under different names. This lead to the cron not activating/deactivating when doing such to the Jetpack plugin. Now these cases are handled by properly detecting Jetpack plugin file name and directory.
|
Cool - thanks. |
There was a problem hiding this comment.
It looks to me now that the entire method doesn't work because the activated_plugin hook does not run if it's set in the plugin that is being currently activated, much like the register_activation_hook method:
https://codex.wordpress.org/Function_Reference/register_activation_hook
It seems to me that we need some another way of activating cron on Jetpack activation.
There was a problem hiding this comment.
Actually it does get run, took me a bit digging to figure out how it was working:
When you run the activation action, Jetpack gets activated, but while doing so it gets loaded up - jetpack.php is included and all the hooks are added that are there, including the plugins_loaded hook, which runs Jetpack::load_modules and if Extra Sidebar Widgets is activated, it will include the wordpress-post-widget.php file, adding the hook, mentioned below
The thing is that this happens after the hook in register_activation_hook('jetpack/jetpack.php') is called, which means that it is of no use. But after digging a bit in the WP core code, it seems that the activated_plugin action is called after Jetpack has been initialized after the activation. This means that we get the action where we can handle it in an inner part of the plugin! :)
That's why I hooked this method to the activated_plugin action.
|
Thank you, tested, looks good! |
There was a problem hiding this comment.
@bisko can you please add spaces in the plugin_basename()'s
There was a problem hiding this comment.
I am so sorry about that. Fixed.
|
LGTM after minor spacing |
…te_deactivate Display Posts Widget: Properly handle situations where Jetpack is not in `jetpack` plugin directory or `jetpack.php` is under a different name.
* Add dropdown option if current status is non-standard * Save untranslated invoice status in database * Add translated status label to invoice object * Use translated status label when appropriate * Add changelog * Set invoice to UnPaid if Draft when emailed * Fix invoice bulk action status change * Fixed Woo mapping to output translated status * Code cleanup * Translated → Untranslated * Compare untranslated strings * Cleanup * Fix typo
The Display Posts Widget didn't properly handle situations where
jetpackandjetpack.phpcould be under different names. This lead to the cron not activating/deactivating when doing such to the Jetpack plugin.Now these cases are handled by properly detecting Jetpack plugin file name and directory.