Note: This article was first published in German at WP Munich.

When Cloudflare introduced EmDash as a new alternative to WordPress in early April 2026, what mattered was not so much the product itself, but what the launch made visible. The comparison exposes an old weakness in Gutenberg: content ultimately gets stored as HTML in post_content, not as a structured data model.
That this is a fundamental problem is not a new observation. The debate around structured data in WordPress has followed Gutenberg from the very beginning, and I have been criticizing this lack of support since 2017. It was already clear early on that content on the web would become more than pure output. It needs to be categorized, sorted, transformed, and moved into new contexts. That is exactly what determines how future-proof a CMS really is today.
So the point is not whether Gutenberg is a good editor. The point is that Gutenberg does not take its internal structure seriously enough when it comes to storage. As long as content is primarily stored as HTML, structure remains something that has to be extracted again when needed. In a web reality shaped by APIs, headless architectures, and AI-powered workflows, that increasingly feels like a design flaw WordPress is still carrying around.

Why EmDash CMS Matters Right Now

Cloudflare is not positioning EmDash CMS as just another new CMS but as an alternative to a specific way of storing and processing content. That is exactly why this launch matters. EmDash CMS uses structured content instead of serialized HTML and relies on Portable Text, a JSON-based rich text format. In doing so, it separates content from presentation at exactly the point where Gutenberg still ties the two too closely together.
A look at Gutenberg’s architecture shows just how fundamental that difference is. In the official WordPress documentation on Data Flow and Data Format, WordPress describes the block tree as existing in memory while editing, while post_contentis what ultimately gets stored. The page on Markup Representation of a Block also shows that this storage happens through HTML with block comments. In other words, Gutenberg works with structure internally but does not treat that structure as the primary data model when saving content.
That is why EmDash CMS matters right now. The launch is not just a product comparison. It creates a contrast that makes Gutenberg’s architectural weakness very easy to see. When a new CMS in 2026 openly treats content as data, the storage question is no longer a technical footnote. It is an architectural question.

The Real Problem Is Not the Editor, but the Storage Format

Gutenberg’s weakness does not show up while writing. It shows up when content is supposed to live beyond the editor. As long as a text is only created in WordPress and then rendered, the storage decision barely stands out. It only becomes relevant when content needs to be processed through interfaces, reworked, or moved into other systems. That is the moment when an internal implementation detail turns into a structural limitation.
The reason is simple: Gutenberg does not store its content structure as the primary data model but as serialized output in post_content. The WordPress documentation on Data Flow and Data Format explicitly describes this separation. What exists as a block structure in the editor is converted into an HTML-based format when saved. The page on Markup Representation of a Block shows how that structure is preserved through comment markers and embedded attributes.
That works, but it comes at a cost. As soon as other systems are supposed to understand not the output but the meaning of a piece of content, that structure first has to be extracted again from the stored HTML. WordPress provides parse_blocks() as the central function for that purpose. The fact that the official reference points to memory overhead, and that WP_Block_Processor was later introduced as a more efficient access layer makes the friction pretty clear.
It becomes even more obvious with WordPress VIP’s Block Data API. It exposes Gutenberg content as structured JSON and is explicitly justified as a way to avoid HTML parsing. That is the key point. If a system first needs an additional API to expose its content in a form that can be used sensibly by headless architectures, GraphQL, or other applications, that mostly shows where the original storage logic runs into its limits.
That also makes it clear why EmDash CMS is such an interesting comparison. The contrast does not just show that another path is possible. Above all, it shows how much additional effort WordPress now has to invest just to get back to the structure it never truly prioritized when saving content.

Why WordPress Framed This Decision the Way It Did, and Why That Still Falls Short

WordPress did not land on HTML in post_content by accident. It justified that decision deliberately. In the official documentation on Data Flow and Data Format, the argument is about compatibility, a single source of truth, and avoiding competing storage models. The Block Editor FAQ makes a similar case and contrasts the HTML-oriented approach with the idea of storing content as JSON in post meta instead.
From our perspective, that rationale still falls short. It thinks too much from the logic of existing WordPress structures and not enough from the question of what content needs to be able to do in the future. Compatibility is a valid point. But it is not a substitute for a clean structural model.
The problem was visible from the start. As soon as content is meant to be more than rendered output, it is not enough to drag structure along implicitly inside HTML. At that point you need a data model that does not merely display content but also makes it machine readable, sortable, and processable. That is exactly the criticism we raised early on in our discussion of structured data in WordPress.
Looking back, the reasoning now feels less like a durable solution and more like a defensive decision in favor of short-term system stability. The price is still visible today. Structure has to be extracted from HTML afterward instead of being the foundation of the content from the start.

EmDash CMS Shows What Another Path Can Look Like

