Block, pattern, theme or plugin? Put the WordPress change in the right place
Many WordPress problems start when a good solution is put in the wrong place. Here is a practical model for choosing between content, a pattern, a block, the theme and a plugin.
Category: WordPress
A new calculator is to be added to the website. The marketing department wants a campaign box that can be reused. The contact information needs to be updated in several places. An editor wants to be able to change the background colour of one specific section.
All these needs can be solved in WordPress, but they should not be solved in the same way. The choice between regular content, a Gutenberg pattern, a custom block, the theme or a plugin affects how easy the website will be to edit, develop further and maintain.
When functionality is put in the wrong place, hidden dependencies often arise. Content becomes locked to the design, editors are given too many choices, and a later theme change becomes unnecessarily complicated. The company should therefore establish some clear principles for where different types of changes belong.
Start by separating content, presentation and functionality
Before choosing a technical solution, the need should be placed in one of three main categories:
- Content: Text, images, video, tables and other information managed by the editor.
- Presentation: Typography, colours, spacing, widths and visual rules that determine how the content is displayed.
- Functionality: Calculations, forms, integrations, search, filtering and other program logic.
This distinction may seem simple, but it resolves many discussions. An introduction is content. How introductions look is presentation. A form that sends data to a customer system is functionality.
Problems arise when the categories are mixed. If an editor has to write HTML to achieve the right design, presentation has been placed in the content. If an important integration is located in the theme, functionality has been made dependent on the website’s visual design.
Use standard Gutenberg blocks for regular content
Standard blocks should be the first choice when editors are publishing regular content. Headings, paragraphs, lists, images, quotes, buttons and columns cover many needs without custom development.
The benefit is not just lower cost. Standard blocks are familiar to many editors, work well with WordPress editing and mean less custom code to maintain. It is rarely necessary to build a custom block just to place a heading and a button next to each other.
At the same time, not every available block should be open to everyone. If the website has clear templates and design rules, a limited selection can make publishing easier. Editors need relevant choices, not as many choices as possible.
Choose a pattern when several blocks should be used together
A Gutenberg pattern is suitable when the company repeatedly uses the same combination of blocks. This could be a customer story with an image, quote and key results, or a contact section with a heading, text and call-to-action button.
The pattern gives the editor a good starting point without requiring the content to be built from scratch each time. After insertion, the text and images can normally be edited as regular content.
A pattern is particularly useful when the need concerns structure and composition, rather than advanced functionality. If the section consists only of existing blocks arranged in a specific way, you should consider a pattern before commissioning a custom block.
The company should also clarify whether the pattern should be freely editable or synced. A freely editable version is suitable when each page should have its own content. A synced version is suitable when the same information should be displayed and updated collectively in several places, such as a shared service message.
Build a custom block when content needs fixed parameters
A custom-developed block is the right choice when editors need a clear editing form, fixed fields or controlled presentation. This could be an employee profile, a product benefit, a pricing component or a key figure with an explanation.
The difference from a pattern is the degree of control. In a pattern, the editor works with several independent blocks. In a custom block, the editor fills in defined fields while the solution controls the layout and display.
A good custom block should make the editor’s work easier. If the block contains many tabs, technical settings and free-text fields for design, it is probably too complicated. Editors should focus on the content, not the implementation.
Before building the block, you should answer three questions:
- Will the element be used in several places or by several editors?
- Is it important that the layout always follows the same structure?
- Can the need be met satisfactorily with existing blocks and a pattern?
If the answer to the first two is yes and the answer to the last is no, a custom block is often a sensible choice.
Let the theme control the website’s visual rules
The theme should be responsible for the consistent visual expression: typography, colour palette, spacing, content widths and the presentation of key elements. It should ensure that a button, heading or list behaves consistently across the website.
This does not mean that all styling must be identical. But the variations should be planned. If editors can choose arbitrary colours, font sizes and margins for each block, the website will quickly become inconsistent. Flexibility should be provided through a limited set of variants that have been tested in the design.
The theme should not, however, own business-critical functionality. A product calculator, integration or custom content type should normally be able to survive a change in the company’s design. Otherwise, a future theme change also becomes a functionality project.
Use a plugin for functionality that should live independently of the design
A plugin is usually the right place for functions that process data, connect systems or introduce lasting business logic. This includes forms, search functions, product data, calculators and integrations.
The key question is whether the function should still exist after a theme change. If the answer is yes, it should not be tied to the theme.
This does not mean that the company needs a new plugin for every small change. Related custom functionality can be collected in an orderly way. The goal is clear responsibility, not as many technical components as possible.
Also consider whether the function is already covered by an established solution you use. Duplicated functionality means more maintenance, more settings and a greater risk of conflicts. A new plugin should solve a genuine need that is not handled well enough by the current setup.
Avoid shortcodes as a long-term content strategy
Shortcodes can be useful in some cases, but they often make content harder to understand and edit. The editor sees code instead of a visual representation, and the content may be left with useless fragments of text if the solution is removed.
For new editorial components, a block is usually better. It can provide a preview, clear fields and validation directly in the editing interface. Existing shortcodes do not necessarily need to be rebuilt immediately, but they should be recorded as technical debt and reviewed when the relevant pages are due for changes anyway.
Consider the implications before development begins
A small request can affect more than the page in question. Before a change is developed, the person responsible should conduct a brief impact assessment:
- Who will create and edit the content?
- How many places will the solution be used?
- Should the content be the same or different across pages?
- What should happen if the theme is changed?
- Does the solution contain data that must be transferable or exportable?
- How will mobile display, accessibility and load time be affected?
- Who will test and approve the change?
This review often reveals that the request should be adjusted. A desired custom block may turn out to be a pattern. A visual component may in fact be an integration. A one-off solution may prove to be the beginning of a new content type.
Document the decision, not just the solution
As the website evolves, it is useful to know why a component was created as a block, pattern or plugin. Therefore, add a brief decision record to the project documentation. Describe the need, the chosen placement, who owns the content and any dependencies.
The documentation does not need to be extensive. A couple of precise paragraphs can save a great deal of time when the solution needs to be changed later. It also makes it easier for a new developer or supplier to understand the architecture without having to reinterpret all previous decisions.
Introduce a simple decision rule
The company can use the following sequence whenever a new need arises:
- Can the need be met with a standard block?
- Can several existing blocks be combined into a pattern?
- Does the editor need a custom block with fixed fields and constraints?
- Is this a visual rule that belongs in the theme?
- Is this enduring functionality that should reside in a plugin?
The sequence helps you choose the simplest solution that actually meets the need. The goal is not to avoid custom development, but to use it where it provides clear value.
The right placement makes a website easier to manage
A well-organized WordPress website is not defined by how many blocks or plugins it has, but by each part having a clear and understandable responsibility. Content should be editable without code. The design should be consistent without manual fine-tuning on every page. Functionality should be maintainable without being unnecessarily tied to the appearance.
When the company considers placement before building the solution, both publishing and further development become easier. Editors make fewer wrong choices, developers encounter clearer boundaries, and the website withstands changes better over time.
