schlessera
commented
6 years ago I think there's two separate mechanisms we'd need to let WP-CLI properly handle this:
- A (configurable) expiry time for cached downloads, which you can then set through any of the existing config files
- A flag to
--skip-cachefor forcing WP-CLI to do a fresh download even though the cache has not expired yet
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.