That is why EmDash CMS is more than just a new CMS. What matters is not that Cloudflare is building a publishing system. What matters is that EmDash CMS addresses the storage question at exactly the point Gutenberg has avoided it until now.
The crucial difference is architectural. EmDash CMS uses Portable Text, a JSON based rich text format, and cleanly separates content from later presentation. That is not a minor technical detail. It reflects a fundamentally different attitude. Content does not become structurally readable only after rendering or parsing. It already carries that structure from the beginning.
That is exactly where the real provocation for WordPress lies. EmDash CMS implicitly questions the assumption that HTML is a sensible place to store content permanently. If content now moves through different systems as data objects, then HTML is not the foundation anymore. It is just one possible output form. EmDash CMS treats that reality as its starting point. Gutenberg still treats it more like a problem to solve afterward.
Of course, that does not automatically mean EmDash CMS is already the final answer to everything. The project is still too new for that. But the launch makes one thing very clear: how content is stored is no longer a technical footnote. It determines how well a CMS can connect to the reality of modern content.

What WordPress Is Now Trying to Repair After the Fact

The clearest sign of the real problem is that WordPress VIP provides Gutenberg content as structured JSON through the Block Data API. This API does not simply extend Gutenberg. It compensates for a storage model that never put structure first. WordPress VIP states the benefit plainly: it is meant to avoid HTML parsing.
The same applies to parse_blocks() and WP_Block_Processor. What you see here is not some luxury feature, but the need to turn stored content back into a usable structure efficiently. The fact that WordPress needs dedicated processing logic and extra optimizations for that makes the underlying design flaw more visible, not less.
That is why the current development around WordPress feels less like consistent forward motion and more like symptom management. More and more tools are being built just to regain the structure that was never properly prioritized at storage time. And that is exactly where the difference from EmDash CMS becomes sharp. There, structure does not need to be recovered. It is part of the content from the start.

What Gutenberg Can Learn from EmDash CMS

The most important lesson from EmDash CMS is not that WordPress is suddenly obsolete. The real lesson is that content on the web now has to be thought about differently. As long as content is understood mainly as output, HTML as a storage format can still seem good enough. But once content moves into new contexts through APIs, multiple frontends, personalization, and AI systems, that logic no longer holds. At that point, structure cannot be something you expose afterward. It has to be stored from the beginning.
For Gutenberg, that is the real challenge. Not because the system lacks blocks or because it is internally unstructured. But because that structure still has not been made, the true core of the storage model. That is why WordPress keeps producing more helper layers around Gutenberg, while EmDash CMS answers the same question one level earlier. The core architectural question is no longer just how content gets edited. It is in what form a system fundamentally understands its content over time.
And that points to a bigger consequence beyond WordPress. The web does not just need more modern editors. It needs systems that take content seriously as data again. EmDash CMS makes that point so visible because it does not merely promise a new interface. It represents a different understanding of content. For Gutenberg, that is not a minor nudge. It is a very direct reminder of where its design flaw has been sitting for years.

Source

Compounding this challenge is an ongoing debate about the very nature of themes. Questions like “What is a theme?” and “Do we even need themes anymore?” have sparked confusion within the WordPress ecosystem. This lack of clarity has led to hesitation among developers and users, slowing the adoption of new theme paradigms.

The consequences are clear: While investments in WordPress tooling continue, themes, the core components that users interact with, have seen little external innovation or funding. This stagnation threatens to undermine WordPress’ appeal, especially compared to competitors offering more structured, user-friendly solutions.

Even WordPress.org acknowledges this issue, phrasing the problem as themes being too similar. In a post from Jan 2nd, 2025, they claim “WordPress Themes Need More Weird”, directly suggesting to “Design for specific use cases”.

To address these issues, we must first understand what themes are meant to accomplish and why they are currently fallingshort of user needs.

What Is a Theme?

The definition of a theme varies depending on perspective. Traditionally, a WordPress theme has been understood as the visual presentation layer that controls the look and feel of the content. This technical perspective is widely acceptedamong developers, the Gutenberg team, and professional agencies operating within the WordPress ecosystem.

However, this perspective does not necessarily align with how most users see themes. Casual WordPress users do not think about presentation layers or content structuring; instead, they view themes as a means to solve a problem. For them, a theme is not just about design. It is a ready-made solution that helps them achieve their goal of launching a functional website as quickly and efficiently as possible.

Over the years, WordPress themes have moved toward becoming flexible, design-agnostic tools, focusing on customization and modularity rather than pre-built solutions tailored to specific industries or user needs. While this shift has given developers greater control, and with the introduction of the Site Editor, even designers, it has also diminished the practical utility of themes for everyday users simply looking for an easy way to set up a website.

This growing disconnect between the technical and user-driven definitions of themes has led to an identity crisis within the WordPress ecosystem. Are themes merely frameworks for design, or should they be packaged solutions that address specific user needs? Until this question is answered, themes will continue to struggle with adoption and relevance.

