Wrong logic used within ZipArchive

[dd32]

Apparently no-one else noticed, The logic employed in [14346] and subsequently [14377] is wrong(Added in #12637). ZipArchive has not been used in the wild for 3 weeks because of that.

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..

[dd32]

(In [14800]) Correct the ZipArchive opening test logic. See #13491

[markjaquith]

dd32 — closable?

[dd32]

Closing as fixed. Re-open if a issue arrises during RC.

[automattor]

(In [15052]) Always fallback to PclZip in the event that ZipArchive does not return true. The PHP Zip extension is hit-and-miss with OSX generated zip files, sometimes 0 will be emitted and extraction will succeed, others it will fail with. Reverts r14346, r14377, partially r14800. See #12637. See #13491