WordPress 6.4.3 MacOS/Linux Compressed Zip plugin archives "Incompatible Archive" on upload

[Endymion00]

If I zip a plugin folder using MacOS right-click Compress command in the contextual menu, those archives are no longer accepted when using upload plugin. It returns "Incompatible Archive". This has worked up until now. Probably related to recent security updates for the plugin and theme uploader.

If I create a zip on the command line of the same folder that works correctly.

[Endymion00]

Sample of Classic Editor using MacOS Compress

[Endymion00]

Sample of Classic Editor using the zip command in the Terminal

[mujuonly]

Am facing the same issue. Possibly this https://core.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&old=57390%40%2F&new=57390%40%2F&sfp_email=&sfph_mail= has something to do with this issue?

[swissspidy]

#60399 was marked as a duplicate.

[TobiasBg]

Yes, this is caused by [57388].

In short: The ZIPARCHIVE::CHECKCONS flag causes checks to use a "pedantic" mode, which Apple's Archive too fails.
(For some internals from an Apple dev, see ​https://wordpress.org/support/topic/macos-zip-files-made-with-the-built-in-archive-utility-arent-accepted/#post-15815401 ).

This has previously affected WordPress (#12637) and WP-CLI (​https://github.com/wp-cli/extension-command/issues/362).

It looks like libzip has a solution already (​https://github.com/nih-at/libzip/issues/341 and ​https://github.com/nih-at/libzip/commit/b3e3b19e2e4b7d4651d01148f123129429ecc69b) but that will probably still need to make its way to servers...

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

[swissspidy]

#60394 was marked as a duplicate.

[swissspidy]

Using the same PclZip fallback in case of an error sounds reasonable at first glance and would bring consistency with unzip_file().

Moving to 6.4.4 for consideration.

[TobiasBg]

#60400 was marked as a duplicate.

[cdevroe]

This issue seems to have broad impact. Is there a way to gauge whether or not the Core team has an expectation of 6.4.4 being released quickly to patch this? Or, should plugin authors try to mitigate this issue in the shorter term?

[welaunchio]

Can you please increase the priority of this? All our users are affected and I am getting support requests per hour.

[TobiasBg]

For plugin developers that are affected: As other ZIP programs for Mac are producing working ZIP archives (like the command line ZIP tool, BetterZip, or ​Keka ), it might be worthwhile to just re-zip your plugin folders with one of those.

[jorbin]

Lowering the severity since there is currently a workaround on both the zip creation side ( use the command line) and the individual site side ( add_filter( 'unzip_file_use_ziparchive', '__return_false' ); ).

[nerdpressteam]

@jorbin Not fixing this urgently puts a huge demand on plugin devs to replace existing install files.

The update mechanism we use (kernl.us) apparently doesn't let us simply replace the binary. So we'd need to issue a new release/version to work around this. 😬

[welaunchio]

Replying to jorbin:

Lowering the severity since there is currently a workaround on both the zip creation side ( use the command line) and the individual site side ( add_filter( 'unzip_file_use_ziparchive', '_return_false' ); ).

How shall I put this filter into my customers plugins when they can NOT Upload my plugins?! This is a solution for individual sites, but not for plugin developers with thousands of customers.

And I can not just zip all my 20 plugins and push into all channels in 1 click. This takes me several hours! remove the CHECKONS Please!

[Koesper]

creating your zip file manually works.
(using terminal on MacOS, instead of right-click > compress in finder)

zip -vr theme.zip your_theme/

see: ​https://superuser.com/q/505034/415143

p.s. use the zip command, not ditto (since that is the same as compress in finder)

[mathewemoore]

I have the same issue on Mac, but have confirmed @Koesper's method using terminal solves the issue for me.
 
Replying to Koesper:

creating your zip file manually works.
(using terminal on MacOS, instead of right-click > compress in finder)

zip -vr theme.zip your_theme/

see: ​https://superuser.com/q/505034/415143

p.s. use the zip command, not ditto (since that is the same as compress in finder)

[JeffPaul]

Unless I'm misunderstanding things, it seems there's a workaround here where impacted plugin authors can STOP using the MacOS UI for generating ZIPs and START using the command line to do so. If that does resolve the issue, albeit not resolved within the WP codebase, then I think keeping this as priority=normal and severity=normal feels accurate.

A patch could still be worked on and if there's a 6.4.4 release that comes up organically, then it could get into that minor release and otherwise would likely land in ​6.5 around 26 March 2024.

[nerdpressteam]

@JeffPaul I think the issue is that existing zipfiles are impacted -- so users are having problems updating to already-released new versions.

For future releases, that workaround seems doable until core is fixed. Then again, will most plugin developers be aware of this?

[halounsbury]

Ah, NM. Figured it out.

[colorful tones]

Let's keep in mind that this impacts themes too and not just plugins.

[britner]

I'm 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.

However, anyone on a Mac using Safari when trying to download from the .org repo will have Safari extract the plugin file on download by default (unless they change this in Safari preferences), and then most of those users would be used to compressing using the native mac compress and uploading to their WordPress website. Which is now broken because of the 6.4.3 update.

[welaunchio]

Replying to JeffPaul:

Unless I'm misunderstanding things, it seems there's a workaround here where impacted plugin authors can STOP using the MacOS UI for generating ZIPs and START using the command line to do so. If that does resolve the issue, albeit not resolved within the WP codebase, then I think keeping this as priority=normal and severity=normal feels accurate.

A patch could still be worked on and if there's a 6.4.4 release that comes up organically, then it could get into that minor release and otherwise would likely land in ​6.5 around 26 March 2024.

This is not a solution, only a workaround that 90% of MAC users will NOT understand. Not only authors are affected, even every normal mac user, who zips a folder locally, is AFFECTED.

For me this is still a critical issue. You will get more and more tickets about this in the next hours / days. The CHECKCONS was not there since years, so please just remove it as soon as possilbe and everybody is fine.

[colorful tones]

This impacts any user that tries to upload a .zip to their WordPress site (theme, plugin), and that .zip was generated from macOS (not command-line), which seems to point to a priority=critical item to me.

[jorbin]

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.

I agree with @JeffPaul that a patch should be worked on and once there is one that is ready, it should also be considered for backporting to the 6.4 branch.

[welaunchio]

Replying to jorbin:

Lowering the severity since there is currently a workaround on both the zip creation side ( use the command line) and the individual site side ( add_filter( 'unzip_file_use_ziparchive', '_return_false' ); ).

That als causes a PHP Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function "_return_false" not found or invalid function name in ..

Correct is: add_filter( 'unzip_file_use_ziparchive', '__return_false' );

Two underscores.

[kevincoleman]

Hi @JeffPaul, long time!

Unless I'm misunderstanding things, it seems there's a workaround here where impacted plugin authors can STOP using the MacOS UI for generating ZIPs and START using the command line to do so. If that does resolve the issue, albeit not resolved within the WP codebase, then I think keeping this as priority=normal and severity=normal feels accurate.

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.

Aside: hope you’re doing well. Ping me some time for a catch-up!

[cdevroe]

Replying to jorbin:

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.

Hello @jorbin -- I see the workarounds for plugin authors. We've created a new zip file for our plugin and are distributing it to users that write a support ticket. We're also deploying an update to our plugin today with a zip file created using the preferred workaround.

However, what is the workaround for a WordPress user that is installing or updating a plugin that isn't the author of that plugin? How would they know to unzip the plugin or theme and rezip it?

[costdev]

Fall back to PclZip if ZipArchive::open() does not return true.

[costdev]

I've added 60398.diff which falls back to PclZip if ZipArchive::open() does not return true.

Please test with this and report your results.

[karinclimber]

Replying to cdevroe:

Replying to jorbin:

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.

Hello @jorbin -- I see the workarounds for plugin authors. We've created a new zip file for our plugin and are distributing it to users that write a support ticket. We're also deploying an update to our plugin today with a zip file created using the preferred workaround.

However, what is the workaround for a WordPress user that is installing or updating a plugin that isn't the author of that plugin? How would they know to unzip the plugin or theme and rezip it?

THIS is the issue. This is ALWAYS the issue. 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.

[feastdesignco]

Replying to jorbin:

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.

Strongly disagree that there's a workaround.

This is a massive issue and the workaround is only valid for the 0.01% of the user base that are developers or have access to developers.

99.99% of the real world user base has no workaround for this.

[Otto42]

Replying to britner:

However, anyone on a Mac using Safari when trying to download from the .org repo will have Safari extract the plugin file on download by default (unless they change this in Safari preferences), and then most of those users would be used to compressing using the native mac compress and uploading to their WordPress website. Which is now broken because of the 6.4.3 update.

First, understand that w.org zip files are not affected by this. The zip files we serve will unzip fine for both themes and plugins.

Second, the most common way of downloading a theme or plugin from w,org is to get it directly in the theme or plugins screen. Direct downloads via Safari is a minute proportion of users.

And thirdly, yes, if you unzip it and then make a new zip and then upload that, an if you're using the Mac method, then it's going to have a problem. However, telling people not to unzip it and just upload the original zip file is a easier response to that issue.

Nobody is saying it's not a problem, they are simply saying it's not as critical of an issue as it's being made out to be. There are workarounds for plugin and theme authors, and user impact is minor at best.

[kevincoleman]

Replying to costdev:

I've added 60398.diff which falls back to PclZip if ZipArchive::open() does not return true.

Please test with this and report your results.

Verified that this fix works. I appreciate your prompt fix, @costdev!

What’s the path to widespread deploy of this patch look like?

[azaozz]

Replying to Otto42:

First, understand that w.org zip files are not affected by this. The zip files we serve will unzip fine for both themes and plugins.

Thanks @Otto42, you beat me to it! :)
Was just about to say that all .zip files that are downloaded from the WordPress plugins and themes repositories (whether manually or by using the WP UI to install them) comply with the standards and work properly.

Nobody is saying it's not a problem, they are simply saying it's not as critical of an issue as it's being made out to be.

Yep, agreed. Seems 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.

[room34]

I'm a plugin developer who is distributing a paid version of my plugin outside of the repository and I can assure you this is not a minor issue.

I was only able to find this Trac thread after a user notified me they couldn't upload the plugin, and I spent a half hour testing my files, running multi-file find on the WP core source code, then downloading different versions and running a diff to find out what had changed and when.

Yes I know this is outside of the idealized open source world of core WP development but it's the practical reality of actual sites using the platform. Many users are going to be completely lost and confused, and a lot of developers as well might struggle to track this issue down as quickly as I did.

Consider also the reality that many sites are not just using off-the-shelf themes and plugins. If someone is developing for themselves, making a child theme, etc. there absolutely might be a lot of scenarios where this bug is completely breaking people's workflows who will have no idea how to find a solution.

To address another point I'm seeing: it is not true that only Safari users are affected. That is only the case in the convoluted download-the-zip-and-then-re-zip-it scenario. But this also affects any development of a theme or plugin that ends up in creating a zip file in the Finder on Mac. (Which is how most Mac users, even developers, create zip files.) Sure it does not affect the WP repositories, but it does affect any other distribution of zip files generated on a Mac, which is a practical reality for both independent site builders and developers of themes/plugins distributed elsewhere.

Please keep the severity critical.

(By the way, yes I was able to resolve the issue for myself by re-zipping my plugin at the command line.)

[melcarthus]

Replying to room34:

I'm a plugin developer who is distributing a paid version of my plugin outside of the repository and I can assure you this is not a minor issue.

I was only able to find this Trac thread after a user notified me they couldn't upload the plugin, and I spent a half hour testing my files, running multi-file find on the WP core source code, then downloading different versions and running a diff to find out what had changed and when.

Yes I know this is outside of the idealized open source world of core WP development but it's the practical reality of actual sites using the platform. Many users are going to be completely lost and confused, and a lot of developers as well might struggle to track this issue down as quickly as I did.

Consider also the reality that many sites are not just using off-the-shelf themes and plugins. If someone is developing for themselves, making a child theme, etc. there absolutely might be a lot of scenarios where this bug is completely breaking people's workflows who will have no idea how to find a solution.

To address another point I'm seeing: it is not true that only Safari users are affected. That is only the case in the convoluted download-the-zip-and-then-re-zip-it scenario. But this also affects any development of a theme or plugin that ends up in creating a zip file in the Finder on Mac. (Which is how most Mac users, even developers, create zip files.) Sure it does not affect the WP repositories, but it does affect any other distribution of zip files generated on a Mac, which is a practical reality for both independent site builders and developers of themes/plugins distributed elsewhere.

Please keep the severity critical.

(By the way, yes I was able to resolve the issue for myself by re-zipping my plugin at the command line.)

I was just about to say something similar, not all people who work with/on WordPress have the technical nohow how to edit code, or zip via commandline.

A workaround is not the problem. The problem is everyone spending precious time until they find out this is a bug in wordpress 6.4.3.

I had a deadline that was supposed to go up 2 hours ago when this started happening...

[jorbin]

Plugin demonstrating workaround

[jorbin]

Before going into core, this really should have some automated tests so this can't get reintroduced.

I've uploaded a plugin that demonstrates the workaround. I've also submitted it to the WordPress Repo. Contributions welcome at ​https://github.com/aaronjorbin/force-pclzip (which also demonstrates how you can use GitHub to generate valid zip files from releases)

Further testing is needed, but based on ​https://github.com/nih-at/libzip/commit/b3e3b19e2e4b7d4651d01148f123129429ecc69b, I believe this also only affects sites where PHP is using libzip versions lower than 1.10.1.

Some additional relevant reading: #10403, [15052], #12637.

Replying to welaunchio:

Correct is: add_filter( 'unzip_file_use_ziparchive', '__return_false' );

Two underscores.

Thanks for catching that, I had been typing from my phone. I've fixed it in the original comment.

Trac ticket:

[peterwilsoncc]

In the ​linked pull request:

• introduces a new function wp_zip_file_is_valid()
• If ZipArchive fails and judges the file as invalid, falls back to PclZip to double check (props @costdev)
• adds tests for new function
• adds a macOS generated archive and invalid archives to the test suite

[sayful]

I am also facing same issue. I cannot upload custom plugin to any sites. I also tried with previous zip file that worked properly but not now.

[maartenbelmans]

Not trying to fuel the debate but just chiming in as I think Windows users don't know this:

Safari on Mac has a setting to automatically open safe files after downloading:

This means any zip file downloaded through Safari is automatically unzipped by the OS. Therefore, a Mac user will right click on the folder and use the context menu to zip it again. Their archive is no longer the original downloaded from wp.org, but a newly zipped one by Mac.

This Safari setting is turned on by default so my guess is most non-power Safari users will run into issues.

[olegfuture]

Hi, so we have to wait for the update to 6.4.4? If you archive through the command line, it also works, but what is the difference between this archiving done through the interface

[olegfuture]

add_filter( 'unzip_file_use_ziparchive', 'return_false' ); It works with this filter, but can you tell me how safe and good it is to use it?

[schutzsmith]

Perhaps getting the word out about this issue would be best in the meantime until it can be fixed. I woke up to a few clients asking why uploads were not working on new sites and thankfully saw Arnie Palmer mention this on twitter.

I suggest the marketing team blast this on socials, email, whatever to let WordPress users know about this problem.

[tnolte]

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.

This also causes major problems for more locked down installs of WordPress that don't allow creating these directories outside of their original location. I think this issue should be closed and things should be kept locked down like they are now. And to be very clear this isn't an issue for any plugins in the WordPress.org repository this only affects plugins distributed through other channels. If people are going to be selling plugins, or themes, then they should have to produce redistributable packages under the same restrictions as with what is distributed from WordPress.org.

[tnolte]

Replying to britner:

I'm 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.

However, anyone on a Mac using Safari when trying to download from the .org repo will have Safari extract the plugin file on download by default (unless they change this in Safari preferences), and then most of those users would be used to compressing using the native mac compress and uploading to their WordPress website. Which is now broken because of the 6.4.3 update.

I find it is most likely a rarity that users are manually downloading plugins from WordPress.org to then upload them via zip archive. I pretty sure they would most likely be just browsing the plugin directory from their Dashboard and just clicking install.

[mujuonly]

Replying to tnolte:

Replying to britner:

I'm 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.

However, anyone on a Mac using Safari when trying to download from the .org repo will have Safari extract the plugin file on download by default (unless they change this in Safari preferences), and then most of those users would be used to compressing using the native mac compress and uploading to their WordPress website. Which is now broken because of the 6.4.3 update.

I find it is most likely a rarity that users are manually downloading plugins from WordPress.org to then upload them via zip archive. I pretty sure they would most likely be just browsing the plugin directory from their Dashboard and just clicking install.

This issue doesn't exist with the WordPress repository downloaded zip. This occurs only for the zips that are created by MacOS UI as mentioned in the title.

[courane01]

#60416 was marked as a duplicate.

[jorbin]

#60413 was marked as a duplicate.

[tnolte]

To assist with the current pains, to allow developers time to adjust their packaging processes, can we revert this change behind a feature flag that can be turned back on manually, using a configuration constant?

Then we can clearly plan to re-implement this change, enabled by default, under a given timeline/plan with clear communication and heads up to Devs.

I'm trying to acknowledge the pain that this is causing Devs being caught off guard by this change, but I'd like to see us still push for this change to be on.

[svitlana41319]

Replying to mujuonly:

This issue doesn't exist with the WordPress repository downloaded zip. This occurs only for the zips that are created by MacOS UI as mentioned in the title.

Ubuntu 20.04.6 Desktop: same problem as on MacOS.

[tnolte]

@svitlana41319 how is it that Ubuntu is creating zip archives with a MACOSX folder? Can you provide more details into what is in the Zip archive and your process for packaging? Is this something being caused by the Nautilus?

[audunmb]

Also got this on Manjaro with Gnome Files. On localhost (same place I created the zip file) I don't get the error, but when uploading the same file to a live site I got this error.

There's no macos folders in the zip of course, there has to be something else that causes this.

(Using command line instead of Gnome Files works).

[svitlana41319]

Replying to tnolte:

@svitlana41319 how is it that Ubuntu is creating zip archives with a MACOSX folder? Can you provide more details into what is in the Zip archive and your process for packaging? Is this something being caused by the Nautilus?

No MACOSX folder, and yes, if I create a zip with Nautilus UI, I can't upload it (Incompatible Archive error). If I create it with

zip -vr

it works fine.

The zip file is our plugin ​https://wordpress.org/plugins/maxi-blocks/
Noticed today while testing it before a release.

[cdevroe]

I'm grateful to @costdev @jorbin and @peterwilsoncc (if I missed someone, sorry) for submitting a patch, tests, examples, and getting the PR to the state it is already at. Well done! 👏

I think it is important for those finding this thread after having the issue to know, this issue can effect you regardless of the computer you're currently using. If you're reading through this thread and you're not a Mac user, and yet you had this issue, you might be wondering why.

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 quiet 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. But stay tuned, it appears the WordPress team is working towards a fix.

(I hope the fix is deployed soon!)

[costdev]

@tnolte 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 are many developers that will write a quick, bespoke, and multi-file plugin for a client site and need to upload it, where CI/CD flows are overkill. It's also a common (and unfortunate) occurrence that for some small jobs, developers aren't given FTP access for some work and only have the ability to upload via the Dashboard.

---

To fix or not to fix
there is no question 😉

Fix.

This change had no intention of causing disruption with valid ZIP files, so this is a bug by definition. While we could theoretically decide to keep it and say "tough", the WordPress project has a commitment to backward compatibility. With that in mind, the action most in-line with our commitment is to do what we're doing: Fix the bug so that previously valid ZIPs remain valid.

unzip_file() is a good reference for how we should handle this:

• uses ZipArchive if it's available and hasn't been disabled by add_filter( 'unzip_file_use_ziparchive', '__return_false' );
• ZipArchive checks for consistency in the ZIP (CHECKCONS)
• If ZipArchive can't open the file, unzip_file() will fall back to PclZip.

This fallback is what 6.4.3 is missing, and this ticket's PR adds it.

---

When to release
A working fix is obviously a great step (​please test!), and one of the next steps will be deciding when to get it out there.

This issue, like all issues, has caused disruption. However, sites have not gone down, files have not been deleted, and themes aren't broken. There is a limited number of affected developers, who can repackage their plugins using an alternate method. There is a limited number of affected users, and several alternatives have been mentioned during this discussion. While the workarounds aren't literal one-click solutions, they're available whereas other issues may have no workaround.

The project's processes include us measuring the reach and impact of each bug to package fixes appropriately. Otherwise, we'd be releasing a new WordPress version for every individual fix and pushing to millions of sites and servers 3-4 times a day. That's a lot of room for something to go wrong, and even if it always went right, can you imagine the update email spam? 💀

We will be continuing to monitor other issues and fixes to determine how we can best package these for release as soon as possible.

---

Until then, what do I do if I have this issue?

• Users/Site owners/Site developers: Download, install and activate the workaround plugin (Safari users: Option+Click the link, or disable this setting before downloading the plugin)
• Plugin/Theme authors: If your non-Safari users are reporting that your ZIP isn't uploading, repackage your plugin or theme using a commandline tool rather than Finder/Nautilus/Gnome/etc. For your Safari users, direct them to the point above.
• QA: Test ​the fix so we can be extra confident that the issue is fully resolved.
• Everyone: Help get the word out there about this work being well underway and the available workarounds.

[StephenCronin]

Hi. I'll just chip in with my 2c as someone who works for Envato.

It looks like this issue has broken backwards compatibility for potentially tens of thousands of themes / plugins and is going to cause end users (and developers) a lot of frustration.

I don't think it's helpful to say "Wp.org themes and plugins are okay, so it's not really a problem". There are literally tens of thousands of themes and plugins outside the wp.org repo and an unknown percentage of these will be affected. From a very small sample of the ThemeForest/CodeCanyon themes/plugins sitting on my hard drive (about 20), 10% encountered this problem. We have 12,000 themes and 5,000 plugins, so that's potentially a lot of items and people affected.

I also don't think it's helpful to say "Well developers should not be creating zip files manually" - that might be true, but 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.

It sounds like a backward compatible solution is in the works, which is great! I'd urge the team to please consider releasing this as soon as possible given the significant number of people who may be affected.

Thanks both for your hard work in general and for hopefully considering this.

[peterwilsoncc]

@audunmb Are you able to upload an example of the Manjaro with Gnome Files you are having issues with? To avoid confusion, are you able to name it archive-gnome-broken.zip or similar?

[costdev]

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

Indeed! We give that warning in advance of a release for any intentional (albeit rare) breaking change.

That's the key thing with this issue: The breaking change wasn't intentional, which is why it was only noticed after release, and why we got started right away to investigate, fix, and provide as many workarounds as possible until the fix has been released.

[StephenCronin]

Replying to costdev:

Indeed! We give that warning in advance of a release for any intentional (albeit rare) breaking change.

That's the key thing with this issue: The breaking change wasn't intentional, which is why it was only noticed after release, and why we got started right away to investigate, fix, and provide as many workarounds as possible until the fix has been released.

Thanks for the response. I should have emphasised that I understood the situation & decision and thought that was the right/great outcome. The sentence you were responding to was more of a counterweight to some of the views expressed earlier (before the decision had been made). I just felt it worthwhile to present an alternative viewpoint.

Anyway, I would repeat what I said earlier about the sooner it's released, the better (we are seeing users impacted by this), but thanks for all the work going into resolving this! It's much appreciated.

For the record (I've provided this info directly to Peter), I've tested the fix (5996) and can confirm that theme and plugin zips that I couldn't load in 6.4.3 can be loaded in the fixed version.

[audunmb]

Example of file made with Gnome Files that doesn't work.

[svitlana41319]

Here is one from Ubuntu 20.04.6 LTS, Nautilus 3.36.3-stable

[jsandtro]

I dont think this is a MacOS only issue. I have the same problems on Windows.

[vikram6]

I'd like to +1 upgrading this to a critical bug and releasing a fix ASAP.

I work at a WordPress hosting company and a number of our customers have already reached out to us about this issue. Most of them were not even aware of this bug and we had to show them how to manually apply the workaround to their sites. We've also seen cases where customers simply downgrade back to 6.4.2 and this means that their sites do not have the latest security patches and the sites are left vulnerable.

In the next two weeks, we're planning to upgrade all sites on our platform to 6.4.3 in order to apply the security patches. We're going to get hundredes of calls asking us to rollback the change and this is going to cause a lot of pain both to our customers and to us.

This bug will continue to cause disruption to site owners, plugin/theme authors and hosting providers. Once the patch has been fully tested and it's ready to go, I humbly request that we release a 6.4.4 ASAP.

Thank you for everyone's hard work on this.

[JeffPaul]

@jsandtro Are you able to upload an example of a Windows ZIP you are having issues with as well as describing how you're generating that ZIP file? To avoid confusion, are you able to name it windows-broken.zip or similar? This will help with further triage here, thanks!

[jsandtro]

Replying to JeffPaul:

It is a licensed file, but I shall hear with the provider if they can contribute.

[costdev]

@jsandtro Just checking:

Are you reporting that:

1. A ZIP file that was created on Windows isn't uploading?

or

2. You're on Windows, and a ZIP file you downloaded from elsewhere isn't uploading?

[jorbin]

​https://github.com/WordPress/wordpress-develop/pull/5996 is looking good. I don't think we need to wait for the additional zip files, but if some come in they can be committed as follow ups.

In the next two weeks, we're planning to upgrade all sites on our platform to 6.4.3 in order to apply the security patches. We're going to get hundredes of calls asking us to rollback the change and this is going to cause a lot of pain both to our customers and to us.

If you are strongly concerned about support, I would suggest you look into either using the provided plugin or applying the patch in 5996 to your sites.

[peterwilsoncc]

In 57537:

Upload: Fallback to PclZip to validate ZIP file uploads.

ZipArchive can fail to validate ZIP files correctly and report valid files as invalid. This introduces a fallback to PclZip to check validity of files if ZipArchive fails them.

This introduces the new function wp_zip_file_is_valid() to validate archives.

Follow up to [57388].

Props audunmb, azaozz, britner, cdevroe, colorful-tones, costdev, courane01, endymion00, feastdesignco, halounsbury, jeffpaul, johnbillion, jorbin, jsandtro, karinclimber, kevincoleman, koesper, maartenbelmans, mathewemoore, melcarthus, mujuonly, nerdpressteam, olegfuture, otto42, peterwilsoncc, room34, sayful, schutzsmith, stephencronin, svitlana41319, swissspidy, tnolte, tobiasbg, vikram6, welaunchio.
Fixes #60398.

[peterwilsoncc]

Reopening for backporting.

Committed r57537 / ​https://github.com/WordPress/wordpress-develop/commit/2ac96bcd07ca615216cedbd855d641fca65853e5

[jorbin]

[57537] is good for backporting to the 6.4 branch.

[vikram6]

Replying to jorbin:

If you are strongly concerned about support, I would suggest you look into either using the provided plugin or applying the patch in 5996 to your sites.

Are the workaround plugin and patch compatible with each other? To elaborate - If I apply the workaround plugin to a site and the patch is later released in 6.5 and I update the site to 6.5, would that cause any issues on my site? Wanting to make sure that the workaround AND the patch existing together won't cause any issues.

[mattormeeple]

I can verify that the committed fix works as expected with zip files created via macOS Finder. Tested with nightly 6.5 nightly 6.5-alpha-57555.

I strongly agree that this should be made available in a 6.4.4 fix.

[cteduard]

One more request to release 6.4.4 with this fix. Many of our customers have been hit by this bug and it is a pain to tell them to upload things through FTP...

[wetah]

Just wanted to add here that I'm facing the same issue on Linux as well. On Ubuntu 23.10, using Gnome's default compresser directly from Nautilus, both plugins and themes generate the error. Via command line things go fine.

[costdev]

#60588 was marked as a duplicate.

[adegans]

It's been days and a fix has been made weeks ago.
Why is there no release for 6.4.4 set yet?
(https://core.trac.wordpress.org/milestone/6.4.4)

Are you (wp people) intentionally trying to kill off non-repo plugins and themes or what?

[welaunchio]

Yeah please push this update now.

I received tons of support queries, bad ratings and refunds for my plugins, because of this change!

[room34]

Replying to welaunchio:

Yeah please push this update now.

I received tons of support queries, bad ratings and refunds for my plugins, because of this change!

To be fair to the core team, there is a fairly simple workaround for devs (zipping at command line instead of in the Finder), and by implementing it quickly with my own commercial plugin I was able to bypass this issue. But this inaction on their part does seem to reflect a general disregard for the larger ecosystem around WordPress.

Open source purists may not appreciate the fact that people have built businesses around commercial uses of WordPress outside of the repository, but WordPress wouldn't be as huge as it is without us. This is a fairly straightforward situation, I think. The update needs to be released without further delay.

[adegans]

@welaunchio Yep same here, frustrated users, several refund requests and multiple tickets a day about this... Very frustrating for devs too.

To be fair to the core team, there is a fairly simple workaround for devs (zipping at command line instead of in the Finder), and by implementing it quickly with my own commercial plugin I was able to bypass this issue. But this inaction on their part does seem to reflect a general disregard for the larger ecosystem around WordPress.

@room34 No! WordPress should conform/support whatever major operating systems provide/do and be compatible with them. Not make unthoughtful updates like this and then make a large part of users wait on a fix that appears to have been ready for at least 2 weeks. I don't know their testing process and I do appreciate testing exists and takes time, but restoring functions/compatibility for something that has worked for over 10 years should not take this long.

Not to mention what @StephenCronin said about backwards compatibility for a bazillion older files already in place, which work fine, have worked fine and will work fine for years...

[room34]

Replying to adegans:

@welaunchio Yep same here, frustrated users, several refund requests and multiple tickets a day about this... Very frustrating for devs too.

To be fair to the core team, there is a fairly simple workaround for devs (zipping at command line instead of in the Finder), and by implementing it quickly with my own commercial plugin I was able to bypass this issue. But this inaction on their part does seem to reflect a general disregard for the larger ecosystem around WordPress.

@room34 No!

You clearly didn't read my entire message.

I think we as plugin/theme devs need to be proactive and pragmatic and use any available workaround ASAP to reduce our own headaches, but the core team also needs to release this update ASAP.

[adegans]

I did, except for the last line and I misinterpreted the 2nd paragraph... Oops :-(

[jorbin]

Are you (wp people) intentionally trying to kill off non-repo plugins and themes or what?

No.

Open-source purists may not appreciate the fact that people have built businesses around commercial uses of WordPress outside of the repository, but WordPress wouldn't be as huge as it is without us. This is a fairly straightforward situation, I think. The update needs to be released without further delay.

You are correct that this is straightforward. There are multiple workarounds available and there is a release scheduled for less than a month from now. There is no evidence of this bug damaging users sites.

I think that the rationale that costdev shared above remains accurate:

This issue, like all issues, has caused disruption. However, sites have not gone down, files have not been deleted, and themes aren't broken. There is a limited number of affected developers, who can repackage their plugins using an alternate method. There is a limited number of affected users, and several alternatives have been mentioned during this discussion. While the workarounds aren't literal one-click solutions, they're available whereas other issues may have no workaround.

The project's processes include us measuring the reach and impact of each bug to package fixes appropriately. Otherwise, we'd be releasing a new WordPress version for every individual fix and pushing to millions of sites and servers 3-4 times a day. That's a lot of room for something to go wrong, and even if it always went right, can you imagine the update email spam? 💀

We will be continuing to monitor other issues and fixes to determine how we can best package these for release as soon as possible.

I've yet to hear any rationale that makes me want to reconsider the classification of this from a normal severity bug and not something to trigger a release on it's own, though I have ​reached out to the forums team to see if there have been an unusual amount of users opening issues. They have not raised any flags, but checking in to hear from those contributors makes sense to me.

[adegans]

Well, guess we'll all have to recommend ClassicPress while we wait for your release schedule to finally clear up...

[Otto42]

Replying to adegans:

Well, guess we'll all have to recommend ClassicPress while we wait for your release schedule to finally clear up...

As ClassicPress is open source software too, feel free to use it if that's your preference. We also highly recommend Drupal, or any other open source software. We are not in competition with them. As far as we are concerned, the more open source software gets used, the better.

[hiddenpearls]

I'd like to +1 upgrading this to a critical bug and release a fix ASAP.

[jorbin]

Replying to hiddenpearls:

I'd like to +1 upgrading this to a critical bug and release a fix ASAP.

If you have new data or new information that you think is relevant, please share it but changing the severity of a ticket where the decision on its severity has been documented by multiple committers is entirely unhelpful.

[kevincoleman]

Replying to jorbin:

Replying to hiddenpearls:

I'd like to +1 upgrading this to a critical bug and release a fix ASAP.

If you have new data or new information that you think is relevant, please share it but changing the severity of a ticket where the decision on its severity has been documented by multiple committers is entirely unhelpful.

Respectfully (and I do highly respect WordPress committers and their sacrifice), this reads very poorly. To translate to how the WordPress community sees this statement it feels like you’re saying: “your opinion doesn’t count because you’re not a committer” and it implies that your minds can’t be changed by the likes of the peons merely using WordPress. While that is ostensibly (and very apparently) true, I’d argue it’s a pretty jaded thing to say outright.

I personally think this attitude is a different problem from the one this ticket addresses. The severity of the ticket may or may not be right, but I don’t think this reply is helping WordPress-community relations in the slightest.

[adegans]

Replying to kevincoleman:

Respectfully (and I do highly respect WordPress committers and their sacrifice), this reads very poorly. To translate to how the WordPress community sees this statement it feels like you’re saying: “your opinion doesn’t count because you’re not a committer” and it implies that your minds can’t be changed by the likes of the peons merely using WordPress. While that is ostensibly (and very apparently) true, I’d argue it’s a pretty jaded thing to say outright.

I personally think this attitude is a different problem from the one this ticket addresses. The severity of the ticket may or may not be right, but I don’t think this reply is helping WordPress-community relations in the slightest.

Yup - Very poorly, almost like they don’t want to fix this.

To me, that just shows that everyone who offers plugins and themes outside of their channels does not matter. But that has been lurking under the surface ever since the focus shifted to Gutenberg.

[adegans]

Another thing, after my first reply here I redid all my zipfiles with the suggested method of doing it through Terminal.
I’m on macOS, using this command from the parent folder of the folder i want to compress.

zip -r plugin-slug.zip plugin-slug/

I think that’s about a week ago I did that, and some users today who got plugins after I ‘fixed things’ are still complaining about incompatible archive errors.
Maybe I did something wrong, I’m no terminal guy or zip expert, but the workaround doesn’t work reliably it seems.

:-(

[room34]

Replying to adegans:

I’m on macOS, using this command from the parent folder of the folder i want to compress.

zip -r plugin-slug.zip plugin-slug/

I’m in the same boat with my plugin. Try using zip -vr instead of just zip -r — the v switch removes some of the Finder’s hidden files which seem to be what is tripping up WordPress on the upload.

[costdev]

@adegans If the ZIP uploads fine for you (if not, see if @room34's comment above works for you), then it should work fine for the users, which points to something going on in between you providing the ZIP, and them uploading it.

Do you know if the users were downloading the ZIP using Safari? If so, they may need to uncheck this box because Safari unpacks ZIPs by default, meaning the users may be re-ZIPping using the UI.

---

“your opinion doesn’t count because you’re not a committer” and it implies that your minds can’t be changed by the likes of the peons merely using WordPress.

Your opinion counts, as does everyone else's in this ticket. Our minds can be changed with new information. We're not better than you, we just have the added responsibility of making a decision. We consider your opinion, the impact on you and your users, the reach of an issue, available workarounds, whether sites go down/files get deleted/databases become corrupted, other fixes available to bundle, the availability of a release squad, whether releasing a new WordPress version containing only this bugfix sets a negative or unsustainable precedent, as well as any context-specific factors.

---

Yup - Very poorly, almost like they don’t want to fix this.

That's not the case. I've put a lot of time into investigation trying to ensure the fix was the correct one, alongside other contributors and committers.

To be clear: The fix will be in WordPress 6.5. The discussion is about whether a 6.4.x minor release is issued containing only this fix.

We have multiple factors to consider, and the opinions of those affected are of course a big part of that. We have a responsibility to make the right decision as we see it at the time. We read and consider every comment in context, and we discuss - publicly, as above - a comment and whether it changes the circumstances influencing a decision.

To me, that just shows that everyone who offers plugins and themes outside of their channels does not matter

No one in the WordPress project, committer or otherwise, thinks that. Extenders matter regardless of where they offer their extensions from. I also offer plugins outside of the WordPress.org channel. My day job (I volunteer to WordPress Core) as an agency developer means I also feel the impact of this issue. That doesn't change my responsibility as a Committer to consider all factors (actually makes it a bit harder in this case 😅).

---

The decision about releasing this fix in a 6.4.x minor can change. As we've already factored existing information into the current decision, a different decision requires new information.

[adegans]

Seeing none of our requests and arguments have any impact I'm giving up.

How do I turn off notifications for this ticket?
I'm not very familiar with trac and don't see how to do it in my preferences or the TracTickets manual.

[askwpgirl]

This is a critical issue. This is basic stuff. Don't expect every person on the planet to know that they can't use their Mac OS for zipping files. Zipped files are ubiquitously used in the WordPress eco-system.

I have already been unable to install several plugins due to this issue. I have had to re-archive them to install or use the filter. And I only know this because I am "in the know" and actively on social media. Any average user will be stumped and not know who to turn to and may take days to get resolved after they have perhaps chased down their web host who then tells them to talk to their plugin or theme dev. And that theme dev or plugin dev may not be even available or all that accessible. So then you have third-party person they might find somewhere (often the host) telling the to add this filter to a code snippets plugin. And inevitably, they will do it wrong due to curly single quote or whatever and crash their site.

This needs fixed in a patch, not next major version. Core team is wrong to think the workarounds are practical for the vast majority of people in the world. And that 6.5 will fix this. People will be running 6.4.3 for a long time, and the people most impacted will be end users as well as any person providing support at any level for WP including designers, builders, web hosts, etc.

This isn't just a theme and plugin developer issue. To think of it that way is very myopic. This fundamentally impacts users and will continue to impact users for a long time if not fixed in 6.4.

This isn't a "new feature" to be added in a major version. This is a major bug to be patched in the major version it was introduced in.

There will be so many Envato plugins and themes with incompatible archives. The ripples of this will be felt for a long time.

What is fundamentally the problem here is not understanding how the real world uses WordPress. How real people use WordPress, and how real users approach problems. And that's whom we should be concerned with in the end. Not the developers but the users.

WordPress is not built solely for developers, nor are all WordPress sites built by developers. WordPress is ultimately for the users. We need to get our priorities straight.

[room34]

Replying to askwpgirl:

WordPress is not built solely for developers, nor are all WordPress sites built by developers. WordPress is ultimately for the users. We need to get our priorities straight.

Core team is proving here that it’s possible to be very closed-minded when it comes to open source. We lowly real-world devs/users are just defiling the purity of their vision.

I guess. I mean it sounds petty for me to put it like that, but it sure feels that way.

I’ve been lucky that I’m enough of a devops nerd that using the command line to zip my plugin isn’t a problem and I’ve avoided too much end user support hassle or loss of revenue over this issue, but it is really putting into stark relief the chasm of perception of what WordPress is and should be, between the core team and the rest of us.

I’ve given up any hope of a 6.4.4 release at this point, and I suspect any further discussion here is just going to make the rift worse. 6.5 is right around the corner. But days can feel like weeks in a situation like this.

[kevincoleman]

I think it’s pretty easy to see how this ticket ends up. Even if the minds of the core committers could be reasonably changed by a flood of comments here (which appears debatable at current), that may take long enough that we’ll be at the next release/milestone anyway and it’ll be a moot point. In short, that just means this ticket will be a shining, archived example of how even though the core devs can “be right” the bug will run its course at the PR expense of the WordPress community. As has been mentioned before, this kind of blunder is doomed to repeat itself with any project lacking good community relations management, open- or closed-source.

And let me be clear: the core committers bring tremendous value to the table here—it’s just that the value is largely realized in technical ability and commitment, not socially as in community relations. They should not be berated for making decisions like this that are technically sound. The failure here is in not having proper user experience representation. It’s an often overlooked role. UX is a hard job, which is often misunderstood and sidelined. This is often an area that suffers in open source projects where the social structure appears more democratic, but frankly UX is undervalued almost everywhere.

I think it’s probably the right choice to abandon this ticket, because unless we want to take steps to fix the UX and community inadequacies all it’s doing is making more noise to get in the way. We just have to accept that breakages happen sometimes, and if we collectively take steps to help (not just complain) we can potentially fix some of the future breakages.

Also, pause to be grateful to the core team. Even if they are making the wrong call here (I’m still unsure), they are making hard calls. That’s stressful. Please remember we’re all on the same side here.

[askwpgirl]

Replying to room34:

Replying to askwpgirl:

WordPress is not built solely for developers, nor are all WordPress sites built by developers. WordPress is ultimately for the users. We need to get our priorities straight.

Core team is proving here that it’s possible to be very closed-minded when it comes to open source. We lowly real-world devs/users are just defiling the purity of their vision.

I guess. I mean it sounds petty for me to put it like that, but it sure feels that way.

I’ve been lucky that I’m enough of a devops nerd that using the command line to zip my plugin isn’t a problem and I’ve avoided too much end user support hassle or loss of revenue over this issue, but it is really putting into stark relief the chasm of perception of what WordPress is and should be, between the core team and the rest of us.

I’ve given up any hope of a 6.4.4 release at this point, and I suspect any further discussion here is just going to make the rift worse. 6.5 is right around the corner. But days can feel like weeks in a situation like this.

All good points, except I haven't seen this type of huge bug introduced in a patch not fixed in a subsequent patch. It seems due to the view that developers can workaround it, then it's not really an issue.

Would be like if theme or plugin uploads stopped working altogether, and they told users to just use wp_cli or SFTP to upload their themes and plugins instead. Sure, that works, but no non-dev can do that practically.

Anyway, 835 million sites use WordPress. As of now 41,750,000 of those run WordPress 6.2. So millions of sites will have this bug for quite awhile if as many people continue to run 6.4 for as long as they have been running 6.2.

The idea that this will go away in a few weeks in 6.5 is a fantasy. 6.5 does not make this problem go away.

But I do hear all your other points. WordPress is massive. This has ripple effects.

[Endymion00]

Maybe this will change things because the scope of this issue is much broader than 6.4 and to me requires a point release for each branch going back to 4.1

I did some spot checking with versions I had running and it appears that every branch that received the January 30, 2024 update is broken.

Branches/versions I confirmed with the issue.

6.2.4
5.9.9
5.8.9
5.6.13
5.4.15
5.2.20
4.9.25
4.1.40 - Fails with a timeout rather than the incompatible archive message.

So, I think it's a fair assumption that the in-between versions updated on January 30, 2024 share the same results.

And this is why each of these branches needs a point release as soon as possible because 6.5 won't fix them unless they all get patched then as well, so there would still need to be a 6.4.4, etc. with the fix.

[jorbin]

An additional workaround is now available. The plugin shared earlier is now available in ​the WordPress.org repository and thus is now available for installation directly from individual site dashboards. Searching for force pclzip brought it up as the first result for me.

Also, as a reminder that while security patches are backported as a courtesy to folks who have not updated, the only supported version of WordPress is the most recent one (6.4 as of this writing).

[adegans]

Replying to jorbin:

An additional workaround is now available. The plugin shared earlier is now available in ​the WordPress.org repository and thus is now available for installation directly from individual site dashboards. Searching for force pclzip brought it up as the first result for me.

Great, but we don't want more workarounds, we want WP to support all popular/common types of zip files.
Releasing plugins for a problem you guys (accidentally) created and supposedly are fixing "within a month" is a waste of time, time better spent on releasing a real solution.

And then - "A workaround for users who are dealing with improperly created zip files."

Really? Improperly?

You (the wp peoples) choose to not support certain types of zip files. That's very different from implying linux and macOS users using built-in tools is wrong...
Operating systems decides what's proper or not. Not you or WP devs. OS developers do.

[askwpgirl]

The challenge is that you assume that all the hundreds of millions WordPress users in the world are part of the inner circle of WordPress core development and are "in the know". And that they will MAGICALLY AND MYSTICALLY KNOW that this error message relates to a bug that WordPress core devs created for a functionality that has worked for as long as any of them have used WordPress. And via this magical psychic connection to the inner circle of they great Oz of WordPress, they will be made aware through a visitation or a dream or perhaps the zeitgeist that they need to go find this specific plugin to workaround it.

The myopic worldview here is astounding to me. Since this effects every branch 6.4 and back, this problem is going to be an issue for long time. Not just for users but for every single person who supports them.

I get the hating on Mac OS zip files. I really do, but why decide this late in the game to stick it to Steve Jobs with a totally unhelpful error message? At least say, "You suck because you use Mac OS and don't know command line or that Mac OS zip files suck, so you're going to have to download this other plugin <link> and install it before you try to upload your sucky Mac OS zip file again."

That would certainly be more useful.

[adegans]

Where is this ticket in the 6.5 release?

https://core.trac.wordpress.org/query?status=closed&changetime=02%2F27%2F2024..03%2F05%2F2024&milestone=6.5&col=id&col=milestone&col=owner&col=type&col=priority&order=id

[room34]

Replying to adegans:

Where is this ticket in the 6.5 release?

https://core.trac.wordpress.org/query?status=closed&changetime=02%2F27%2F2024..03%2F05%2F2024&milestone=6.5&col=id&col=milestone&col=owner&col=type&col=priority&order=id

+1 to this!

After all of this back-and-forth, to omit this fix from the 6.5 release would be inexcusable!

Edit: I see that @costdev did say that this would be included in 6.5. But yeah… I'm not seeing it in that list.

[peterwilsoncc]

@adegans @room34 The fix has been committed for the 6.5 release.

This ticket is currently open on the 6.4.4 milestone as a candidate in the event a 6.4.x release is made prior to the release of 6.5. The correct report to review is open next minor tickets.

If there isn't a 6.4.4 release this will be moved the the 6.5 milestone and reclosed.

[adegans]

As you well know, so far we've been stonewalled and ignored for a 6.4.whatever release. So just update the ticket to 6.5 already instead of leaving it to chance... Or is that too much forward and logical thinking for whoever makes these decisions?

I don't have that access, and being forgotten once RC2 or GM rolls around is just a opportunity waiting to happen to further sabotage the dev community at large...

[room34]

Replying to peterwilsoncc:

@adegans @room34 The fix has been committed for the 6.5 release.

This ticket is currently open on the 6.4.4 milestone as a candidate in the event a 6.4.x release is made prior to the release of 6.5. The correct report to review is open next minor tickets.

If there isn't a 6.4.4 release this will be moved the the 6.5 milestone and reclosed.

Thank you for clarifying.

[adegans]

Mac Users -
While we wait, or if you just want to make "clean" zip files, take a look at the Finder action workflow I just made.

This workflow lets you create compatible zipfiles from Finder without using Terminal straight from the Finder context Menu.
See how it works here: ​https://ajdg.solutions/blog/create-zip-archives-in-macos-in-finder-without-using-terminal/

[manfcarlo]

Replying to costdev:

The discussion is about whether a 6.4.x minor release is issued containing only this fix.

In case anyone was not aware, there is another ticket #60290 with a similar commit [57685] that has been added to 6.5 but not 6.4 where the bug was first introduced, so there is the potential of 6.4.4 bundling both fixes.

[SergeyBiryukov]

Looks like this was fixed in [57537] for trunk but not backported to the 6.5 branch.

Moving to 6.5.1, as there are no plans for 6.4.4 at this time.

[room34]

Replying to SergeyBiryukov:

Looks like this was fixed in [57537] for trunk but not backported to the 6.5 branch.

Moving to 6.5.1, as there are no plans for 6.4.4 at this time.

So @peterwilsoncc's statement that it was committed for 6.5 was incorrect? How can we be certain it absolutely will be included in 6.5.1?

[TobiasBg]

@SergeyBiryukov: [57537] was committed to trunk before 6.5 was branched (in [57781]), no?

However, wp_zip_file_is_valid()'s @since tag should be changed from 6.4.4 to 6.5.0.

[Endymion00]

"as there are no plans for 6.4.4 at this time."

Why would you choose to leave the last 10 years of branches broken... at this time?

I struggle to rationalize the thinking behind that. I know you want to push people to the latest but not every site can.

[SergeyBiryukov]

In 57916:

Docs: Update @since version for wp_zip_file_is_valid().

Follow-up to [57537].

Props TobiasBg.
See #60398.

[SergeyBiryukov]

Replying to TobiasBg:

[57537] was committed to trunk before 6.5 was branched (in [57781]), no?

Ah yes, you're right, thanks!

Replying to Endymion00:

Why would you choose to leave the last 10 years of branches broken... at this time?

Cleaning up the unreleased 6.4.4 milestone was a part of the ​6.5 release checklist.

I think the ticket can remain open for now to consider backporting to older branches.

[adegans]

Replying to Endymion00:

"as there are no plans for 6.4.4 at this time."

Why would you choose to leave the last 10 years of branches broken... at this time?

I struggle to rationalize the thinking behind that. I know you want to push people to the latest but not every site can.

Yep, as has been the argument for most of this pointless ticket...

And the fix not being in 6.5, or maybe it is, but nobody really knows... Also as expected and predicted.

Plus, once again... WP does not get to dictate what a valid zip file is. Operating systems do and CMS like WP using such files just have to deal with it. Regardless of the pointlessness of meta files and other OS specific crap.

[peterwilsoncc]

Replying to adegans:

And the fix not being in 6.5, or maybe it is, but nobody really knows... Also as expected and predicted.

The fix is definitely included in WordPress 6.5. It was committed prior to the 6.5 branch being created as discussed above.

The code can be seen on the 6.5 tag.

[jorbin]

In 57929:

Upload: Fallback to PclZip to validate ZIP file uploads.

ZipArchive can fail to validate ZIP files correctly and report valid files as invalid. This introduces a fallback to PclZip to check validity of files if ZipArchive fails them.

This introduces the new function wp_zip_file_is_valid() to validate archives.

Follow up to [57388].

Reviewed by jorbin.
Merges [57537] to the 6.4 branch.

Props audunmb, azaozz, britner, cdevroe, colorful-tones, costdev, courane01, endymion00, feastdesignco, halounsbury, jeffpaul, johnbillion, jorbin, jsandtro, karinclimber, kevincoleman, koesper, maartenbelmans, mathewemoore, melcarthus, mujuonly, nerdpressteam, olegfuture, otto42, peterwilsoncc, room34, sayful, schutzsmith, stephencronin, svitlana41319, swissspidy, tnolte, tobiasbg, vikram6, welaunchio.
Fixes #60398.

[TobiasBg]

@SergeyBiryukov: With [57929] porting the changes (and wp_zip_file_is_valid()) to the WP 6.4 branch, and WP 6.4.4 now released, [57916] needs to be reverted. Thanks!

[davidbaumwald]

Milestone renamed

[SergeyBiryukov]

In 57984:

Docs: Update @since version for wp_zip_file_is_valid().

Follow-up to [57537], [57916], [57929].

Props TobiasBg.
See #60398.