Wrong logic used within ZipArchive
|Reported by:||dd32||Owned by:||dd32|
Take $zopen = true, Fails the first check, passes the 2nd check, returns invalid archive.
&& > || sometimes.
I'm going to commit a fix for it now, but due to the limited testing recieved, I'm thinking its going to be best to make ZipArchive opt-in for 3.0, and make it opt-out again in 3.1 trunk.
The possible issues that could arise are certain configurations which I've not tested or which were not tested by the community that for one reason or another, fail to uncompress properly using ZipArchive, Whilst I believe the chances of the archive being opened without error, and then failing to be highly rare, the result would be that either the upgrade to 3.0.1 may fail (causing them to have to install a plugin to disable ZipArchive, or perform a manual upgrade), or that plugin/theme upgrades/installs would error out.
The work around of (manually) installing a plugin in case of an ZipArchive error would be something that users would have to do regardless right now if it was working for all testing users..