Building a WordPress website for a client: creating a streamlined editorial experience

In this post, I want to explore the foundation of building a site for a client using the WordPress Site Editor and Block Editor. How do I build a site when core blocks alone don’t fully meet design and user requirements? What are my options, and what’s the best approach?

Say Hello Logo

I offer technical, training, programming and conceptual support for partner agencies and freelancers through my agency Say Hello: either on-site or via email, Slack or video call. Get in touch if you’d like to discuss what options I provide. I am fluent in English, German and Swiss German, and my daily rate is means-adjusted for international work.

The primary goal of any website is to ensure content is accessible to both human visitors and search engine crawlers. Many site-building tools prioritise speed and automation but overlook long-term usability. AI-generated sites may look good at first, but what happens when site owners need to update their content later?

Many users turn to platforms like Squarespace or plugins like Elementor for flexibility and lower costs, but these often introduce complex settings and maintenance challenges. A well-curated editorial experience should make content management intuitive, allowing users to focus on their business rather than learning web design and accessibility.

Lessons from a complex project

WordPress provides a range of built-in blocks for layouts, from columns to grids and media with text. However, while WordPress is highly flexible, it’s designed for a broad user base. Thoughtful implementation is key to building a structured, maintainable, and user-friendly site.

I learned this the hard way. Early in the Block Editor’s development, I built a site where every content element was part of a complex, highly customisable layout with several layers of nested blocks. While the site still looks great and functions well, the client struggles with the editorial complexity. Budget constraints prevent them from investing in a technical rework that would make annual content updates easier.

From a development perspective, I consider this a partial failure because I couldn’t convince the client that less control would ultimately benefit them. In hindsight, I should have kept the editorial experience simple from the outset—curating it so users could focus on content without dealing with intricate page layouts.

So, how can I achieve this? Traditionally, content and design were kept separate, but page builders and the Block Editor have blurred that distinction. While structured data management is useful for multi-platform outputs (e.g., websites, apps, data streams), this approach is unnecessary for most projects. Instead, the focus should often be on providing a streamlined, user-friendly editing experience.

How would I approach this project today?

If I were to start this project again, I would take a different approach.

Most pages in the project follow a handful of common layouts:

  • Image left, text right (and vice versa)
  • A video player
  • A three-column cards layout
  • News sections
  • Hero elements with a background image or video, title, subtitle, and buttons

These layouts can all be created with collections of WordPress core blocks, but assembling them manually can be cumbersome. That’s why WordPress introduced patterns—predefined block groups that simplify content creation.

Patterns help, but what if a client with dozens of pages wants to tweak spacing across all instances of a layout later on? Synchronised and partially synchronised patterns provide some support, but essential features are missing from WordPress to allow this using core technologies. Open-source development has many competing priorities, meaning WordPress doesn’t always provide everything we need, when we need it. However, as site builders, we can bridge these gaps by applying our own expertise.

Core blocks or custom blocks?

Before starting a project, I determine which core WordPress features I can use and where custom development is necessary. Relying solely on core blocks has been challenging, particularly due to a lack of responsive controls and the complexity of adding custom settings. However, most clients don’t want to manage screen-specific layouts—they just want everything to work. It’s my job to take nearly thirty years of experience in using and building content management systems to make that happen.

I rely heavily on self-built custom blocks. Eight years ago, I built a custom content management framework using Advanced Custom Fields (ACF) and implemented it across many projects. Some of those sites still run on it today. ACF remains a valid and effective tool, providing a simple, intuitive editorial experience—provided the developer structures it thoughtfully. The downside is that ACF is a third-party dependency, which some developers prefer to avoid.

Over the past few years, I’ve taken a similar approach to my former ACF-based solution, but now rely on hand-coded blocks for most projects. This allows me to take full advantage of the Block Editor while keeping the user experience close to core WordPress functionality. Rather than depending on patterns and incomplete core features, I sometimes wrap core blocks inside a custom container using InnerBlocks. This provides greater flexibility in defining how content is formatted, while allowing advanced core blocks to handle the heavy lifting inside the editor.

For more complex content elements, where there is a danger that layouts can be broken by a requirement for the use of complex data, I build blocks from scratch using a React-based editorial interface with a PHP-rendered frontend. Thanks to the block.json registration schema, I can load CSS and JavaScript only when a block is used, reducing unnecessary frontend code.

By defining my own frontend output, I can:

  • use modern frontend technologies like JavaScript, web components, CSS Grid, and individual, hand-crafted responsive design at a component level,
  • optimise caching for complex data,
  • and write semantic HTML for improved accessibility.

Other third-party solutions

Why not just use a block library like GenerateBlocks? While trusted block plugins are valuable for many projects, using them also means relying on a third-party dependency. These tools often modify the editorial workflow and introduce extra settings, which can complicate content management rather than simplifying it.

Using such tools also means depending on:

  • the availability of features and controls,
  • the decisions made by the plugin’s developers,
  • and the long-term sustainability of the third-party provider.

While this can be a valid approach, I don’t believe adding layers of complexity improves the editorial experience. Instead, I focus on streamlining the content management process by building lean, efficient, and future-proof solutions tailored to each project.

Conclusion

The Block Editor has come a long way, but the limitation of waiting for new features or relying on technology which doesn’t allow you to apply all of your own expertise still requires careful consideration when designing an editorial experience. Core blocks provide a strong foundation, but custom blocks allow greater control and a more refined editing workflow.

By prioritising usability, efficiency, and maintainability, we can ensure that WordPress sites remain both powerful and easy to manage—without unnecessary complexity.

Leave a Reply

Your email address will not be published. Required fields are marked *