$ filed under: wordpress

open source · editorial infra

WordPress Is Expanding its Editorial Platform Case

WordPress 7.0 introduces significant features for media publishers, including an evolving “Guidelines” custom post type for editorial governance and an experimental “Content Types” system. Revisions now cover templates and patterns, enhancing stability for complex layouts. These…

WordPress 7.0 introduces significant features for media publishers, including an evolving “Guidelines” custom post type for editorial governance and an experimental “Content Types” system. Revisions now cover templates and patterns, enhancing stability for complex layouts. These updates mark WordPress’s progression toward a comprehensive editorial platform.

WordPress 7.0 is days away (May 20), and the latest developer roundup landed today. Most of the coverage will focus on what didn’t ship — real-time collaboration got pulled — but there’s a lot here that matters specifically for teams building and running media properties on WordPress. Here’s what to pay attention to, and why.


The Big Ones

Editorial Governance Is Going Native

The most consequential item for publishers is the continued development of the Guidelines custom post type. Renamed from “content guidelines” to simply “guidelines,” this feature now includes a dedicated wp_guideline_type taxonomy, a standalone /content-guidelines REST API route, and import/export workflows.

Why this matters: Large newsrooms have always managed style guides, editorial standards, and content policies outside WordPress — in Google Docs, Confluence, or custom-built plugins. Guidelines as a first-party content type signals WordPress moving from publishing tool to editorial platform. If you’re running content governance workflows through custom tooling today, this is worth tracking closely.

Content Types: The Long-Awaited Rethink

An experimental Content Types system is taking shape — the first serious architectural rethink of how WordPress handles content types since custom post types arrived in WordPress 3.0 back in 2010.

Why this matters: Media organizations typically maintain anywhere from 5 to 15 custom post types — articles, videos, galleries, live blogs, sponsored content, newsletters, and more. Registration and management of these has always been fragile and developer-dependent. A first-party content type system could simplify publisher architectures significantly, especially for teams evaluating headless or decoupled approaches where content modeling is a constant friction point. It’s early, but directionally important.

Revisions Now Cover Templates, Parts, and Patterns

The revisions panel — previously limited to posts and pages — now extends to templates, template parts, and patterns. You can track changes and roll back to earlier versions across all of these.

Why this matters: Publishers managing complex homepages, section fronts, and multi-layout sites tweak templates constantly. Until now, there was no safety net for those changes. This reduces the “who broke the homepage?” problem that every large editorial team knows too well.


The Practical Wins

REST API date fields on templates and parts — You can now sort and filter templates by creation or modification date. A small addition, but useful for teams managing large template libraries programmatically across multi-brand or multi-vertical setups.

HEIC-to-JPEG file extension fix — HEIC images converted client-side now correctly get a .jpg extension. Sounds trivial, but photo desks and mobile journalists shooting on iPhones produce HEIC constantly. Broken extensions cause downstream issues in CDNs, image pipelines, and DAM systems.

Image block alignment preservation — Wide and full-width images no longer lose their aspect ratio and scale values when alignment changes. Publishers rely on hero images heavily; this eliminates a common source of layout surprises in the editor.

Custom CSS capability gating — Per-block custom CSS now properly respects the edit_css capability. For publishers with tiered editorial roles, this prevents contributors and editors from injecting CSS that could break production layouts.


What Didn’t Ship

Real-time collaboration was pulled from 7.0. The decision came down to surface area concerns, race conditions, server load, and bugs found during fuzz testing. For newsrooms hoping for Google Docs-style co-editing in WordPress, it’s a disappointment — but the right call given the stability bar a feature like this needs to clear. It remains a stated priority for a future release.


Worth Watching

  • Tabs and Accordion blocks continue maturing — increasingly useful for structured explainer content, FAQ sections, and product comparisons that media sites produce at scale.
  • @wordpress/grid package — A new standardized package for grid-based interfaces in the editor. Early, but relevant for teams building custom editorial dashboards and editor extensions.
  • Playwright E2E testing tutorial — The developer blog published a guide on writing end-to-end tests with Playwright. Relevant for publisher dev teams investing in CI/CD for their WordPress customizations.

The Takeaway

The headline feature (RTC) didn’t make the cut, but the underlying platform work in this release cycle is arguably more consequential for media publishers. Guidelines and Content Types represent WordPress evolving toward the kind of structured editorial infrastructure that large publishing operations have been building on their own for years. That’s the story worth following.