Hey,
Can you let me know what exactly isn’t working? Does the admin menu not appear? If that’s the case, there might be a JavaScript error on the site preventing it from appearing.
Activating a plugin with WP-CLI should fire the activation hook as normal, and the only thing that QM does in the activation hook is to put its db.php symlink into place. The plugin works even if the activation hook doesn’t fire.
If you’re still seeing a problem it’d be great if you could deactivate your other plugins one by one (and/or switch to a default theme) to see if there’s a conflict somewhere.
John
I can confirm that this happens for me as well. I’m running wp-cli 0.20.0 on WordPress 4.3, and the activation hook (and presumably deactivation hook) is being ignored.
This happens even when Query Monitor is the only plugin running. For some reason, it doesn’t see the activation hook.
If WP-CLI doesn’t fire the activation hook then unfortunately that’s an issue with WP-CLI, not Query Monitor.
Weird. I can confirm.
wp plugin install query-monitor --activate
does not produce the admin bar menu. Deactivating and reactivating plugin on Plugins screen adds it back.
Has anyone filed a bug report with wp-cli?
Edit: Is this bug report possibly related?
I retract my previous statement that “the only thing that QM does in the activation hook is to put its db.php symlink into place”. The activation hook also sets up the view_query_monitor capability.
It looks as though either WP-CLI isn’t triggering the activation hook, or QM’s activation hook isn’t compatible with what happens when WP-CLI does fire it. I’ll look into it.
Thanks John. Sorry I didn’t take the time to respond to your initial response. I have a little more time to help you investigate or give feedback if you need it, so please let me know.
I’m having the same issue. I believe that this ticket on Github is indeed related. It was closed with little fanfare because the revslider plugin calls register_activation_hook() from within a class, which the WP-CLI folks apparently consider a poor practice. I see that Query Monitor also calls that from within a class.
Just checked out that Github issue and it definitely sounds like it’s related. Unfortunately I don’t know enough about OOP to chime in very constructively…
I did a little testing and it seems like the difference of the WP-CLI activate and “manual” activation is the db.php file being symlinked. John, does this help identify where the init sequence is stalling? (Also updated the Github ticket)
Note: this was marked as a duplicate of #142.
I just recently started started using WP_CLI and I’ve experienced the same issue. I’ve managed to fix it with the code below. Is there a reason this isn’t used or hasn’t been tried before?
/query-monitor.php#L33
if ( 'cli' === php_sapi_name() && ! defined( 'QM_TESTS' ) ) {
# For the time being, let's not load QM when using the CLI because we've no persistent storage and no means of
# outputting collected data on the CLI. This will hopefully change in a future version of QM.
if( defined('WP_CLI') && WP_CLI ){
// you shall pass ...
} else {
return;
}
}
vagrant@username:/vagrant/site$ wp plugin activate query-monitor
Success: Plugin 'query-monitor' activated.
vagrant@username:/vagrant/site$ wp plugin deactivate query-monitor
Success: Plugin 'query-monitor' deactivated.
Just to jump into this one; I had this request open: https://ww.wp.xz.cn/support/topic/doesnt-show-in-admin-bar-front-or-backend
Activating the plugin via wp-admin/plugins.php does work fine; and after doing so deactivating and reactivating via wp-cli then seems to work fine. It just seems on initial activation the problem happens.
Fixed in the newest release.
