EmDash Shows Gutenberg’s Content Storage Limits  🔗 **Source:** [EmDash Shows Gutenberg’s Content Storage Limits](https://kraut.press/2026/emdash-cms-shows-gutenberg-limits/) > [!note]+ Document Notes > tags: #wordpress #gutenberg #cms #content-storage #structured-data > author: Hendrik Luehrsen > source: KrautPress > reference: https://kraut.press/2026/emdash-cms-shows-gutenberg-limits/ > date created: 2024-12-28 10:45 > > # 🏷️ Title: EmDash CMS Shows Why Gutenberg Is Hitting Limits with HTML as a Content Storage Format > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Evaluate Gutenberg's HTML storage model impact on headless WordPress implementations — immediate #wordpress - [H2] Research Portable Text adoption patterns for structured content migration — Q1 2027 #structured-data - [H3] Document parse_blocks() performance overhead in high-volume scenarios — next sprint #wordpress ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [WordPress Data Flow and Data Format](https://developer.wordpress.org/block-editor/explanations/architecture/data-flow/) - [Block Markup Representation](https://developer.wordpress.org/block-editor/explanations/architecture/markup-representation/) - [WordPress VIP Block Data API](https://docs.wpvip.com/technical-references/vip-go/vip-block-data-api/) ## 📝 Summary - Cloudflare's EmDash CMS launch exposes Gutenberg's structural weakness in storing content as HTML rather than structured data - While Gutenberg works with blocks internally, it serializes content to HTML in post_content, requiring reparsing for structured access - EmDash uses Portable Text (JSON-based format) that maintains content structure from creation through consumption - WordPress compensates with tools like parse_blocks(), WP_Block_Processor, and VIP's Block Data API to extract structure after storage - The contrast highlights how content storage architecture affects future-proofing for APIs, headless systems, and AI workflows ## 📖 Main Content Hendrik Luehrsen argues that Cloudflare's EmDash CMS launch matters not as a product comparison, but because it exposes a fundamental architectural flaw in Gutenberg's content storage model. While Gutenberg operates with structured blocks during editing, it ultimately stores content as HTML with block comments in the post_content field rather than maintaining a structured data model. This design choice creates friction when content needs to move beyond WordPress into APIs, headless architectures, or AI-powered workflows. WordPress must use functions like parse_blocks() to extract structure from stored HTML, and WordPress VIP created a separate Block Data API specifically to "avoid HTML parsing" by exposing Gutenberg content as structured JSON. EmDash CMS uses Portable Text, a JSON-based rich text format that separates content from presentation and maintains structure throughout the content lifecycle. Luehrsen contends this represents a fundamentally different philosophy - treating content as data from the start rather than as output that requires post-processing to become machine-readable. The author acknowledges WordPress justified HTML storage for compatibility and avoiding competing storage models, but argues this prioritized short-term system stability over long-term structural integrity. As content increasingly functions as data objects moving through multiple systems, HTML storage becomes a limitation rather than a foundation. ## 🗒️ Notes This article does not contain timestamped video content, so traditional timestamp notes are not applicable. Instead, here are key structured points from the text: #### Key Point — Gutenberg's Storage Architecture Problem - Key idea: Gutenberg stores structured blocks as HTML with comments instead of maintaining structured data - Evidence: "Gutenberg works with structure internally but does not treat that structure as the primary data model when saving content" #### Key Point — EmDash's Architectural Difference - Key idea: EmDash uses Portable Text (JSON) to separate content from presentation from the start - Evidence: "EmDash CMS uses structured content instead of serialized HTML and relies on Portable Text, a JSON-based rich text format" #### Key Point — WordPress's Compensatory Tools - Key idea: WordPress built additional layers to extract structure from HTML storage after the fact - Evidence: "WordPress VIP's Block Data API...is explicitly justified as a way to avoid HTML parsing" #### Key Point — Performance and Memory Overhead - Key idea: Converting HTML back to structured data creates processing costs - Evidence: "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" #### Key Point — Future-Proofing Challenge - Key idea: Modern content workflows require structure-first thinking, not output-first - Evidence: "In a web reality shaped by APIs, headless architectures, and AI-powered workflows, that increasingly feels like a design flaw" #### Key Point — WordPress's Original Justification - Key idea: HTML storage was chosen for compatibility and single source of truth - Evidence: "The argument is about compatibility, a single source of truth, and avoiding competing storage models" #### Key Point — Structural vs Output Thinking - Key idea: Content must be machine-readable from creation, not just after rendering - Evidence: "Structure has to be extracted from HTML afterward instead of being the foundation of the content from the start" #### Key Point — Real-World Impact - Key idea: The limitation appears when content moves between systems, not during editing - Evidence: "Gutenberg's weakness does not show up while writing. It shows up when content is supposed to live beyond the editor" ## 📚 References - [WordPress Block Editor Data Flow Documentation](https://developer.wordpress.org/block-editor/explanations/architecture/data-flow/) - [WordPress Block Markup Representation](https://developer.wordpress.org/block-editor/explanations/architecture/markup-representation/) - [WordPress VIP Block Data API](https://docs.wpvip.com/technical-references/vip-go/vip-block-data-api/) - [WP Munich Original German Article](https://wpmunich.de/) - [WordPress Block Editor FAQ](https://developer.wordpress.org/block-editor/explanations/faq/) ## 🗣️ Paraphrase - Gutenberg's internal block structure gets flattened into HTML during storage, forcing WordPress to rebuild structure through parsing when content needs to be accessed programmatically - EmDash CMS maintains content structure throughout its lifecycle by using JSON-based Portable Text instead of HTML serialization - WordPress has created multiple tools (parse_blocks, WP_Block_Processor, Block Data API) to work around the limitations of HTML storage, indicating architectural friction ## 📰 Newsletter **Rethinking Content Storage: What EmDash CMS Reveals About WordPress Architecture** Cloudflare's new EmDash CMS has sparked important conversations about how WordPress stores content. While Gutenberg works beautifully with structured blocks during editing, it ultimately saves everything as HTML in the database. This creates extra work when that content needs to move through APIs or headless systems. EmDash takes a different approach, using structured JSON (Portable Text) from start to finish. This highlights a key question for WordPress developers: should content be stored as data or as output? For your WordPress projects, consider how content flows beyond the editor. Tools like the Block Data API and parse_blocks() help extract structure, but they're solving a problem that structured storage could prevent. **Key Takeaway**: Content architecture decisions made today determine how well your WordPress site adapts to future integrations and workflows. Resources: [Block Editor Architecture](https://developer.wordpress.org/block-editor/explanations/architecture/), [VIP Block Data API](https://docs.wpvip.com/technical-references/vip-go/vip-block-data-api/), [WordPress Developer Resources](https://developer.wordpress.org/) ## ✅ Action Items #### WordPress - Core: Evaluate structured content storage options for future Gutenberg iterations - Core: Document performance characteristics of parse_blocks() vs direct structured access - Core: Research compatibility pathways for dual storage models (HTML + structured) - Meta: Benchmark Block Data API adoption patterns across VIP implementations - Documentation: Create guidance for developers choosing between HTML parsing and structured access #### Community - Contributors: Share experiences with headless WordPress and content structure challenges - Maintainers: Consider how plugins currently work around Gutenberg storage limitations - Developers: Evaluate EmDash CMS patterns for applicable WordPress improvements ## 🧪 Hypotheses - WordPress sites with heavy API usage experience measurable performance overhead from HTML parsing compared to direct structured content access - Migration to structured storage would reduce memory consumption in block processing by eliminating parse_blocks() overhead - Content management workflows become more efficient when structure is preserved throughout the content lifecycle rather than reconstructed on demand - Developer adoption of headless WordPress correlates with frustration around content structure extraction complexity ### 📊 Methodology - Benchmark parse_blocks() vs WP_Block_Processor vs hypothetical structured access across content volumes - Survey WordPress developers on headless implementation pain points and workaround strategies - Analyze WordPress VIP Block Data API usage patterns to quantify demand for structured content access ### ❓ Questions - How would dual storage (HTML + structured) affect WordPress database size and performance? - What percentage of WordPress use cases actually require the structural access that EmDash optimizes for? - Could WordPress implement Portable Text compatibility without breaking existing themes and plugins? ### 🔮 Future Research - Comparative analysis of structured content formats (Portable Text, DraftJS, Slate) for WordPress compatibility - Investigation of incremental migration paths from HTML to structured storage - Analysis of content portability between WordPress and other modern CMSs ### 💡 Implications - Practice: WordPress developers may need to evaluate content architecture earlier in project planning - Policy: WordPress Core team faces architectural decisions about backward compatibility vs future optimization - Security: Structured content storage could reduce parsing attack vectors compared to HTML processing - Education: Developer training should cover content storage tradeoffs, not just editor usage - Funding: Investment in WordPress infrastructure may need to address storage architecture modernization ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical analysis with complex concepts) #### 👀 Visual learners - Present: Article structure with clear headings and conceptual flow - Improve: Architecture diagrams comparing HTML vs structured storage, data flow visualizations #### 🔊 Aural learners - Present: No audio version currently available - Improve: Podcast discussion of architectural tradeoffs, recorded developer interviews #### 🗣️ Verbal learners - Present: Clear definitions of technical concepts, analogies about content as data vs output - Improve: Glossary of terms, expanded metaphors for storage models #### 🧩 Kinesthetic learners - Present: References to hands-on WordPress development experience - Improve: Code examples showing parse_blocks() vs structured access, interactive demos #### 🧠 Logical learners - Present: Logical progression from problem identification to architectural comparison - Improve: Decision trees for storage architecture choices, performance metrics tables #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion context, industry perspective - Improve: Developer forum links, collaborative analysis opportunities #### 🧘‍♀️ Solitary learners - Present: Deep technical analysis suitable for individual study - Improve: Self-assessment questions about architectural decisions #### 🌿 Naturalistic learners - Present: Evolution of content management paradigms over time - Improve: Ecosystem thinking about how storage decisions affect the broader WordPress environment ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Good heading hierarchy, clear article structure - Improve: More descriptive headings that include context, landmark roles #### Keyboard navigation - Present: Standard web navigation patterns - Improve: Skip links to main sections, keyboard shortcuts for technical content #### Contrast and readability - Present: Standard text contrast appears sufficient - Improve: Verification against WCAG 2.2 standards, consideration of technical complexity #### Text resizing and reflow - Present: Responsive design typical of modern WordPress themes - Improve: Testing at 200% zoom with technical content #### Media and captions - Present: Text-only article, no media accessibility concerns - Improve: Consider audio version with technical term pronunciation guides #### Forms and interactions - Present: Basic comment form - Improve: Enhanced labels and validation for accessibility #### Standards reference - Generally meets WCAG 2.2 AA for text content, could enhance with technical content accessibility features ### 🌍 DEIB Assessment #### Cultural breadth - Present: European WordPress community perspective, references to global web standards - Improve: Include perspectives from diverse WordPress communities, multilingual considerations #### Inclusive language - Present: Technical but accessible language, avoids unnecessary jargon - Improve: Expand abbreviations on first use, provide plain language summaries #### Neurodiversity support - Present: Well-structured content with clear logical flow - Improve: Add section summaries, break up dense technical paragraphs #### Representation - Present: Focuses on technical merit rather than individual perspectives - Improve: Include diverse voices from WordPress development community #### Psychological safety - Present: Respectful critique of technical decisions - Improve: Acknowledge different valid approaches to content architecture ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from EmDash launch to Gutenberg architectural analysis - Inductive strength: Uses specific examples (VIP Block Data API, parse_blocks) to support general claims about storage limitations - Causal reasoning: Clearly connects HTML storage decisions to current performance and integration challenges - Analogical strength: Effective comparison between EmDash's structured approach and WordPress's HTML serialization #### Fallacies - False dilemma: Implies HTML vs structured storage is binary choice, when hybrid approaches might exist - Appeal to novelty: Suggests newer EmDash approach is inherently better without considering WordPress's different constraints and user base #### Tone of voice - Overall tone: Analytical and constructively critical, focuses on technical merits rather than partisan arguments ### 🛡️ DARVO Analysis - Deny: No denial patterns present - acknowledges WordPress's legitimate reasons for HTML storage - Attack: No personal attacks - criticism targets architectural decisions, not individuals - Reverse victim/offender: No reversal patterns - maintains focus on technical analysis - Emotional cues and rhetoric: Uses measured technical language rather than inflammatory rhetoric ## 🎯 Conclusion The EmDash CMS launch serves as a valuable mirror for WordPress, revealing how content storage architecture affects long-term adaptability. While Gutenberg excels as an editing experience, its HTML-first storage model creates friction for modern content workflows that treat content as data rather than output. For WordPress practitioners, this analysis highlights the importance of understanding content architecture early in project planning, especially for headless implementations or API-heavy workflows. The tools WordPress has built to work around storage limitations (parse_blocks, Block Data API) demonstrate both the community's ingenuity and the real costs of architectural decisions. Rather than viewing EmDash as a threat, the WordPress community can use this comparison to inform future architectural decisions while building on WordPress's strengths in compatibility, ecosystem, and developer experience. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Gutenberg serializes structured content as HTML during storage > [!quote] EmDash CMS Shows Why Gutenberg Is Hitting Limits with HTML as a Content Storage Format by [[Hendrik Luehrsen]] via [[KrautPress]]. Published 2026-04-03. Accessed 2024-12-28. > "Gutenberg works with structure internally but does not treat that structure as the primary data model when saving content." Core architectural decision that creates downstream processing costs and limits structured content access. [view highlight](https://kraut.press/2026/emdash-cms-shows-gutenberg-limits/#storage-architecture) #xref #articleseed ID:rw_gutenberg_storage ### [H2] WordPress builds compensatory tools for structure extraction > [!quote] EmDash CMS Shows Why Gutenberg Is Hitting Limits with HTML as a Content Storage Format > "WordPress VIP's Block Data API...is explicitly justified as a way to avoid HTML parsing." Demonstrates real-world need for structured content access that HTML storage doesn't natively provide. [view highlight](https://kraut.press/2026/emdash-cms-shows-gutenberg-limits/#vip-api) #xref ID:rw_wordpress_structure_tools ### [H3] Modern content workflows require structure-first thinking > [!quote] EmDash CMS Shows Why Gutenberg Is Hitting Limits with HTML as a Content Storage Format > "In a web reality shaped <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/EmDash Shows Gutenberg’s Content Storage Limits|EmDash Shows Gutenberg’s Content Storage Limits, kraut.press]] ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01knwxergqvb231pk8d12fc8ds)) - Tags: 👻 ai highlighted - The same applies to [`parse_blocks()`](https://developer.wordpress.org/reference/functions/parse_blocks/) and [`WP_Block_Processor`](https://developer.wordpress.org/reference/classes/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. ([View Highlight](https://read.readwise.io/read/01knwxerha60pr0k6vvc84pa8n)) - Tags: 👻 ai highlighted