Skip to content

--skip-plugins is ignored on WordPress 7.0.4 and higher under specific circumstances. #548

Description

@brechtryckaert

Bug Report

Describe the current, buggy behavior
We have automated updates using WP-CLI on our hosting-cluster. We notice that since August 20th, this behaviour is occurring on a lot of sites of customer that have built their sites with a premium plugin but lack a valid license or have an expired license.

How it occurs
Every night we run several wp-cli commands to deploy updates of plugins and themes. We use WP-CLI for this, obviously.

# wp plugin update js_composer
Onderhoudsmodus inschakelen...
Warning: Update pakket niet beschikbaar.
Onderhoudsmodus uitschakelen...
+-------------+-------------+-------------+--------+
| name        | old_version | new_version | status |
+-------------+-------------+-------------+--------+
| js_composer | 8.3.1       | 9.0.1       | Error  |
+-------------+-------------+-------------+--------+
Error: No plugins updated (1 failed).

So at this point, to ensure we do not hit a blocking factor due to a plugin conflict, we'll repeat the command with the --skip-plugins option:

# wp plugin update js_composer --skip-plugins
Onderhoudsmodus inschakelen...
Warning: Update pakket niet beschikbaar.
Onderhoudsmodus deactiveren...
+-------------+-------------+-------------+--------+
| name        | old_version | new_version | status |
+-------------+-------------+-------------+--------+
| js_composer | 8.3.1       | 9.0.1       | Error  |
+-------------+-------------+-------------+--------+
Error: No plugins updated (1 failed).

Now here's the weird thing. If you then run that same command again, this suddenly declares that the plugin did update (even when it did not):

Success: Plugin already updated.

This only occurs on the second time you run the same command with the --skip-plugins option.

We have seen this occur consistently on several premium plugins in combination with WordPress 7.0.4 or 7.1. We did not see this behaviour in combination with earlier versions of core.

Describe how other contributors can replicate this bug

To replicate you'll need these things:

  • a premium plugin (WPBakery Page Builder, Elementor Pro) that has an update available, but has no valid license.
  • WordPress 7.0.4 or 7.1

How to replicate:
(for this example I'll assume you are also testing with js_composer, update your plugin name accordingly when testing with another plugin)

  • Run: wp plugin update js_composer
  • Run: wp plugin update js_composer --skip-plugins
  • Run: wp plugin update js_composer --skip-plugins

Expected outcome

The first two commands will result in:
Error: No plugins updated (1 failed).
The third command will result in:
Success: Plugin already updated.

Let us know what environment you are running this on

# wp cli info
OS:	Linux 6.1.182-hcl #deb11 SMP Fri Aug  7 06:55:11 UTC 2026 x86_64
Shell:	/bin/bash
PHP binary:	/usr/local/php-7.4/bin/php
PHP version:	7.4.33
php.ini used:	/data/jail/usr/local/php-7.4/etc/php.ini
MySQL binary:	/usr/local/bin/mysql
MySQL version:	mysql  Ver 14.14 Distrib 5.7.44-57, for debian-linux-gnu (x86_64) using  8.1
SQL modes:
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	phar:///usr/bin/wp
WP-CLI packages dir:	/data/sites/web/REDACTED/.wp-cli/packages/
WP-CLI cache dir:	/data/sites/web/REDACTED/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version:	2.12.0

Sadly I'm not able to provide a solution just yet, as I am still trying to figure out where the cause originates.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions