Dear WordPress: Nobody Asked for AI Connectors. We Asked for Caching.

I wrote a post a while back about 20 WordPress plugins you can replace with a few lines of PHP. It did well. People shared it. Developers nodded along. But the more I thought about it, the more it bugged me.

The post was treating the symptom. The disease is WordPress itself.

WordPress 7.0 is approaching. The flagship features? A shiny new Connectors Screen for OpenAI, Gemini, and Claude. An MCP Adapter that exposes your site's abilities to AI assistants. An Abilities API. Smart Content Suggestions. Auto-Alt Text.

Meanwhile, you still need a plugin to cache a page.

WordPress 7.0 Is Coming. And It Has AI Connectors.

Let me be clear about what's happening. WordPress 7.0, originally targeted for April 9, 2026, got delayed to May 20. First time in modern WordPress history that a release in RC phase was held back. The reason? Cache invalidation problems with the new real-time collaboration feature.

The irony is almost poetic. They can't ship collaboration because they can't solve caching internally. But they're shipping AI connectors to let Claude write your blog posts.

The new AI infrastructure includes a Connectors Screen where you plug in API keys for various AI providers. An MCP Adapter that turns your WordPress site into a tool server for AI agents. An Abilities API that defines what actions your site can perform. All of this is genuinely interesting technology. I've written about MCP and I think it's one of the more exciting developments in how we interact with software.

But here's my problem. WordPress has had 20 years to build basic CMS features that every competitor ships out of the box. Instead of fixing the foundation, they're installing a smart doorbell on a house with no roof.

Caching: The Feature WordPress Refuses to Build

It's 2026. WordPress powers over 40% of the web. And it ships with zero caching.

No page caching. No object caching. No cache management. Every WordPress site on the planet installs WP Super Cache, W3 Total Cache, LiteSpeed Cache, or FlyingPress. FlyingPress is excellent, by the way. I reviewed it. But the fact that it needs to exist at all is the problem.

Next.js has ISR (Incremental Static Regeneration) built in. You define a revalidation period and the framework handles it. Astro ships static HTML by default. Ghost is 2-3x faster than a typical WordPress site out of the box because it doesn't carry 20 years of architectural debt.

And here's the kicker. WordPress 7.0 was delayed specifically because of cache invalidation issues in their real-time collaboration feature. They're struggling with caching internally but won't build it as a user-facing feature. The engineering team clearly understands the problem. They just won't solve it for the rest of us.

Every managed WordPress host (Cloudways, Kinsta, WP Engine) has built their own caching layer on top of WordPress because WordPress won't do it. The hosts are doing WordPress's job. And charging you for it.

SEO: Twenty Years and Still No Meta Description Field

This one genuinely baffles me.

WordPress is the world's most popular CMS. It's used by millions of people who care about getting found on Google. And it has no built-in field for a meta title. No meta description. No Open Graph tags. No JSON-LD structured data.

Every single WordPress site installs Yoast SEO or Rank Math. Every. Single. One. These plugins are so universal that most people think they're part of WordPress. They're not. They're third-party code maintained by companies that could disappear tomorrow, change their pricing model, or get acquired and gutted.

Ghost has native SEO fields. You open a post, there's a meta title field, a meta description field, an Open Graph image picker. Done. No plugin. No configuration. No potential conflicts with your theme or other plugins.

Next.js has a Metadata API. You export a metadata object from your page and the framework handles the rest. Open Graph, Twitter cards, JSON-LD, all generated from a simple data structure.

These are not advanced features. They're table stakes. A meta description field is literally a text input and a database column. WordPress has had 20 years to add one. Instead, they built AI connectors.

Custom Fields That Actually Work

WordPress has "custom fields." They're key-value pairs. The same implementation from 2005. You get a text input for a key and a text input for a value. That's it.

Want repeater fields? Install ACF. Want relationship fields? Install ACF. Want flexible content layouts where editors can build structured pages? Install ACF, or Pods, or Meta Box.

The answer to "how do I build structured content in WordPress?" has been "install a third-party plugin" for twenty years. And it still is in 2026.

Statamic ships with a full content modeling system. You define blueprints with fieldsets, repeaters, relationships, conditions, validation. All built in. Craft CMS does the same thing. Even Directus, which is basically a database UI, gives you complete control over your content schema without plugins.

WordPress chose a different path. They built Gutenberg, a block editor that tries to be a page builder instead of fixing the data layer underneath. You can drag blocks around on a page, sure. But the underlying content model is still a single blob of HTML in the post_content column. No structure. No queryable fields. Just a big string.

Export, Import, Migration: The Basics Nobody Talks About

Try moving a WordPress site from one host to another using the built-in tools.

The native WordPress export gives you an XML file. It contains your posts, pages, and some metadata. It doesn't include your media library reliably. It doesn't include plugin settings. It doesn't include theme customizations. It doesn't include widget configurations. On complex sites with custom post types and ACF fields, it often breaks entirely.

So what does everyone do? They install All-in-One WP Migration or Duplicator. Plugins that essentially zip up your entire WordPress installation and database, because the built-in export is that inadequate.

Moving a website from one server to another is not an edge case. It's one of the most common operations in web development. Ghost has a one-click export that gives you a clean JSON file with everything. You import it on another Ghost instance and it works. Strapi and Directus are API-first, so your content is always accessible and portable through standard REST or GraphQL endpoints.

WordPress has been around since 2003. The export tool still produces XML that chokes on complex content.

Security, Image Optimization, and the Plugin Tax

No built-in firewall. No built-in two-factor authentication. No built-in login rate limiting. No built-in WebP or AVIF conversion.

I wrote a whole guide on WordPress security plugins. That guide shouldn't need to exist. Basic security hardening should be part of the platform.

Here's the paradox that drives me crazy. WordPress has a plugin problem, and the solution to every problem is another plugin. Your site is insecure? Install a security plugin. Your images are too large? Install an image optimization plugin. Your site is slow? Install a caching plugin.

But every plugin you install adds code that runs on every page load. Every plugin is maintained by a different developer with different coding standards, different update schedules, and different security practices. Every plugin is a potential vulnerability. Every plugin can conflict with every other plugin.

You're literally installing security plugins to protect yourself from the security risks created by having too many plugins. The snake is eating its own tail.

WordPress 6.5 only just introduced Plugin Dependencies as a feature. In 2024. After two decades of plugins depending on other plugins with no formal system to manage it.

It's Not About Hating AI. It's About Priorities.

I want to be fair. The AI features in WordPress 7.0 aren't bad ideas. MCP integration is forward-thinking. The Connectors Screen is a reasonable approach to managing AI provider keys. Auto-Alt Text for images is genuinely useful for accessibility.

But priorities matter. When you have a limited number of engineering hours and you choose AI connectors over built-in caching, you're making a statement about what you think matters. When you push multilingual support to "tentatively v7.2" while shipping an MCP Adapter, you're telling your international users where they rank.

WordPress powers 40%+ of the web. A huge portion of those sites are small businesses, blogs, and personal projects run by people who aren't developers. These people don't care about AI connectors. They care about their site being fast, secure, and easy to move when their host raises prices. They care about showing up on Google without installing a plugin that adds 200KB of JavaScript.

The WordPress ecosystem has created an entire industry around solving problems that WordPress should solve itself. Hosting companies sell "managed WordPress" because unmanaged WordPress is a minefield. Plugin companies sell caching because WordPress won't cache. SEO plugin companies sell meta description fields because WordPress won't add a text input to the post editor.

This is part of why I stopped using WordPress after 6 years. Not because the technology is bad. Because the priorities are wrong.

I don't need WordPress to compete with Claude. I need it to compete with Ghost.

Want a website that doesn't need 23 plugins to do what a CMS should do out of the box? Let's talk about building something that works without the duct tape.