WPIntell

Source evidence

“Only by using user id=1 to activate via wp-cli”

AdRotate Banner Manager · support · 2026-03-27T02:14:00+00:00

complaintsentiment
highseverity
1.0relevance
3replies
Evidence linked to opportunitycommercial context

Proof Health

Open evidence

Commercial opportunities need traceable source links before they are treated as build-worthy.

3 / 28 rows with source links

10.7% of this page's analysis has direct source links.

0 build-decision rows missing links

0 rows here require auditable proof before promotion.

25 rows with no attached evidence

0 rows have source counts but still need direct links.

Conversation

support
Daniel Oliveira da Paixão unresolved
sudo -u www-data wp –path=/var/www/vozdamazonia.com.br/htdocs –user=1 plugin activate adrotate The page I need help with: [ log in to see the link] And your question? Or what does this mean? What I meant is that your plugin is not properly compatible with WP-CLI during activation and deactivation. It only works through the WordPress admin dashboard, while most other plugins activate and deactivate normally both from the dashboard and via WP-CLI. In this case, AdRotate appears to fail specifically when executed from the command line. When I try to activate or deactivate the plugin with WP-CLI, WordPress throws a fatal error similar to this: PHP Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function “adrotate_deactivate” not found or invalid function name in /var/www/mydomain.com/htdocs/wp-includes/class-wp-hook.php:341 … Error: There has been a critical error on your website. Technically, the issue appears to be that the plugin registers a deactivation hook pointing to the function adrotate_deactivate, but when WP-CLI runs the deactivate command, that callback is not available in memory at the moment WordPress attempts to execute it. In practice, this usually means one of the following: The function adrotate_deactivate() is not loaded unconditionally before the deactivation hook is registered. The function exists only in a file that is loaded in the admin dashboard flow, but not in the WP-CLI execution flow. The hook registration points to a function name that no longer exists, was renamed, or is conditionally declared. The plugin relies on admin-only includes such as is_admin() or similar logic, which prevents the callback file from being loaded under WP-CLI. To fix this, the plugin developer needs to make sure that the deactivation callback is always available whenever WordPress loads the main plugin file, including under WP-CLI. In other words, the function used in register_deactivation_hook() must be defined before WordPress attempts to call it, regardless of whether execution comes from the dashboard or the command line. A correct implementation usually looks like this: function adrotate_deactivate() { // cleanup tasks } register_deactivation_hook( FILE , ‘adrotate_deactivate’); If the callback is defined in another file, that file must be included unconditionally from the main plugin bootstrap file, not only inside admin-specific logic. For example: require_once plugin_dir_path( FILE ) . ‘includes/deactivate.php’; register_deactivation_hook( FILE , ‘adrotate_deactivate’); What needs to be corrected, technically, is this: Ensure the callback function exists and is spelled exactly as registered. Ensure the file containing that function is always loaded. Avoid wrapping the function definition inside if ( is_admin() ), if ( ! defined(…) ), or other conditions that may not run in WP-CLI. Test activation and deactivation both from the admin panel and with commands such as: wp plugin deactivate adrotate wp plugin activate adrotate So the core problem is not simply “WP-CLI incompatibility” in general. The real issue is that the plugin’s activation/deactivation hook architecture is incomplete or incorrectly scoped, causing WordPress to call a callback that is not available during CLI execution. This reply was modified 1 month, 3 weeks ago by Steven Stern (sterndata) . Reason: format Maybe you can try a few things – Does it work if you move adrotate.php lines 43-47 to line 143 (Right above the adrotate_dashboard function? And if not; Does it then work if you *also* expand the if on line 94? Like so: if(is_admin() OR WP_CLI) { I don’t use cli myself, never even looked at it. So I’m not sure why it wouldn’t work. But if it’s missing functions then that will probably fix it. You can also try to include adrotate-setup.php earlier, move it up from line 95 to line 39-40. But since you never use anything from that file outside of the dashboard (and CLI apparently) I’m not a fan of that. Looking forward to your findings and answer 👍 Thanks! This reply was modified 1 month, 3 weeks ago by Arnan .

Comments

3 shown
Arnan 2026-03-27T02:17:00+00:00

And your question? Or what does this mean?

Daniel Oliveira da Paixão 2026-04-02T15:04:00+00:00

What I meant is that your plugin is not properly compatible with WP-CLI during activation and deactivation. It only works through the WordPress admin dashboard, while most other plugins activate and deactivate normally both from the dashboard and via WP-CLI. In this case, AdRotate appears to fail specifically when executed from the command line. When I try to activate or deactivate the plugin with WP-CLI, WordPress throws a fatal error similar to this: PHP Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function “adrotate_deactivate” not found or invalid function name in /var/www/mydomain.com/htdocs/wp-includes/class-wp-hook.php:341 … Error: There has been a critical error on your website. Technically, the issue appears to be that the plugin registers a deactivation hook pointing to the function adrotate_deactivate, but when WP-CLI runs the deactivate command, that callback is not available in memory at the moment WordPress attempts to execute it. In practice, this usually means one of the following: The function adrotate_deactivate() is not loaded unconditionally before the deactivation hook is registered. The function exists only in a file that is loaded in the admin dashboard flow, but not in the WP-CLI execution flow. The hook registration points to a function name that no longer exists, was renamed, or is conditionally declared. The plugin relies on admin-only includes such as is_admin() or similar logic, which prevents the callback file from being loaded under WP-CLI. To fix this, the plugin developer needs to make sure that the deactivation callback is always available whenever WordPress loads the main plugin file, including under WP-CLI. In other words, the function used in register_deactivation_hook() must be defined before WordPress attempts to call it, regardless of whether execution comes from the dashboard or the command line. A correct implementation usually looks like this: function adrotate_deactivate() { // cleanup tasks } register_deactivation_hook( FILE , ‘adrotate_deactivate’); If the callback is defined in another file, that file must be included unconditionally from the main plugin bootstrap file, not only inside admin-specific logic. For example: require_once plugin_dir_path( FILE ) . ‘includes/deactivate.php’; register_deactivation_hook( FILE , ‘adrotate_deactivate’); What needs to be corrected, technically, is this: Ensure the callback function exists and is spelled exactly as registered. Ensure the file containing that function is always loaded. Avoid wrapping the function definition inside if ( is_admin() ), if ( ! defined(…) ), or other conditions that may not run in WP-CLI. Test activation and deactivation both from the admin panel and with commands such as: wp plugin deactivate adrotate wp plugin activate adrotate So the core problem is not simply “WP-CLI incompatibility” in general. The real issue is that the plugin’s activation/deactivation hook architec...

Arnan 2026-04-04T21:43:00+00:00

Maybe you can try a few things – Does it work if you move adrotate.php lines 43-47 to line 143 (Right above the adrotate_dashboard function? And if not; Does it then work if you *also* expand the if on line 94? Like so: if(is_admin() OR WP_CLI) { I don’t use cli myself, never even looked at it. So I’m not sure why it wouldn’t work. But if it’s missing functions then that will probably fix it. You can also try to include adrotate-setup.php earlier, move it up from line 95 to line 39-40. But since you never use anything from that file outside of the dashboard (and CLI apparently) I’m not a fan of that. Looking forward to your findings and answer 👍 Thanks! This reply was modified 1 month, 3 weeks ago by Arnan .