The User Experience: A Realtor’s Journey

To understand the gap between WordPress themes and user expectations, let’s take a practical example: Imagine a realtor based in rural America who needs a website. Numerous platforms promise a simple, do-it-yourself website creation experience. How do these platforms cater to the user’s needs?

Competitor Approaches:

• Squarespace: The homepage prominently features a “Templates” link, leading to an interactive wizard recommending templates based on user needs. Even without the wizard, users can easily navigate to a “Real Estate & Properties” category showcasing templates designed explicitly for realtors.
• Wix: Although not as streamlined as Squarespace, Wix places “Templates” as a secondary item in its main menu. The templates page is utility-driven, offering clear filtering options. A “Real Estate” category under “Business & Services” provides realtors with pre-designed templates tailored to their industry.
• Elementor: The “Elementor Kit Library” is slightly harder to find but still embraces a utility-first approach. While Elementor does not yet have a dedicated “Real Estate” category, it features filters like “Business” and “Agency.” Users can find templates such as “Personal Chef Website Kit” or “Real Estate Agency Website Kit” that directly solve their specific needs.

The WordPress Theme Repository:

Now, let’s compare this experience to the WordPress theme repository. If our realtor searches for a real estate theme, their primary method is keyword-based, yielding inconsistent results. There is no structured filtering system that immediately presents industry-specific themes. Instead, they are met with a mix of classic and block-based themes, many of which are not clearly designed to solve their problem.

The only remotely structured listing in the WordPress theme repository is under “Subject,” but even this categorization is chaotic. For instance, in the “Food and Drinks” category, users will find themes such as “Holiday Quest,” “Newspaper Flash,” and “Travel Quest,” none of which clearly address the needs of a food business. This lack of clarity creates a frustrating experience for users who simply want a theme that aligns with their business.

A look at the most downloaded block themes reveals a similar issue. The “Twenty-X” themes may be familiar to long-time WordPress users, but for newcomers, they do not indicate their purpose. Popular block themes like “Extendable,” “Yith Wonder,” and “Ollie” also fail to communicate their utility to non-technical users. These themes do not offer a clear answer for a realtor simply looking for a quick and effective website solution.

The Path Forward: Fixing WordPress Themes

To address these challenges and restore themes as essential problem-solving tools for users, WordPress must take several crucial steps:

• Reframe the Purpose of Themes: Themes should be more than just aesthetic frameworks. They should be solution-driven, providing users with ready-made options that cater to specific industries and use cases.
• Improve Discoverability: The WordPress theme repository needs a complete overhaul to introduce structured categories and utility-driven filtering. Users should be able to browse themes by industry or business type, just like on competing platforms.
• Enhance Accessibility for Casual Users: The theme selection process should be intuitive, guiding users toward the best choices for their needs. A wizard-style recommendation engine, similar to Squarespace, could be an effective solution.
• Prioritize Ease of Setup: Full Site Editing (FSE) must become more user-friendly, reducing complexity and making it easier for new users to build and manage their websites. If WordPress insists on FSE as the future, it must match the usability of traditional, classic themes.

Conclusion: Making WordPress Themes Relevant Again

If WordPress wants to remain a dominant force in the website-building space, it must rethink the role of themes. The current theme landscape is unfocused, failing to address the practical needs of users looking for simple, industry-specific solutions.

The shift towards Full Site Editing has complicated the onboarding process for new users, making it harder to find and implement themes that solve real-world problems. Meanwhile, competitors have doubled down on ease of use, ensuring their template libraries offer immediate value and clear solutions.

For WordPress to regain its competitive edge, it must make themes relevant again. By emphasizing utility over flexibility, improving discoverability, and prioritizing an intuitive user experience, WordPress can ensure that themes serve as powerful tools rather than confusing obstacles.

Source

Unlike most other contact form plugins, Form Block integrates directly into the Block Editor after installation, eliminating the need for a complicated overlay. There’s no separate settings page to build forms in; instead, all contact forms are created directly within the Block Editor.

In the editor, new forms come with a selection of pre-made templates that can be adopted and customized as needed.

While Form Block keeps things simple, it does include a few settings. Under Settings / Writing in the admin menu, From Block adds two options, but these are only relevant if the contact form is used for file uploads.

A paid version offers additional features, such as the ability to store uploads in WordPress without sending them via email. For example, we use this feature to collect local recordings from interview partners for our podcast. The Pro version also adds custom form actions, extended form validation, and more.

Source

This plugin, developed and maintained by accessibility experts, aims to run several automated checks directly within WordPress. Earlier this year, I interviewed Amber Hinds, co-founder of Equalize Digital, for our English-language podcast. You can listen to the interview in the KrautPress Podcast.

