Let’s start this post of with a disclaimer – core blocks and block patterns should be used if possible. Keeping that in mind, below is a post summarizing my decision process on whether to leverage core blocks and block patterns or delve down the road of a custom block (built with Advanced Custom Fields).
Core blocks for the win
Core blocks represent the foundation of the block editor offering functionality that handles most content needs without the need custom code. You should prioritize core blocks when possible for a number of reasons:
- They are native WordPress ensuring automatic updates with new features and functionality
- They inherent accessibility compliance (like proper ARIA roles and keyboard navigation)
- There is minimal performance overhead from zero additional JavaScript or CSS keeping things as lean and mean as possible
Sticking to core blocks also future-proofs sites against editor changes (for the most part), as WordPress core maintains backward compatibility far better than third-party solutions.
Core blocks are ideal for straightforward content like paragraphs, headings, images, columns and groups, where end users expect simple editing without a learning curve. Additionally, they load instantly in the editor and on the frontend, avoiding the bloat of rendering custom blocks.
This approach aligns with block editor best practices: leverage a large percentage of use cases covered by core first, reserving custom work for true edge cases, keeping themes lightweight, performant and scalable.
What about block patterns?
Block patterns bundle multiple blocks (core or custom) into reusable, pre-configured layouts, letting developers ship ready-to-use designs directly in the editor’s inserter. Additionally, users can create their own patterns as needed. Registered via PHP or created directly in the block editor UI, they appear as options under the Patterns tab, allowing users to drop in more complex layouts with one click while still permitting light customization of individual blocks inside.
Patterns can be used strategically to prevent the need for repeating work by creating patterns for common layouts that shouldn’t need to be rebuilt from scratch each time. They’re perfect for enforcing structure while still allowing for easy customizations and tweaks, without the overhead of building full custom blocks. Creating robust, well-thought-out pattern libraries can be a huge benefit for your website to ensure consistency and efficiency when creating pages.
Prioritize patterns when working on layouts that recur predictably, bridging core blocks’ simplicity and custom blocks’ power without dev maintenance beyond initial setup.
When do custom blocks come into play?
Custom blocks come into play in a few scenarios when I am building sites:
- The block needs to integrate custom meta data
- The block is a query of some kind
- The block requires unique functionality like filters or tabbed content
- The block has a unique layout that isn’t easily created with core blocks
- The block has unique responsive requirements that aren’t easily created with core blocks
When there is a need for custom meta, I find it much easier to go with a custom blocks. For example, lets say you want a block that outputs a list of team members with a name, headshot, position and social media links. That layout is possible with core blocks, but for the end user it is much easier if they can just enter some information (name, position, headshot, etc…) and the formatting is all handled automatically by the block. This approach accomplishes a few things:
- Ensure consistent formatting as new team members are added
- Allows for flexibility if the team members need to have information pulled from a custom post type
- Creates a much easier UI for the end user when adding/removing team members
Unique layouts and functionality are also primary drivers for using custom blocks. A few good examples of this would be:
- Slideshows or any layouts requiring specific javascript
- Tabbed content or toggles
- Blocks requiring querying data like recent posts (this is possible with the query block, but I prefer custom)
- Unique layouts that aren’t easily achievable with core blocks
So, while you can probably cover 90%+ of layouts with core blocks and block patterns, there is a very important place for custom blocks.
The core v. custom block matrix
Below is quick chart as a reference I use to decide whether I should be using core blocks or creating custom blocks to use during a site build. If I’m unsure of which to use based off of this, I will typically try to build what I need with core blocks first and then revert to a custom block if needed.
| Scenario | Core Blocks | Custom Block |
|---|---|---|
| Simple static content | X | |
| Basic fields like text, heading, buttons, columns, etc… | X | |
| Unique more complex layouts | X | X |
| Layouts including custom metadata | X | |
| Layouts including queries | X | |
| Layouts including the need for custom javascript | X |
In summary, the decision to reach for core blocks, block patterns, or custom ACF blocks boils down to balancing simplicity, consistency, and project-specific needs. Core blocks handle the vast majority of straightforward content with zero overhead and custom blocks unlock structured data, queries, and unique functionality where generic tools fall short. This layered approach keeps sites performant, maintainable, and editor-friendly.
Adopting this framework as your default process streamlines site builds, reduces layout breakage, and creates reusable patterns (literal and figurative) across projects. Next time you’re sketching a new block, start with core—escalate only when true gaps emerge—and you’ll cover 90%+ of needs efficiently, reserving custom work for what truly differentiates premium WordPress development.
Make sure to version control everything as well!