Updated September 2026: WordPress 5.0 is no longer an upcoming release. It shipped in December 2018, and the block editor—originally developed under the Gutenberg project name—is now the standard WordPress editing experience.
Quick answer: use the block editor for new content when the active theme supports the required layout. Do not bulk-convert legacy pages. Test one representative page on staging, document reusable patterns and keep a rollback path.
What Gutenberg means today
“Gutenberg” is still used for the wider WordPress editing project and the feature plugin where new editor work is tested. For everyday publishing, most site owners simply use the WordPress block editor.
A heading, paragraph, image, gallery, button or group is a separate block with its own controls. Depending on the active theme, editors may also have patterns, synced content, columns, navigation tools and site-editing controls. A classic theme, block theme and third-party page builder do not expose the same capabilities.
The main parts of the block editor
- Block inserter: adds text, media, design and widget blocks.
- List View: shows the document hierarchy and helps select deeply nested blocks.
- Settings sidebar: contains options for the current post and selected block.
- Patterns: reusable layouts made from multiple blocks.
- Document outline: helps identify heading-order and structural problems.
- Code editor: exposes block markup for advanced troubleshooting.
Synced patterns versus regular patterns
An unsynced pattern is a reusable starting layout. Once inserted, its blocks can be edited independently on that page. A synced pattern is shared content: changing it updates every location where that synced pattern remains connected.
Use a synced pattern for centrally managed information such as contact details or a standard call to action. Use an unsynced pattern when the layout should be consistent but the words and images need to differ. WordPress’s official synced patterns documentation also explains how to detach a pattern for local editing.
Should an existing site convert all old content?
Usually not. Existing posts can remain in a Classic block or continue to render through the system that created them. Converting hundreds of pages in one operation creates unnecessary risk, particularly when content contains shortcodes, custom HTML or builder components.
- Create a current backup of files and the database.
- Clone the site to a staging environment.
- Choose one representative page with headings, images, embeds and buttons.
- Convert or rebuild that page and compare it with production at several widths.
- Test links, forms, analytics, structured data and custom styles.
- Document the approved blocks and patterns before migrating more pages.
- Keep the original page or a revision available for rollback.
Block editor versus a page builder
The block editor can handle many layouts that once required a separate builder. That does not mean every builder-based site should be converted immediately. A builder may power templates, dynamic content or components that blocks cannot replace without development work.
| Question | Why it matters |
|---|---|
| Does the active theme support the required layout? | Block controls and front-end styles vary by theme. |
| How much builder-specific content exists? | Shortcodes and proprietary elements increase migration work. |
| Can editors follow one documented system? | Mixing tools creates inconsistent pages and support overhead. |
| How will rollback work? | A converted page may fail visually or functionally after launch. |
Avoid using two complete page-building systems on the same page. Their markup, CSS, JavaScript and editing models can conflict and make future maintenance harder.
How to adopt blocks safely
Create patterns for repeated sections
Create approved patterns for calls to action, testimonials and common content sections. This reduces inconsistent one-off styling and gives editors a reliable starting point.
Keep heading structure semantic
Choose headings for document structure, not their default visual size. A page should normally have one primary H1 supplied by the template, followed by meaningful H2 and H3 sections.
Avoid unnecessary block libraries
Install a block library only when it provides components the site will use. Multiple libraries can ship overlapping CSS and JavaScript, duplicate controls and increase future migration work.
Test the published page
A layout that looks correct in the editor can wrap differently on the public site. Review real pages at mobile, tablet and desktop widths, especially columns, wide images, tables and navigation blocks.
When the Classic Editor still makes sense
The Classic Editor can be a temporary compatibility layer for a legacy workflow or integration. It should not replace a migration plan. If a critical integration only works with the classic screen, confirm that it is maintained and document the dependency before a future WordPress or PHP update turns it into an emergency.
Govern block-editor changes across a content team
For a business site, reusable patterns need owners and publishing rules. Decide who may edit locked layouts, global styles and synced patterns; otherwise a small content change can affect many pages. Give editors a preview and approval workflow, then use the WordPress pre-publication checklist for links, metadata and the rendered page.
When the block system supports lead-generation or client sites, include template changes in the same maintenance and recovery process as plugin updates. A defined WordPress support service gives broken layouts and editor conflicts an escalation path.
Troubleshooting a broken block editor
If the editor is blank, cannot save or displays invalid-block warnings, reproduce the issue on staging. Check the browser console, WordPress Site Health and recent plugin or theme changes. Disable suspected components one at a time rather than deleting them, and keep a rollback point.
An invalid-block warning does not always mean the visible content is lost. It often means the saved markup no longer matches what the registered block expects. Review the block’s recovery options and source before replacing it.
The official WordPress block editor documentation covers the current workspace and controls.
Frequently asked questions
Is Gutenberg the same as the WordPress block editor?
Gutenberg is the broader editing project and feature plugin. The editor included in WordPress core is normally called the block editor.
Should I convert every Classic block?
No. Convert content only when there is a clear editing or design benefit, and test representative pages first. Legacy shortcodes and custom HTML may not convert cleanly.
What is the difference between a synced and unsynced pattern?
A synced pattern keeps its content connected across placements, so one edit can update all connected instances. An unsynced pattern provides a reusable layout whose inserted blocks can be edited independently.
Can I use the block editor with a classic WordPress theme?
Yes. A classic theme can support the post and page block editor, although Site Editor features and template controls depend on block-theme support.
Need help modernizing legacy content?
CodaStudio can audit the active theme, builder and shortcodes, then migrate representative pages without using production as a test environment. See our WordPress support service for ongoing fixes and carefully scoped changes.
Written by
Ivan Puzic
Ivan is a CodaStudio lead wordpress developer. He also manages a web design company at Elivan Studio. He likes to sneak in a few games of World of Tanks, and is a huge Harry Potter movie fan.
