Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 tasks done
dgrumbler opened this issue Nov 28, 2023 · 2 comments

Comments

@dgrumbler
Copy link

dgrumbler commented Nov 28, 2023

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

@swissspidy
Copy link
Member

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.

@dgrumbler
Copy link
Author

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!

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

No branches or pull requests

2 participants