Skip to content
ExponaBLOG
WORDPRESS DEVELOPMENT & PLUGINS · DAY 076 / 100

Gutenberg for clients in WordPress Development & Plugins

Make editing easy for non-developers.

Expona Admin7 min read

Gutenberg for clients in WordPress Development & Plugins

Your clients hired you to build a WordPress site, but now they're terrified of breaking the layout when they edit content. The Gutenberg editor is powerful—but without guardrails, non-developers struggle with block options, accidentally delete critical sections, or create pages that look nothing like your designs. We're going to walk through four proven techniques that turn Gutenberg into a client-friendly tool while keeping your design integrity intact.

Why Gutenberg needs guardrails for clients

Gutenberg is fundamentally different from the Classic Editor. It's block-based, flexible, and gives editors granular control—which is exactly why untrained clients get lost. They see 50+ blocks available and don't know which ones belong on their pages. They nest groups incorrectly. They change column widths and spacing without understanding breakpoints. They delete reusable blocks thinking they're removing one instance.

The solution isn't to hide Gutenberg. It's to configure it thoughtfully. You set up template locks to prevent structural changes, restrict available blocks to what makes sense for their page type, provide pre-built patterns so they copy-paste complete sections, and give them focused training on what they actually need to do.

Lock templates — Template locks keep layouts intact

Template locking is your first line of defense. It lets you define which parts of a page structure can be edited and which are off-limits. You can lock entire templates, specific blocks, or even just the nesting structure while allowing content changes.

There are several lock levels available in Gutenberg:

  • No lock: Full editing freedom (default).
  • Partial lock: Content inside blocks can be edited, but structure cannot be moved or deleted.
  • Full lock: Nothing can be changed—useful for fixed components like headers.

Here's how you implement template locking in a block template file (used with FSE or custom post types):

php
register_block_pattern(
    'mysite/homepage-hero',
    array(
        'title'         => 'Homepage Hero Section',
        'description'   => 'Hero with image and CTA',
        'content'       => '<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">
<!-- wp:heading {"level":1} -->
<h1>Welcome</h1>
<!-- /wp:heading -->
<!-- wp:paragraph -->
<p>Edit this text</p>
<!-- /wp:paragraph -->
<!-- /wp:group -->',
        'lock'          => array(
            'move'   => true,
            'remove' => true,
        ),
    )
);

For more granular control, use the lock property on individual blocks when building templates programmatically:

php
// In a custom block template
$template = array(
    array(
        'core/group',
        array(
            'lock' => array(
                'move'   => true,
                'remove' => true,
            ),
        ),
        array(
            array(
                'core/heading',
                array(
                    'level'   => 1,
                    'content' => 'Main Section',
                ),
            ),
            array(
                'core/paragraph',
                array(),
            ),
        ),
    ),
);

In practice: you create a landing page template where the header section, footer, and sidebar are locked. The client can only edit the hero heading, the main content paragraphs, and image galleries in the center. They cannot move or delete the structural containers. This prevents accidental layout collapse while giving them real editing power where it matters.

Limit blocks — allowed_block_types_all filter

By default, Gutenberg offers the kitchen sink. Your client sees Social Sharing blocks, Audio blocks, Legacy Gallery blocks, and 20 others they'll never use. They get overwhelmed and sometimes use the wrong blocks for the job.

The allowed_block_types_all filter lets you curate the block library per post type, per user role, or globally. You show only the blocks that make sense for your site.

Here's a practical example for a real estate site where clients manage property listings:

php
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
    // For the 'property' post type
    if ( isset( $editor_context->post ) && 'property' === $editor_context->post->post_type ) {
        return array(
            'core/heading',
            'core/paragraph',
            'core/image',
            'core/gallery',
            'core/list',
            'core/quote',
            'core/group',
            'core/columns',
            'core/button',
            'core/spacer',
        );
    }
    
    // For regular posts
    if ( isset( $editor_context->post ) && 'post' === $editor_context->post->post_type ) {
        return array(
            'core/heading',
            'core/paragraph',
            'core/image',
            'core/gallery',
            'core/list',
            'core/quote',
            'core/embed',
            'core/table',
            'core/group',
            'core/columns',
        );
    }
    
    return $allowed_blocks;
}, 10, 2 );

You can also restrict blocks for specific user roles:

php
add_filter( 'allowed_block_types_all', function( $allowed_blocks, $editor_context ) {
    // Non-admin users get a minimal set
    if ( ! current_user_can( 'manage_options' ) ) {
        return array(
            'core/heading',
            'core/paragraph',
            'core/image',
            'core/list',
            'core/button',
        );
    }
    
    return $allowed_blocks;
}, 10, 2 );

