Joshua Bryant of Dow Jones joined the Jukebox Podcast to explain how his team reimagined editorial workflows by decoupling Gutenberg from WP Admin and embedding it in a standalone React application — all while keeping content in a traditional WordPress database.
Context and motivation
Dow Jones runs major publications (Wall Street Journal, Barron’s, MarketWatch, Mansion Global, and others) on a WordPress Multisite. Editors publish into a central WordPress database that multiple front ends consume. For breaking news and market updates, time matters down to seconds: being a few seconds faster can change the reach and impact of a story or push notification. The goal was to shave seconds from editorial actions and reduce distractions for newsroom staff, while preserving the existing WordPress business logic and extensibility.
Three-part architecture
Their platform is split into three distinct applications:
– Planning: a React single-page app where editors schedule, coordinate, and prepare stories (the place reporters often already live).
– Editing: WordPress (NewsPress), the CMS where content, user permissions, and plugins live.
– Rendering: separate front-end systems (mobile, web, etc.) that read from the central database and display published content.
The key change was moving Gutenberg’s block editing surface into the planning tool so editors can publish breaking content quickly without page reloads or the full WP Admin experience.
What they embedded and why
Rather than replace WordPress entirely, the team chose to reuse Gutenberg because of the heavy investment in WordPress business logic, plugins, and workflow integrations (e.g., tickers for MarketWatch, author databases, SEO tools). The approach: embed the Block Editor’s core content area (the middle editing canvas) in the React app, strip out surrounding UI that adds noise (left inserter, right sidebar, WP wrapper), and expose only the essential blocks editors need for rapid publishing.
They intentionally limited available blocks to a minimal set — chiefly paragraph and list — plus a few custom blocks that map to proprietary functionality (e.g., stock tickers, bylines). This minimized distractions and the chance editors would over-format or introduce visual changes that the headless front ends wouldn’t honor.
Publishing via the REST API
When an editor hits publish in the React planning tool, the app calls WordPress REST API endpoints to save, lock, or publish posts. That avoids loading WP Admin pages or triggering full admin workflows in the browser. The content lands in the WordPress database as usual, so subsequent edits, SEO updates, or enhancements can occur in WordPress or keep happening in the planning tool. Published content is then picked up by downstream rendering systems and pushed to readers instantly.
Benefits
– Speed: fewer clicks and no page reloads save seconds during publishing — crucial for breaking news.
– Reduced distraction: a focused editing surface keeps journalists on task in noisy or time-pressured environments (field reporting, boardrooms).
– Reuse: retaining WordPress as the source of truth preserves years of plugin work and editorial rules.
– Flexibility: different front ends (mobile, web, other clients) continue to consume from the central DB, enabling varied render strategies.
Technical challenges and solutions
– Simulating the global WP object: Gutenberg and many plugins assume a global wp object and bundled scripts provided by the WP build process. In a standalone React app that environment doesn’t exist, so the team had to import the necessary WordPress packages and expose them appropriately at runtime so Gutenberg code and plugins would run outside WP Admin. Discovering this build- and namespace-related behavior was a key debugging hurdle; implementing the simulation was straightforward once understood.
– Picking the right pieces: distinguishing between the broader Editor (WP wrapper, publish controls, metadata UI) and the Block Editor (inserter, middle canvas, sidebar) was crucial. The team embedded primarily the block editing canvas and reimplemented save/publish as REST API interactions.
– Documentation gaps: WordPress documents standard use cases well, but doing this out-of-the-box required reading Trac tickets, GitHub issues, and source code. There wasn’t a single tutorial for embedding Gutenberg in an external React app.
Workflows and usage
The lightweight editor in the planning app is primarily for breaking news and market “pulses” — short, time-sensitive updates requiring rapid publication. Less time-sensitive content (features, long-form articles, recipes) continues through the normal WordPress flow. For breaking items, editors can publish immediately; later they or others can enhance the story (add images, SEO metadata, corrections) in WordPress or the planning tool. The team also supports “convert to article” workflows to hand off a breaking item to other editors for fuller treatment.
Mobile and accessibility
The planning tool is accessible on mobile and desktop: reporters in the field can open the app, type a quick update, and publish without friction. Minimizing required clicks and UI complexity reduces barriers to timely reporting.
Adoption and rollout
The system was piloted at MarketWatch and later rolled out to wsj.com and Barron’s. The approach was designed to be extendable across newsroom properties on the Multisite. Because the WordPress backend remains the canonical store, the same model can scale to multiple publications and front ends without duplicating business logic.
Open source and sharing
Joshua has started a public repo demonstrating how they moved Gutenberg into an external app, with proprietary pieces removed. He intends to expand it and welcomes community input. The pattern can help contractors and agencies who want WordPress as a backend (database, user management, revisions) while offering customized React/Vue front-ends or tailored editor experiences for clients.
Final notes
This work demonstrates a hybrid approach: preserve WordPress’s strengths (plugins, editorial rules, central content store) while delivering a focused, headless editing experience that meets newsroom speed demands. It’s a niche but powerful solution for enterprises and teams where seconds and editorial coordination directly affect business outcomes.
For further details and links to Joshua’s talk and repo, see the episode notes at wptavern.com/podcast. Joshua also welcomes conversation and feedback from developers looking to adopt or refine a similar approach.
