wp-cli / extension-command

Manages plugins and themes, including installs, activations, and updates.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Available Updates don't show up if wp plugin update --all previously failed due to permissions error.

dgrumbler opened this issue · comments

Bug Report

Describe the current, buggy behavior

WP CLI Version: 2.9.0 (also present on lower versions from 2.7.1 - I updated to see if that would resolve)

This bug only appears in particular circumstances.

I had an issue on a server where when running:
wp plugin update --all
WP CLI reported that all plugins were already updated.

When running
wp plugin list
It didn't list available updates despite there being available updates on the WordPress Repository.
In the browser no updates were listed on the Check Updates page or in the plugin list despite there being updates available.

I initially assumed a plugin conflict - deactivating all plugins and reactivating them again caused the available updates notifications to reappear.
wp plugin list also showed the updates once more.
I then discovered there was a permissions error that was causing the updates to fail:

"Warning: Could not create the upgrade-temp-backup directory.
Plugin update failed."

It correctly listed the updates having failed but I noticed that the available updates notifications had vanished again in the admin area.
I ran wp plugin list again and again it was showing "none" against every plugin.
I ran wp plugin update --all as a test and it reported "Success: Plugin already updated." despite this not being the case.

I can get the updates to appear again by deactivating the plugins and re-activating and I'll resolve my permissions error so the updates don't fail in the first place but I think WP CLI must be setting something somewhere that all plugins have been updated despite the update having failed which made it hard to track down so I thought it was worth reporting here so it could be looked into.

Describe how other contributors can replicate this bug

Any WordPress installation that has a plugin needing an update.

  • set upgrade-temp-backup directory as unwritable
  • run wp plugin update --all (it should fail due to being unable to create a directory)
  • Once it has finished running run wp plugin list and wp plugin update --all to see the incorrect messages

Describe what you would expect as the correct outcome

When an update command fails
I'd expect that the available updates should still display in WordPress Admin and in wp plugin list
I'd expect wp plugin update --all to try and update the plugins again.

Let us know what environment you are running this on

OS: Linux 5.4.0-167-generic #184-Ubuntu SMP Tue Oct 31 09:21:49 UTC 2023 x86_64
PHP version: 8.2.8
MySQL version: mysql Ver 8.0.35-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))
WP-CLI version: 2.9.0

Thanks for your report!

WP CLI must be setting something somewhere that all plugins have been updated despite the update having failed

WP-CLI just uses whatever update information that is stored in WordPress' transients and doesn't have any additional logic on top of that. So if you don't see any updates in the browser it makes sense that you don't see any in WP-CLI either.

I just tried reproducing this issue with the steps you provided, but was unable to do so.

Yes, the update failed with a "Could not create the upgrade-temp-backup directory." warning, but I still see the available plugin update when running wp plugin list.

Given what I said initially, this seems to be more an issue with your WordPress installation and not WP-CLI.

Thank you for having a look - that's fair enough - I was able to replicate the problem on our dev server as well as the original server but I accept there may be something in our server setup triggering this odd problem or maybe firewall related? It was like it got blocked from checking again once it had failed or something was being cached. I will keep looking and see if I can figure out what is triggering the problem if it's not the permissions error that was triggering it. Would be nice to get to the bottom of it so I can be sure it won't happen again!