WordPress introduced the Block Editor as the default editor in WordPress 5.0 in December 2018. Instead of treating a post as one large field, it treats paragraphs, headings, images, buttons, embeds, and other elements as individual blocks with their own controls.
That change was bigger than a new writing interface. Blocks became a shared system for composing content, building page layouts, and extending WordPress products. A plugin can add a block that feels native to the editor instead of asking users to memorize a shortcode or jump between a settings screen and the page they are building.
Gutenberg, Block Editor, and Site Editor
These names are related, but they do not mean exactly the same thing.
| Term | What it means |
|---|---|
| Gutenberg | The development project behind block-based editing. The Gutenberg plugin also ships features for testing before some of them reach WordPress Core. |
| Block Editor | The editor used to create posts, pages, and other block-enabled content. |
| Site Editor | The interface block themes use to edit templates, template parts, styles, and site-wide design. |
People still call the Block Editor “Gutenberg,” and they will probably keep doing that. The distinction matters when you are reading documentation or deciding where a plugin feature belongs.
What a WordPress block is
A block is a structured unit of content or functionality with a consistent editing interface. WordPress includes blocks for common elements such as paragraphs, images, galleries, tables, buttons, navigation, and Query Loops. Plugins can register their own blocks for product-specific jobs.
Each block can define content attributes, editing controls, styles, variations, and support for WordPress features such as spacing, color, typography, and alignment. Some blocks save their final markup in the post. Others render dynamically when the page loads because their output depends on current data.
Blocks, patterns, templates, and template parts
| Use | Choose | Example |
|---|---|---|
| A reusable content element or product feature | Block | Donation form, pricing table, event list, or testimonial |
| A starting composition made from existing blocks | Pattern | Hero, team section, call to action, or article layout |
| The structure used to render a page type | Template | Single post, archive, 404, or landing page |
| A reusable structural area inside templates | Template part | Header, footer, or sidebar |
A pattern should not become a custom block just because the layout has a name. If core blocks already provide the needed behavior, a pattern is usually the lighter and more flexible answer. Build a custom block when the product adds distinct data, behavior, or editing controls.
What this means for WordPress plugin teams
Shortcodes solved an important problem, but they ask users to remember syntax and imagine the result. A well-designed block can expose the same feature through visible controls and show the result in context while the user edits the page.
That does not mean every plugin needs a block. Use the editor when the user is placing, composing, or previewing something that belongs in content. Keep account connections, global configuration, background jobs, logs, and other operational tools in an appropriate admin screen.
- Start with the user’s job. Decide what they need to place or accomplish in the editor before designing controls.
- Use native block supports. Let WordPress handle common controls instead of creating a second spacing, color, or typography system.
- Keep setup out of the canvas. The block should help users create the result; it should not become a miniature copy of the plugin’s entire settings screen.
- Render current data dynamically when needed. Listings, forms, and account-connected content often should not freeze their final output into the post.
- Provide a useful default state. A newly inserted block should show the next action or a meaningful preview instead of an empty rectangle.
A practical example
A gallery plugin might begin with a shortcode that accepts an ID. A native gallery block can let the user choose the gallery, preview it, adjust the few settings that matter on this page, and still render the gallery through the plugin’s existing frontend system.
The block does not need to replace every global gallery setting. Its job is to make placing and configuring that gallery feel like part of WordPress. That is the real shift the Block Editor created for plugin products: users can work with the feature where they are building the result.