You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a feature request because I recently got hit by "old" caching of plugin zip files by WP-CLI that caused a constant re-installation of a particular plugin (it was Yoast SEO's "wordpress-seo-7.2.zip" - they'd stupidly released it for one day with 7.1 as the version inside the zip! Even though they fixed it the next day, WP-CLI kept using the cached one, because the re-release with the correct 7.2 version internally also used the same wordpress-seo-7.2.zip filename :-( ). So each daily update tried to install "7.2", but it got stuck on 7.1 of course!
This can also annoyingly happen because of the awful concept of re-packaging a same-named zip file after editing the README.txt inside it to increment the "Tested on:" line when a new WordPress release is out. Yes, it's awful because you have a new zip file with the same name/internal version and different contents - WP-CLI caches the old one and then the "wp-cli plugin verify-checksums" command fails of course (there's new checksums remotely, but WP-CLI uses the older cached zip).
Hence, I would like WP-CLI to ignore (or even delete?) .zip files (or any other cached files) in the cache directory older than a certain number of days (and re-download if necessary), which should be optionally specifiable. The default ignore period should be conservative e.g. the average number of days between WordPress releases would be a good start because there'll be a flurry of those "Tested on:" zip updates around the time of a WP release. This would also add the ability to disable the cache if WP-CLI was run with days=0 as the expiry period.
The text was updated successfully, but these errors were encountered:
Original issue by @rklrkl:
This is a feature request because I recently got hit by "old" caching of plugin zip files by WP-CLI that caused a constant re-installation of a particular plugin (it was Yoast SEO's "wordpress-seo-7.2.zip" - they'd stupidly released it for one day with 7.1 as the version inside the zip! Even though they fixed it the next day, WP-CLI kept using the cached one, because the re-release with the correct 7.2 version internally also used the same wordpress-seo-7.2.zip filename :-( ). So each daily update tried to install "7.2", but it got stuck on 7.1 of course!
This can also annoyingly happen because of the awful concept of re-packaging a same-named zip file after editing the README.txt inside it to increment the "Tested on:" line when a new WordPress release is out. Yes, it's awful because you have a new zip file with the same name/internal version and different contents - WP-CLI caches the old one and then the "wp-cli plugin verify-checksums" command fails of course (there's new checksums remotely, but WP-CLI uses the older cached zip).
Hence, I would like WP-CLI to ignore (or even delete?) .zip files (or any other cached files) in the cache directory older than a certain number of days (and re-download if necessary), which should be optionally specifiable. The default ignore period should be conservative e.g. the average number of days between WordPress releases would be a good start because there'll be a flurry of those "Tested on:" zip updates around the time of a WP release. This would also add the ability to disable the cache if WP-CLI was run with days=0 as the expiry period.
The text was updated successfully, but these errors were encountered: