Failed Downloads

[PeterBooker]

There have been a variety of problems with marking plugins/themes as failed since the first release, which I am now focusing on reducing. Once I am certain that the list is accurate I can set update commands to search the .failed-downloads file and retry previous failures.

I fixed a bug today where closed plugins (which return a 404) still tried to write to disk, causing an error and getting marked as failed. I also added HTTP retries and increased the timeouts to further reduce failures. This has significantly reduced the number of downloads marked as failed but it is still too high (in testing today between roughly 1,800 and 2,800 for a full slurp of plugins).

I am looking for ways to further reduce the failures and will implement retrying failed downloads on the next update command.

[PeterBooker]

I am content with the current functionality now, but there is a procedure issue. Currently, WPDS checks for the .failed-downloads file after a normal update. If there was nothing to update it exits without checking for the .failed-downloads file though, I believe each update command should check for potential updates to download and the .failed-downloads file, performing an update if either were detected.

I also think that the user should be informed when there were failed downloads, letting them know that these will be picked up on the next update command.