Recent searches
Search options
Zip files created in #MacOS stopped working in #WordPress 6.4.3
https://wordpress.org/support/topic/zip-files-created-in-macos-stopped-working-in-wordpress-6-4-3/
@davidbisset As a plugin developer, and site maintainer for many clients, my stance is that developers should't be creating zip archives of their plugins on any desktop, let alone macOS.
There is no excuse these days for premium plugins not to be using a CI/CD process for plugin/them builds.
I see it as bad practice for Devs to be using their personal machines for builds. This is a situation ripe for spreading malware in plugins and themes.
Also, as I see it the people this is a problem for are 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.
cc @davidbisset
@tim you’re not wrong. Although I don’t believe you need a complex built system or process to produce commercial software, or even in the repo. In some cases, it makes sense. Those systems come with their own trade-offs, discussion for another thread.
But I have already hit this problem yesterday creating a simple plug-in that I zipped up for one user that only knows how to upload zip files manually. It’s a legit use case so I’m sure this problem will be resolved.
@davidbisset I hope it's not. I've been dealing for years with premium plugin developers breaking our plugin updates process because they have these junk MACOSX folders in their archives. And as the Trac ticket pointed out there are alternatives to using the macOS right-click archive that don't have this problem.
As I just pointed out to someone else developing software for other platforms like macOS or Windows requires very restrictive distribution controls. IMO this change is the right path.
@tim That's an interesting take. Even with that, I would think or hope that "“Incompatible Archive" as the only response would be made more user friendly and not have to rely on a minatory experience and opinion of WordPress developers adding comments and opinions in .org forums. 
Will be interesting to see how this plays out.
@davidbisset so, I've been a developer for probably 30 years, and have done development in corporate environments and with a ton of other languages and platforms. So I have a broader perspective on this from a professional standpoint.
@tim I have one theme and one plugin in the directory and it was wild to me when I learned this works by uploading zips.
Let me hook it up to a Git repository and tag my releases. It’s 2024.
@tim @davidbisset To me, this sounds like you want to force people using a more specific workflow because you think it might be better. I don’t think, it’s up to anyone to decide such thing for someone else.
All basically working ZIP files should be working in WordPress.
100% what @matze said. While I agree as a professional business you ideally have CI/CD, #WordPress is way bigger than pro plugins @tim
E.g. I just used the zip upload for a quick demo for students. While I am an experienced developer and know how to handle a "professional" workflow I haven't forgotten how I got started and I strongly object to the trend in the recent years to look down and hobby users and beginners by complicating workflows from the beginning.
@davidbisset
@kraftner from a security standpoint I disagree. I don't have any problem with learning but being OK with teaching people wrong is also not something I'm OK with.
Case in point, my son is learning web development and the instructor literally taught him that H# tags are just about changing the font size. I told my son that the instructor was wrong and my son replied that "it doesn't matter". I as so pissed as someone who advocates for using HTML properly for a11y.
@tim @kraftner @davidbisset In this case, it’s just about how the ZIP file is created. How is that a security issue? I can create a perfectly valid file on the same machine using CLI. It’s practically the same environment, just a different method. The one is currently declined by WordPress, the other isn’t. None of them has, in this limited scope, a security implication. And that’s basically the scope of the issue.
@matze to a degree but it goes deeper than that. I saw this change as a way to improve the packaging standards walking back on it just leaves the door open.
I still have my opinion that zip archives should be rejected by WordPress if they have anything at the top level besides the plugin directory. Regardless of how they were created. There is an aspect where I feel like this is an issue with other software and not WordPress, and was exposed. 
@tim @kraftner @davidbisset Even if, this should be nothing for a patch release, since it’s a huge breaking change. I understand your desire, but I don’t think the current issue is worth it. As part of a bigger change in a proper release with breaking changes and proper announcement, sure. But not breaking it silently and then ignore feedback and leaving it as is.
@matze ah, yes. So on that topic I actually do 100% agree. I noted this to a degree in one of my comments in the Trac ticket actually. I agree that a breaking change in a point release, regardless of what it is, is actually the bigger picture issue at hand. That should be more clearly called out instead of the issue with the actual code change.
@tim
Again, while I agree in theory, from my teaching practice I know that often sloppy shortcuts are necessary *at the beginning*.
If I had been forced to use CD, perfect security practices etc. I would have surely given up as a student writing my first crappy theme in my free time.
Sticking with the <hX> example: To explain this you need to explain the whole concepts of semantics and a11y. If you have very limited time and mental capacity in a beginners course this just isn't viable.
@matze
@matze @davidbisset so this isn't about workflow, this is about packaging standards as well as security. There is literally no oversight into what ends up in a manually generated zip file. Pretty much all other means of software distribution have clear restrictions on packaging & distribution. And even if there are options to work around those restrictions they are not on by default with a big warning about the risks. Apple does this with downloads that don't come from the App Store.
So much chat on that forum post but nobody seemingly reporting it. Thankfully, someone had: https://core.trac.wordpress.org/ticket/60398. A fix is due in 6.4.4.