UNDERDOG of PERFECTION

For various reasons, I’ve kind of taken a step back from heavy client project development in WordPress over the past few months.

Today I’m back at it, trying to really actively work on something new for the first time since before the big kerfuffle started, and the time away has given me new perspective on what WordPress really is, and what the core team (let’s be honest, Matt) wants it to be.

I’ve frequently argued that WordPress owes its broad success to the malleability its plugin architecture provides. The platform is not, inherently, a general-purpose Content Management System (CMS), but thanks to plugins like Advanced Custom Fields, it can be turned into one.

The funny thing is, the platform clearly was moving in the general CMS direction for much of its early life. The availability of custom fields (not ACF specifically, but the more rudimentary open-ended key/value pair system created by the wp_postmeta table), not to mention custom post types and taxonomies, and the extensible template system, really pointed things in the direction of a system much broader than simply “blogging.”

But Matt really just wants WordPress to be about blogging. Because that’s how he uses it. And he only sees what he wants to see.

All of that natural growth in the direction of general-purpose CMS use was effectively pruned by the shift to all things Gutenberg: the Block Editor, and now the Site Editor (formerly Full Site Editing).

I won’t deny that — now that they’re reasonably mature — the elements of Gutenberg are powerful and (somewhat) intuitive tools for building an engaging blog without having to write code.

But for many of us who helped get WordPress to where it is, that’s not what we want, or need. These tools are not only irrelevant to our work, they make the work we need to do much more difficult.

Specifically I’m talking about template design. In their pure intended form, Block Themes can’t have any PHP code in page templates. Which severely limits their functionality. Even if you end up creating a theme — like I have — that’s somewhat of a hybrid of the old and new ways, you’ll find it absolutely maddening how your PHP code may no longer have access to such obvious and basic variables as the post ID.

Meanwhile, core functionality for things like custom fields has been all but killed. It seems like, at the very least, there should be a way in the Block Editor to reference a custom field value. Nope.

Even Advanced Custom Fields’ efforts to extend Block Editor support require a bunch of convoluted hoops. Assuming that creating your own ACF Blocks is overkill, in some cases you can reference ACF values using the [acf] shortcode, but that only works for certain types of fields and, as I’m learning right now, it only seems to work in the Block Editor itself, not in templates.

I’m not saying Advanced Custom Fields is the entire reason for Matt’s extreme actions against ACF owner WP Engine, or for his subsequent deranged steps, seemingly intent on tearing apart the WordPress community itself. But it’s hard to deny that Matt hates ACF for what it represents: a WordPress he can’t control, and one that doesn’t look like what he thinks it should be.

Unfortunately, that’s the only kind of WordPress I care about.

Well… that’s enough for now. Time to go and unravel my theme so I can make this new site I’m building actually do what my clients need it to do. Why did I choose WordPress again? I seem to be asking myself that question more and more frequently.

Update: The morning after I wrote this, I stumbled upon this forgotten bit of code in my theme:

function r3423_acf_disable_shortcode() {
    acf_update_setting('enable_shortcode', false);
}
add_action('acf/init', 'r3423_acf_disable_shortcode');

So, uh… yeah, that part was my fault. But I was just following ACF’s instructions since I generally don’t ever use the shortcode.

Don’t get me wrong, I greatly appreciate the fact that the Mac has built-in translation features (which predate the marketing appellation “Apple Intelligence”). I just don’t get why it lacks so much context.

ICS Calendar Pro is a big (and growing, slowly) part of my business. And a big (and growing, faster than the business as a whole) chunk of it is in Europe. I’m a lame American, who really only speaks English. Sure, I studied French for three years in high school, and Russian (!) for two years in college. And I have enough of a general understanding of most common European languages that I can at least identify on sight what language something is written in, even if I have some trouble actually reading it — and I most definitely can’t respond in that language. (Well, I almost can in French, sometimes. But it definitely wouldn’t sound professional.)

Enter the Mac’s built-in system-wide translation feature. Just highlight a block of text, right-click on it, and the contextual menu offers translation as an option. It can’t translate to every known living language, of course, but I am mainly dealing with four languages other than English, in this order: German, Dutch, French and Italian.

I just don’t understand why the Mac is so stupid about what kinds of translations I want to do.

My Mac system language is set to U.S. English. So the Mac is usually pretty good, when I’ve selected a block of text that is not in English, at recognizing such, and choosing the correct “from” language in the dropdown.

The “to” language… not so much. It generally just remembers the last language I translated something into, and uses that. But shouldn’t it be smart enough to figure out that if the “from” language is not my system default, the language I want to translate it into is probably the system default?

When the “from” language is English, I get that it is harder for it to know what I want to translate into. There’s context that the system-wide translation tool is probably isolated from.

Ideally, the translation tools would have the context available, such as “this text is inside an email being sent to an address with the .de TLD.” In that context, it should be obvious that if I’m bothering to translate some text out of English, the most likely language I’d want to translate it into would be German.

Yeah, I have a lot of users in countries where it’s not so straightforward — e.g. Belgium and Switzerland — but in general, it seems like there’s a more logical starting point than, “OK, here’s a block of text written in English. Let’s try translating it from German into Spanish.” Sheesh.

I feel at this point in time it really needs to be stated that building plugins that extend the functionality of WordPress is just as important for the ecosystem — possibly more, depending on the nature of the plugin — as contributing to core.

WordPress isn’t as huge as it is because of blogs. It’s huge because plugins make it viable as a general purpose CMS. In fact, there’s one particular plugin that is more responsible for its general-purpose flexibility than any other.

If WordPress were limited to its core functionality, no one would even be talking about it today… because it would have been abandoned at least a decade ago.

That is all.

Here we go again…

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

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

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

² 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:

1. 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.
   
2. 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.
   
3. 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.

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.