The benefit is immediate: your client opens the editor and sees only the 10 blocks they need, not 80. They move faster, make fewer mistakes, and the editing experience feels tailored to their role.

Patterns — Ready-made sections for common pages

Block patterns are pre-built, reusable sections that clients can insert with one click. Instead of starting blank or manually recreating common layouts, they choose "Testimonials Section" and get a fully designed, properly spaced grid of testimonial cards ready to customize.

Register patterns in your theme or plugin:

php
register_block_pattern(
    'mysite/testimonials-grid',
    array(
        'title'       => 'Testimonials Grid',
        'description' => 'Three-column grid with testimonial cards',
        'content'     => '<!-- wp:group {"layout":{"type":"grid","columnCount":3}} -->
<div class="wp-block-group">
<!-- wp:group {"className":"testimonial-card"} -->
<div class="wp-block-group testimonial-card">
<!-- wp:paragraph -->
<p><strong>Quote goes here.</strong></p>
<!-- /wp:paragraph -->
<!-- wp:paragraph {"fontSize":"small"} -->
<p class="has-small-font-size">— Client Name</p>
<!-- /wp:paragraph -->
<!-- /wp:group -->
<!-- wp:group {"className":"testimonial-card"} -->
<div class="wp-block-group testimonial-card">
<!-- wp:paragraph -->
<p><strong>Quote goes here.</strong></p>
<!-- /wp:paragraph -->
<!-- wp:paragraph {"fontSize":"small"} -->
<p class="has-small-font-size">— Client Name</p>
<!-- /wp:paragraph -->
<!-- /wp:group -->
<!-- wp:group {"className":"testimonial-card"} -->
<div class="wp-block-group testimonial-card">
<!-- wp:paragraph -->
<p><strong>Quote goes here.</strong></p>
<!-- /wp:paragraph -->
<!-- wp:paragraph {"fontSize":"small"} -->
<p class="has-small-font-size">— Client Name</p>
<!-- /wp:paragraph -->
<!-- /wp:group -->
<!-- /wp:group -->',
        'categories'  => array( 'social', 'call-to-action' ),
    )
);

Create patterns for sections your clients actually need: hero sections, feature grids, pricing tables, contact forms, service cards, team members, FAQs. Aim for 8–12 essential patterns per site type rather than 50 generic ones.

Then organize them by category so clients find what they need. When they build a new page, they pick patterns for each section, customize the text and images, and they're done in 15 minutes instead of an hour of manual block assembly.

Training — Short videos beat long manuals

Documentation and written guides are forgotten within a week. Video training sticks. But don't make a 30-minute course—your clients won't watch it. Instead, record 2–3 minute videos targeting specific tasks they do weekly.

Example video topics:

  • How to edit a page (click the Edit button, find your section, change text).
  • How to add an image (click the image block, upload).
  • How to use patterns (insert a pattern, fill in your details).
  • What NOT to do (don't drag blocks around, don't delete locked sections).
  • How to publish and preview.

Host these on a private Loom, Vimeo, or YouTube playlist. Link them in your WordPress handover document and in the admin footer so clients see them when they need help. Record a fresh version each time you roll out a site, showing their specific patterns and workflows.

Pair this with a one-page quick reference (single sheet, 8–10 points, printed or PDF) and a 30-minute kickoff call where you walk through editing together. That combination covers 95% of client questions.

Common mistakes

  • Locking too much: Clients feel restricted and call with "why can't I change this?" Find the balance—lock structure, unlock content.
  • Not testing with the actual client: You think your block setup makes sense. The client gets confused anyway. Always have them test-edit a real page before you hand it over.
  • Forgetting about mobile: You limit blocks but don't preview how they behave on phone. Responsive issues still break layouts even with restrictions.
  • Too many patterns: A long pattern list is just another form of overwhelm. Curate to 8–12 per site.
  • No follow-up support window: Clients will get stuck in week two and need 10 minutes of help. Budget for that in your proposal.

Key takeaways

  • Use template locking to prevent structural changes while allowing content edits.
  • Filter allowed blocks by post type and user role so clients see only what they need.
  • Create 8–12 high-value block patterns for common page sections your clients build repeatedly.
  • Record short video walkthroughs (2–3 minutes each) and provide a one-page quick reference.
  • Test your setup with an actual client before launch and budget for a short support window afterward.
  • Gutenberg for clients is not about hiding features—it's about thoughtfully guiding non-developers to success.
ShareXLinkedInReddit

Found this useful? Support the writing.

Buy me a coffee
Written by
Expona Admin
Site administrator

Comments

Loading comments…

Leave a comment

Comments are reviewed before they appear. Be kind and stay on topic.

Related articles