On January 30th, 2024, WordPress 6.4.3 was launched to resolve two security issues. However, following the release, numerous users reported difficulties uploading MacOS Zip files, encountering an “Incompatible Archive” error. Interestingly, files compressed on Windows exhibited no problems, and a ticket was quickly opened to tackle the issue.
Jose Mortellaro suggested solving the issue by adding this line of code in the functions.php of a child theme or a functional plugin. It will ask WordPress to use the PclZip class instead of the ZipArchive module.
add_filter( 'unzip_file_use_ziparchive', '__return_false' );
The others found deleting the MACOSX folder from the zip and re-uploading it works. Compressing/recompressing the folder using the terminal, using a third party archive app to zip the file before uploading, unzipping/re-zipping the packages in the Windows operating system, extracting the package in the wp-content/plugins path and then activating the package from the WordPress plugins section, creating your zip file manually were other temporary solutions shared by the users.
Several plugin/theme authors complained of being inundated with support requests from their users. Most of the solutions shared were helpful only for individual users and not for developers with several plugins and thousands of users.
To Fix Or Not To Fix
Tim Nolte of Forum One had this to say “this is a problem for the people that are not using the WordPress.org repository for their packages, and are generally charging for plugins/themes. The companies/devs distributing their own packages should be held to having to distribute their packages with the same restrictions as packages that come from WordPress.org.” He also said “IMO this shouldn’t be fixed. Plugin & theme developers should not be using daily driver developer machines to package plugins. In this day in age with freely available CI/CD process that can do this in more protected environments there is no excuse for creating these packages on macOS which has always resulted in archives with junk MACOSX folder that have no business being there on any other platforms.”
Tobias Bäthge (author of TablePress plugin) shared, “One solution for Core could be to just repeat the call to $archive->open( $file[‘file’] ) (but without the ZIPARCHIVE::CHECKCONS flag) or to try a fallback check with PclZip on failure as well (and not just if the ZipArchive class is not available).”
Despite many hoping the bug would be treated as highly critical, it was kept as normal priority as workarounds were available. Aaron Jorbin (WordPress core committer) clarified “A critical bug is one where a large percentage of users are likely to be impacted and there is no workaround. In this case, there is a workaround (in fact, there are two) and it only impacts users who attempt to upload a zip that is created in one specific way.” Jeffrey Paul (Director of Open Source at 10up) also supported this view.
Automattic sponsored Andrew Ozz is of the opinion that “the .zip files that are affected are mostly self-made by the people that are uploading them. Downloading a theme or plugin and then uploading the .zip file to a WP site seems like pretty rare workflow. In addition only Safari users are affected. Thinking that a support forum thread about how to set Safari to not automatically unzip and delete downloaded .zip files would probably be enough until the core fix is released.”
However Open source UX advocate Kevin Coleman said “I respectfully disagree with this logic. If Honda broke their door handles and said “just leave your windows down so you can reach in and lift the latch inside to get in” it would be a catastrophe. This is breaking all kinds of workflows and the UX happy path for potentially thousands of devs and users. Breaking an edge case? Sure, priority normal. Breaking a high-traffic happy path = catastrophe.”
Ben Ritner (of Kadence WP) was “surprised this isn’t being treated as a more critical bug. I understand the desire to push this on theme/plugin developers and have them not use native Mac compress to create zip files.” Andrew Palmer (co-founder of Bertha AI) voiced this through X: “There are millions of users of WP – not all are developers who could figure out why a particular plugin doesn’t work when its uploaded – I know people who have zero idea of what even a Zip file is. Let alone Safari users who have no idea how to rezip a folder or even tell Safari to NOT unzip a file.”
Kari Anderson (Southern Bytes) reminded everyone that “Not everyone who uses WordPress uses the command line. What about the blogger or business owner working on their site who has a deadline and now can’t get anything done and has no idea why? They are not going to know to unzip a file and rezip it in the command line? Are you kidding me? This is a HUGE issue.”
Daniel Schutzsmith (Software developer and entrepreneur) recommended “the marketing team blast this on socials, email, whatever to let WordPress users know about this problem.” and Stephen Cronin (WordPress Specialist at Envato) suggested, “If a breaking change is going to be introduced, developers should be warned a long time in advance and giving them plenty of time to prepare.”
Colin Devroe (of Hubbub) explained why non-Mac users also might have this issue. “All plugins are distributed as zip files. The software that created the zip file, as well as the software uncompressing the zip file on your WordPress server, are the two factors that matter here. Without even knowing it, if you create a zip file on macOS or in Ubuntu or any other operating system, you may be creating the a zip that will trigger this bug. Additionally, if you are experiencing this bug with a zip file that you didn’t create, or that you downloaded from a WordPress plugin or theme vendor’s website… it is likely because the version of a piece of underlying software on your WordPress server is not quite up-to-date. So, you can experience this issue whether or not you’re on a Mac and whether or not you created the zip file.”
As of now, the issue has been scheduled for resolution in WordPress 6.4.4.