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.