Like most of the other plugins featured in our Advent calendar this year, the Equalize Digital Accessibility Checker can be installed directly from the WordPress.org plugin directory. After activation, it informs users about a more feature-rich paid version and integrates its testing interface directly into the post and page editor.

Below the editor, various tabs in the Accessibility Checker section provide insights into several tests. With great attention to detail, the plugin offers guidance on identifying and solving issues. For example, I discovered a few flaws in our theme here at KrautPress and plan to address them over the Christmas holidays—not because the new accessibility regulations will apply to us, but simply because it’s the right thing to do.

In general, the Equalize Digital Accessibility Checker assesses the site’s compliance with WCAG 2.1 AAA standards but also points out that not all tests can be effectively automated. For a thorough evaluation, you should reach out to an expert.

The paid version can get quite pricey, but it offers significantly extended functionality, that will be worth the premium if you create sites for clients.

Source

Progress Planner is the latest project from former Yoast CEOs Marieke van de Rakt and Joost de Valk. Their goal is to make working on content more engaging and to keep bloggers motivated with some good old gamification.

The plugin achieves this with a system of recommendations, monthly statistics, and badges.

Progress Planner is still in its early stages and will undoubtedly gain additional features in the coming months. Even now, though, it provides extra motivation to write and work on one’s blog. Let’s see if it helps the KrautPress blog.

Source

The WebAuthn Provider for Two Factor plugin creates its own settings page but adds the most critical parts of its configuration directly to the Two Factor plugin’s settings under Users / Profile.

Initially, setting up the plugin was a bit complicated, but it has since received several updates. The process involves creating a security key for each user, enabling them to authenticate with this key as a second factor in addition to their username and password. Most modern browsers and operating systems already support Passkeys, and many of them (along with many password managers) even allow Passkeys to be synchronized across multiple devices.

As with the original Two Factor plugin, multiple authentication methods can still be used as a second factor. For example, a one-time code stored in a bank vault (depending on your level of paranoia) can be set up as an emergency fallback.

However, two important limitations must be kept in mind: First, this remains a second-factor method. Unlike Passkeys for many other services, WebAuthn Provider for Two Factor does not replace the username and password. Second, Passkeys have lost momentum in recent months after their initial hype subsided. Nonetheless, support in modern software remains strong enough to make testing worthwhile.

Source

The target audience for this plugin, which is free directly from WordPress.org, is professional photographers who need approval from their clients for photos from commissioned projects.

After installation, the plugin allows you to create “collections” containing various photos. These collections can be sent to clients for selection and approval via email or direct link.

The link opens in a completely standalone interface, independent of the active theme. This view is fully powered by Picu.

While the free version of Picu offers a fantastic preview of the Pro version—which includes advanced features, branding options, and workflows—it’s also excellent and fully functional on its own.

Source

Under the Cookies section in the admin menu, the plugin provides a variety of options. To keep everything organized, the team at devowl.io has included a handy checklist, which guides newcomers step by step through the setup process.

During this setup, not only can basic details be configured, but also a range of nuances related to the services used and the text displayed in the cookie banners.

I must admit that I don’t run a single website that requires a cookie banner. However, whenever I’m asked for recommendations, Real Cookie Banner is always my go-to suggestion.

The team behind the plugin offers both free and premium versions. If you’d like to take a closer look before committing, you can set up a test environment on the devowl.io website.

Source

If you run a blog with many posts, perhaps even authored by multiple contributors, it’s easy to lose track. Today’s plugin, Editorial Calendar, is here to help.

The plugin’s interface has a slightly dated look but remains functional. It appears under Posts as Calendar. There, Editorial Calendar provides a compact overview of upcoming posts sorted by date. New drafts can be created directly from this interface.

Entries in the calendar can even be moved and rescheduled using drag-and-drop.

An editorial calendar may not be worthwhile for simple blogs with less busy publishing schedules. However, for more complex operations, it can significantly simplify the workflow for everyone involved.

Source

If you’re working on a website, you might not want others to see it during that early time. However, working on a server and sharing progress with clients can sometimes be useful. The plugin Maintenance Mode for WordPress by Robert DeVore aims to solve this problem. While this isn’t a unique feature, what sets this plugin apart is its lack of ads, annoying upsells, or other inconveniences. Instead, it focuses on the essential functionality of creating Coming Soon pages – exactly as it should.

After a manual installation via GitHub, the plugin adds an additional Maintenance entry to the admin menu. Within this Custom Post Type, you can create custom Coming Soon pages using the block editor.

Once created, entries can be selected and activated under Maintenance / Settings. Additionally, the plugin requires a launch date, after which the Coming Soon page will be deactivated.

There’s not much else to do or see. These are all the features of the plugin.

The plugin is currently only available on GitHub.

Source