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

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 ago by Steven Stern (sterndata). Reason: format