Gutenberg has been the default editor in WordPress since version 5.0. However, it does not automatically appear for Custom Post Types (CPTs).
By default, custom post types use the classic editor. To enable the block editor for a CPT, two conditions must be met during registration.
show_in_rest to true and include editor in the supports array. Missing either one will keep the classic editor active.Basic Example
Here is a typical custom post type registration without Gutenberg support:
function savvy_cpt_init() {
$labels = array(
// not relevant for this article
);
$args = array(
'labels' => $labels,
'description' => __( 'Description.', 'textdomain' ),
'public' => true,
'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
);
register_post_type( 'newcpt', $args );
}
add_action( 'init', 'savvy_cpt_init' );To enable Gutenberg for this content type, add show_in_rest set to true:
function savvy_cpt_init() {
$labels = array(
// not relevant for this article
);
$args = array(
'labels' => $labels,
'description' => __( 'Description.', 'textdomain' ),
'public' => true,
'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),
'show_in_rest' => true,
);
register_post_type( 'newcpt', $args );
}
add_action( 'init', 'savvy_cpt_init' );Why Is show_in_rest Required?
Gutenberg is built on top of the WordPress REST API. The editor uses REST endpoints to load, save, and validate post content. Setting show_in_rest to true exposes your custom post type to these endpoints, which is a prerequisite for the block editor to function.
If you need to customize the REST API route for your CPT, you can use the
rest_baseparameter to change the endpoint slug andrest_controller_classto specify a custom controller.
Without show_in_rest, WordPress falls back to the classic TinyMCE editor – even if editor is included in the supports array. This is also the reason why some developers disable Gutenberg by removing REST API support from specific post types.
Setting Default Block Templates for a CPT
Once Gutenberg is enabled, you can define a default block template that pre-populates the editor whenever a new post of that type is created. This is done using the template parameter:
$args = array(
'public' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'thumbnail' ),
'template' => array(
array( 'core/image', array( 'align' => 'wide' ) ),
array( 'core/heading', array( 'placeholder' => 'Add subtitle...' ) ),
array( 'core/paragraph', array( 'placeholder' => 'Write content...' ) ),
),
);
register_post_type( 'portfolio', $args );You can also lock the template to prevent editors from adding, removing, or reordering blocks by setting template_lock:
$args = array(
'public' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'thumbnail' ),
'template' => array(
array( 'core/image', array( 'align' => 'wide' ) ),
array( 'core/heading' ),
array( 'core/paragraph' ),
),
'template_lock' => 'all',
);
register_post_type( 'portfolio', $args );Setting template_lock to all prevents any changes to the block structure. You can also use insert to allow inserting new blocks while keeping the existing template blocks locked in place.
If you are working with ACF, take a look at the guide on creating custom Gutenberg blocks with ACF and block.json. It is a powerful way to build structured content types with a visual editing experience.
FAQs
Common questions about enabling Gutenberg for custom post types:
show_in_rest => true parameter in your register_post_type() call, or the absence of editor in the supports array. Both are required for Gutenberg to load. Also check that no plugin or theme is forcing the classic editor for that post type.show_in_rest make my custom post type publicly accessible via the REST API?
show_in_rest to true exposes the post type through the REST API, which means its content can be read by unauthenticated requests by default. If the CPT contains private data, you should implement custom permissions using the rest_controller_class or capability checks.public to false and still enable Gutenberg by setting show_in_rest to true and show_ui to true. The REST API exposure is needed for the editor, but it does not require the post type to have a public-facing archive or single template.template_lock do?
template_lock parameter controls whether editors can modify the block structure defined in the template parameter. Setting it to all prevents adding, removing, or moving blocks. Setting it to insert prevents adding or removing blocks but allows reordering. Omitting it gives editors full control.show_in_rest?
show_in_rest alone does not require a rewrite flush. However, if you change the rest_base or modify other URL-affecting parameters at the same time, visit Settings > Permalinks once to flush the rules. Never call flush_rewrite_rules() on every page load - only on plugin activation or deactivation.Summary
Enabling Gutenberg for a custom post type requires just one addition to your register_post_type() call: setting show_in_rest to true. This exposes the post type to the REST API, which the block editor depends on to function.
Beyond basic activation, you can take advantage of block templates to pre-populate the editor with a specific block structure, and lock the template to enforce content consistency. These features make CPTs with Gutenberg a powerful tool for structured content editing.
