id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
13491	Wrong logic used within ZipArchive	dd32	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.."	defect (bug)	closed	normal	3.0	Upgrade/Install	3.0	major	fixed