It’s true, WordPress has always been a little bit hard to take seriously, what with the Hello Dolly plugin being part of the base installation.1
As much as I have devoted the last decade of my professional career to WordPress (and used it fairly extensively for several years before that), I have never had much appreciation for Matt’s sense of humor or his perspective on things. I’ve invested myself in WordPress despite Matt, not because of him.
But the turn things have taken over the past 3 months has come as a surprise even to a Matt skeptic like me. He really just seems to be going completely off the rails in this vendetta against WP Engine, and he’s absolutely dragging down the entire WordPress ecosystem in the process.
It’s an extremely frustrating and tenuous position to be in, as a developer of a plugin that is becoming an increasingly large portion of my livelihood. I know that the majority of the sales of my commercial plugin are fed by users starting out with the free version of the plugin that’s distributed through the WordPress Plugin Directory. It just does not sit right with me that the source that feeds so much of the WordPress ecosystem, both free and commercial, is controlled by a single individual (said individual’s disingenuous protestations otherwise notwithstanding). It’s especially concerning when that single individual makes unilateral decisions of great impact on the entire community with the kind of capriciousness and petulance Matt has been demonstrating lately. (Even though I do like pineapple on pizza.)
I know it’s dangerous to my very livelihood for me to be writing this. Much like the Rebellion’s one-man fighters against the Death Star, I’m too small to be a threat.2 But I’m also sure Matt wouldn’t think twice about kicking my plugins out of the directory if he saw this on a bad day. I’m literally nothing to him, but the WordPress Plugin Directory is immensely important to me. That kind of power imbalance is dangerous. And it is much more of a danger to the spirit of open source software than anything WP Engine is doing. I worry that WordPress as we’ve known it is dead.
1 I do not have any problem whatsoever with the existence of the Hello Dolly plugin. My problems are that a) the functionality it adds is superfluous and undermines the appearance of WordPress as a professional tool, and b) it is a bad example of how to write a plugin, which is the nominal reason for its inclusion in the base WordPress installation in the first place. It is not structured the way modern plugins are supposed to be written, and it doesn’t include any of the types of functionality a new plugin developer would need to see in action to gain any meaningful insight into how WordPress works.
2 The significant difference, of course, being that I don’t have access to any secret plans revealing the Death Star’s weakness.
As I’ve mentioned previously, I have a problem with my iCloud Photo Library. A few problems, in fact:
I only add photos/videos to the library from my iPhone. I might occasionally take photos with my iPad, but I almost never need to add those to my library.
The way Apple “manages” storage for the iCloud Photo Library is woefully inadequate. As I noted in the post linked above, there are only three options: put everything on your device, let your device decide on some arbitrary amount of free space to keep, or don’t have the photos on your device at all.
The way the options work is not adequate for me with an unwieldy library of over 50,000 photos, and neither the storage space nor the need to have my whole photo library on my iPad and Mac.
I pretty much have no interest in the new Apple Intelligence features that are rolling out as we speak. But today I did learn there’s one intriguing new ability. (At least, I think it’s new.) The Photos app can now identify duplicates in your library, and purge them, retaining only the highest-quality version and merging all of the meta data.
I immediately took advantage of that feature, and removed about a thousand duplicate images.
But I still was confronting a very convoluted situation with my new iPad, which has only a meager 64 GB of storage. (I was seduced by a “Cyber Week” promotion to upgrade from my old 8th Gen to a 10th Gen that was on sale for $259, but I overlooked the fact that in so doing, I was going from 128 GB to 64 GB.) The whole damn library got loaded onto the new iPad before I could stop it, and now I’m dealing with trying to purge it.
There should be a simple and fast way to just delete the entire thing from a device, but there isn’t. Apparently turning off iCloud Photos on the device deletes everything, but… does it? It’s not instant, and there’s no progress indicator. The photos do seem to be very slowly disappearing from the device, but the lack of clarity is maddening.
Meanwhile, I also (finally) discovered something that I think should obviate all of this nonsense. You can very easily access your entire iCloud Photo Library from iCloud on the web!
Yes, just go to icloud.com/photos and log in to your account, and you have a fairly decent set of tools for interacting with your entire iCloud Photo Library without having to store any of it on-device.
One look at the crap I keep in my library should make it clear why I don’t need this filling up all of my devices’ storage.
Why isn’t this one of the default options? In fact, it seems like it would be a no-brainer for Apple to make the Photos app present an option to interact with the library in the cloud only. I know there are bandwidth and connectivity implications, so it would probably involve a reduced set of features.
I suppose, in a way, that’s what the option to optimize storage does — or at least what it’s intended to do — but I am still astonished that it works in such a way that even the reduced/optimized images can fill up your device storage. Why doesn’t it just keep the tiny thumbnails plus the meta data (and no videos!) on-device, and only retrieve larger versions when you interact with an individual image directly?
Again… maybe it actually is doing that, and it’s just that my library is so ludicrously large that it still causes a problem.
But I know I’m not the only person with a huge library (probably others are even much larger than mine), who only ever wants to add items to the library from their iPhone, not their iPad or Mac. It seems that in those extreme cases, they could provide a “web-only” option.
Or, at least… let people know you can shit-can your whole Photos library on the iPad and just access it through the web if you really need to get to your photos.
Sure, you lose cool things like the “memories” widgets on the iPad OS home screen if you don’t have the library on-device, but it’s a trade-off that is not only acceptable, but necessary in a situation like mine.
Sometimes, in their effort to make tools easier to understand by limiting how much they explain what’s going on behind the scenes, Apple actually makes their tools harder to use.
I’ve been using Advanced Custom Fields Pro since it was a solo project run by Elliot Condon. When you contacted ACF for support, you dealt with Elliot directly. I still think of it that way, even though several years ago, Elliot (after growing the business apparently beyond the scale he was interested in managing) sold ACF to WordPress plugin company Delicious Brains, which itself was later acquired by WP Engine.
Make no mistake: for me and countless other developers, ACF is the reason we can use WordPress as a general purpose Content Management System (CMS). It’s the reason I stopped building my own custom CakePHP-based CMS!
WordPress started as blogging software, and based on all available evidence, the core team, or really its BDFL, Matt Mullenweg, still sees it that way. I suspect it burns Matt up inside that a large contingent of us developers who have made WordPress the most popular CMS in the world only use WordPress because ACF makes it possible, and that we’re using WordPress specifically in ways he never envisioned it being used.
I doubt Matt’s ongoing war against WP Engine is that much about ACF. But it’s unmistakable that with WordPress.org’s (read: Matt’s) recent hostile takeover (don’t call it a fork, because this isn’t how forks work) of the free version of Advanced Custom Fields, renamed to “Secure Custom Fields,” and their even more recent actual fork of the paid Advanced Custom Fields Pro, also confusingly renamed to “Secure Custom Fields” and released for free in the Plugin Directory, WP.org/Matt sees ACF as, at least, a useful pawn in that war.
The thing that really confused me though was how could they get away with it? Advanced Custom Fields Pro is a paid plugin, distributed directly on its own website, to paying customers only.
In order to appear in the WordPress Plugin Directory, plugins are required to carry an open source license, with GPL v2 being the preferred choice. The free version of ACF in the Plugin Directory is, of course, GPL. But the Pro version…?
Strangely, after the news broke about this, I started seeing counterarguments that WP.org absolutely had the right to do it, because there wasn’t any other copyright in the ACF Pro code.
What?
So I checked for myself. Standard practice in WordPress plugins is for the license terms to be included in either the readme.txt file, the plugin’s main PHP file, or both. Here’s the top of the readme.txt file in the latest version of ACF Pro (6.3.11):
Well, there it is. ACF Pro is GPL v2. But just to make sure we didn’t miss anything, here’s what’s in the main PHP file:
I did a multi-file search in the plugin code for any instance of the word “copyright” and came up empty.
Well, that’s not good.
In case you’re not familiar with the GPL/open source, uhhh… yeah. This says in effect that WP.org absolutely has the legal right to fork and freely distribute not just the free version of Advanced Custom Fields, but the paid Pro version as well.
But just because it’s legal, doesn’t mean it’s ethical. And reading pages of the ACF site such as their terms for embedding ACF Pro in other plugins and themes, it is clear that their intentions, while generous, are more restrictive than the GPL.
I’m not really sure how, in all of these years, it never occurred to Elliot, or Delicious Brains, or WP Engine, that they needed to change the license terms for Advanced Custom Fields Pro. There’s nothing to stop them from doing that. Earlier versions of the plugin released under GPL will always be GPL. But newer versions could have switched to a more restrictive copyright, which would have (legally) prevented WP.org from forking ACF Pro.
As it happens, I now find myself somewhat in the position Elliot Condon was in back when I first started using Advanced Custom Fields Pro over a decade ago: a solo developer of a plugin that has both a free version in the Plugin Directory, and a paid Pro version.
My plugin is far more niche than ACF, so I doubt it will ever be valuable enough for a company like Delicious Brains to snap up, or that any company that would snap it up would itself become valuable enough to be acquired by a hosting behemoth like WP Engine.
I’m less valuable than a pawn. But that doesn’t mean my work isn’t of value to me. And that’s why, although the free version of ICS Calendar in the Plugin Directory — by necessity — carries a GPL license, the Pro version emphatically does not. (The latest version’s terms were reworded in the wake of this situation to be even more emphatic.)
Update: After posting this, I read the terms of the GPL more closely, and I think the issue may be that, because ACF Pro is coded in such a way that the free version’s code is deeply integrated with the Pro code, they may legally have no choice but to make ACF Pro GPL as well.
I believe it is within the terms of the GPL, and is fairly common practice among paid plugins (including mine), to put any GPL code libraries into a vendors (or similar) folder, and keep the proprietary code separate. (That’s how ICS Calendar Pro works.)
Since the GPL was written with full operating systems in mind, interpreting its wording in the context of something like a WordPress plugin, which doesn’t exist in compiled form and can’t function outside of a much larger system, can get a little fuzzy. What can or can’t be included in that vendors folder?
This leads to a broader consideration: Do I believe in the principles of open source? Or am I just using open source software opportunistically? Can I both support and contribute to open source and make money off of my software, even if it relies (partially) on other people’s open source projects to function?
I think it is naive to suggest anyone who is actually making a living working with open source software is not in that compromised position. Automattic (Matt’s company) relies on open source software just as much as WP Engine, and does far more to blur the lines between the free and commercial sides of the WordPress ecosystem than WP Engine does. (WordPress.com, anyone?)
There is no money in pure open source. That’s kind of the point. But even the most ardent anti-capitalist still needs money to survive in any modern society. And that money has to come from somewhere, whether that’s working for a for-profit company that benevolently “gives back” to the open source community by committing employee time to working on open source projects, or from indie developers releasing the basic versions of their software for free and selling paid “premium” add-ons to provide a source of income.
Last week I had several clients report to me that their websites were suddenly displaying images at the wrong size — too small. I checked their sites (in Safari, my default browser), and everything looked fine.
Then I realized, it was a bug in the new version of Chrome. (At least, it seems like a bug to me, when CSS code I’ve been using consistently for over a decade suddenly doesn’t render properly in just one browser, right after that browser has been updated.)
I discovered that by just removing the width: auto; line, the images rendered at the intended size, and this didn’t seem to break anything in other browsers either. Sweet!
Unfortunately today I had a client contact me with what I initially thought was the same issue. But then they said it was affecting Firefox and Edge as well. (Windows user!) Sure enough it’s also a problem in Safari.
But this time, it’s not that the images are rendering too small; it’s that they’re getting stretched and distorted. Then I realized I had already applied my fix for that client’s site, and it was causing this new issue.
Fortunately there’s another simple CSS fix. (I briefly considered the aspect-ratio property, but that’s not flexible enough for what I’m trying to do.) It’s a newer CSS property that I haven’t used much: object-fit.
It’s really quite simple though. Here’s the new code I’m using that seems to resolve the issue completely. But I suppose I’ll get another email from someone next week describing another edge case where it doesn’t work. Stay tuned…
Update (11/21/2024): OK, so maybe as with the PNG-to-HEIC-to-JPEG glitch, this was actually more of a WordPress 6.7 issue. By the way, I reported the PNG glitch and it got patched in 6.7.1, as did this issue… assuming it’s the same issue I’m describing here, which kind of sounds like it. In retrospect it does seem kind of odd that Chrome and WordPress would both introduce image-related issues on the same day. Much more likely that WordPress introduced multiple issues — or, well, maybe just revealed browser issues, but still. Gotta blame someone.
tl;dr update: I submitted a bug report about this issue to the WordPress Trac, it was fixed in 6.7.1, and I was even credited as a contributor to that version. Now on with the post…
Look at this image:
Now look at this one:
What if I told you those were the same image? Well… I mean… they’re not. Obviously. But they’re supposed to be. They were both the same image when they were on my computer. The same exact file. But I uploaded them to this page in two slightly different ways, and that made all the difference.
The one on top — the screwed-up one — I placed by inserting an Image block in the WordPress Block Editor, and then clicking the Upload button in that block, navigating my hard drive, and locating the image. The one on the bottom, I placed by again inserting an Image block, but this time I just dragged the image from a Finder window into the Safari window. WordPress supports drag-and-drop uploads.
Looking “under the hood,” I discovered that the file on top was somehow getting converted to Apple’s “High Efficiency Image Format,” HEIC (the reason for the C instead of an F is something I’ll leave to the Apple podcasters). WordPress just added HEIC support in version 6.7, which was released this week. Since browsers (other than Safari, I assume) can’t display HEIC images, WordPress automatically converts uploaded HEIC files to JPEG. And that’s why these two images look different. JPEG doesn’t support transparency, so the areas that were transparent in the original PNG got flooded with the nearest available colors1.
But, why should the results of these two upload processes be any different?
Well, after starting in the WordPress Support Forums and then moving over to the Make WordPress Core Trac and finally searching until I stumbled upon a year-old, barely active thread on the Apple Developer Forums, I discovered that Safari has a bug — I mean it has to be a bug, right? — where, if a file upload input field says it accepts HEIC format, Safari automatically converts the uploaded file to that format, apparently with no option not to do that. (I looked around all of the settings, even the developer ones, and didn’t see anything about this “feature” at all.)
And sure enough, WordPress 6.7 is a bit haphazard with its “support” of HEIC uploads, which made it easier to confirm the cause. There are two ways, generally speaking, that WordPress handles file uploads: the browser upload, via an <input type="file"> HTML field, and a JavaScript/AJAX/React/whatever drag-and-drop option.
The <input type="file"> field in the Image block of the Block Editor has added HEIC support via the accept="image/heic" attribute. But the input field in the old school Media Library upload page has not been similarly updated. (It’s become a fact of life in the WordPress world that most of the core team’s attention is on Block Editor stuff these days, and older features get ignored.) Uploading images in the Media Library does not do the conversion. Likewise, whatever exactly is going on with the drag-and-drop method also does not involve the accept="image/heic" attribute that causes Safari to do its mischief.
Unfortunately, it looks like the only “solution” at this point would be for WordPress to do a browser sniff and remove the accept="image/heic" attribute if the browser is Safari. The only reason that was explicitly added was to get Chrome to support HEIC uploads; as I understand it, Safari would support them regardless, but explicitly declaring HEIC support is apparently what triggers Safari to make the conversion.
So, practically speaking, Safari users who want to upload PNGs to their WordPress sites just need to be sure to only upload via drag-and-drop, or the Media Library.
(I haven’t tested, but I suspect JPEG uploads are likewise getting converted to HEIC and then back to JPEG, which probably results in a reduction of image quality.)
Side note on how I discovered this in the first place: Two days ago I was writing another blog post somewhat critical of Apple, and I found when I was trying to upload a screenshot of a window from my Mac — Mac screenshots are saved as transparent PNGs — the transparency was turning black. I was so driven to distraction over the situation that I barely managed to finish writing the post.
1 Saying those areas are flooded with color is an oversimplification. It looks like the color of each pixel is being determined consistently with how PNG compression works.
