Gutenberg: Gutenberg editor shows blank screen for custom post type when GB is enabled via code but show_in_rest is false

Created on 29 Nov 2018  路  16Comments  路  Source: WordPress/gutenberg

Describe the bug
Gutenberg editor shows blank screen for custom post type.

To Reproduce
Steps to reproduce the behavior:

  1. Install vanilla WP RC1 and the GB v 4.5.1 plugin
  2. Add the following to the functions.php of twentyseventeen theme
// Register post type
$labels = array(
    'name'               => _x( 'MD Stories', 'post type general name', 'feature-template' ),
    'singular_name'      => _x( 'MD Story', 'post type singular name', 'feature-template' ),
    'menu_name'          => _x( 'MD Stories', 'admin menu', 'feature-template' ),
    'name_admin_bar'     => _x( 'MD Story', 'add new on admin bar', 'feature-template' ),
    'add_new'            => _x( 'Add New', 'MD Story', 'feature-template' ),
    'add_new_item'       => __( 'Add New MD Story', 'feature-template' ),
    'new_item'           => __( 'New MD Story', 'feature-template' ),
    'edit_item'          => __( 'Edit MD Story', 'feature-template' ),
    'view_item'          => __( 'View MD Story', 'feature-template' ),
    'all_items'          => __( 'All MD Stories', 'feature-template' ),
    'search_items'       => __( 'Search MD Stories', 'feature-template' ),
    'parent_item_colon'  => __( 'Parent MD Stories:', 'feature-template' ),
    'not_found'          => __( 'No Custom MD found.', 'feature-template' ),
    'not_found_in_trash' => __( 'No Custom MD found in Trash.', 'feature-template' ),
);

$args = array(
    'labels'             => $labels,
    'public'             => true,
    'publicly_queryable' => true,
    'show_ui'            => true,
    'show_in_menu'       => true,
    'query_var'          => true,
    'rewrite'            => array( 'slug' => 'md-feature' ),
    'capability_type'    => 'post',
    'has_archive'        => true,
    'hierarchical'       => true,
    'menu_icon'          => 'dashicons-schedule',
    'menu_position'      => 12,
    'supports'           => array( 'title', 'editor', 'revisions', 'author', 'thumbnail', 'excerpt', 'page-attributes' ),
    'taxonomies'         => array( 'category', 'post_tag' ),
);

register_post_type( 'mdtest', $args );


add_filter('gutenberg_can_edit_post_type', 'cnmd_enable_gutenberg_for_longform_cpt', 10, 2);
add_filter('use_block_editor_for_post_type', 'cnmd_enable_gutenberg_for_longform_cpt', 10, 2);
function cnmd_enable_gutenberg_for_longform_cpt($current_status, $post_type) {
    if ($post_type === 'mdtest') {
        return true;
    }
    return $current_status;
}
  1. Create a new post of this custom post type

Expected behavior
The GB editor should be visible. Instead I get a white page. There is page src content and no script errors in the log, just nothing showing in the browser.

Desktop (please complete the following information):

  • OS: macos sierra
  • Browser chrome
  • Version 70.0.3538.102
[Feature] Extensibility [Type] Bug

Most helpful comment

Regarding Gutenberg editor shows blank screen for custom post type when GB is enabled via code but show_in_rest is false: in my case show_in_rest is set to true, and this still happens.

All 16 comments

Thank you for the clear steps!!

I tested adding the sample code to functions.php in Twenty Seventeen with WordPress 5.0-RC1-43946 as well as WordPress 5.0-RC1-43946 + Gutenberg 4.5.1 and going to MD Stories > Add New and I can confirm that using WP5.0-RC1 results in a blank page for the editor with no errors in the console and the following response headers for the CPT:

screen shot 2018-11-29 at 11 15 42 am
Seen at https://madefortesting.com/wp-admin/post-new.php?post_type=mdtest running WordPress 5.0-RC1-43946 AND Gutenberg 4.5.1 using Firefox 63.0.3 on macOS 10.13.6.

When I tested with WordPress 5.0-RC1-43946 without the Gutenberg plugin added separately, I found that the CPT falls back to the classic editor:

screen shot 2018-11-29 at 11 13 21 am
Seen at https://madefortesting.com/wp-admin/post-new.php?post_type=mdtest running WordPress 5.0-RC1-43946 using Firefox 63.0.3 on macOS 10.13.6.

This is just a guess, but it seems that it falls back to the classic editor without the plugin because the core version doesn't make use of the use_block_editor_for_post_type filter.

Updated to Gutenberg 4.6.0 and the problem remains.

Updated to WordPress 5.0-RC1-43946 and the problem remains.

Updated to WordPress 5.0-RC2-43958 and the problem remains

Adding 'show_in_rest' => true, to the custom post type definition enables the editor. So this bug should really be "Gutenberg editor shows blank screen for custom post type when GB is enabled via code but show_in_rest is false"

Behaviour should be to either over-ride the imlicit show_in_rest = false and show GB, or fall back to the classic editor. A white screen is not the answer.

Currently, this seems to fall back to the classic editor. Whereas that's a lot better than a blank screen, it's confusing for end-users that think/thought that they've entirely switched to the block editor.

Moved this from Needs Technical Feedback to [Type] Bug and we'll now want to wait for a reply from a developer. Thank you for the update @theMikeD, it is appreciated!

Regarding Gutenberg editor shows blank screen for custom post type when GB is enabled via code but show_in_rest is false: in my case show_in_rest is set to true, and this still happens.

Register your custom post type on 'init' but earlier than default (10). That fixed my 'blank screen'.


function nen_create_post_type_project()
{
    // register your post type 
}
add_action( 'init', 'nen_create_post_type_project' , 5 )

Regarding _Gutenberg editor shows blank screen for custom post type when GB is enabled via code but show_in_rest is false_: in my case show_in_rest is set to true, and this still happens.

Same thing with me. I tried to create a Custom Post Type and Gutenberg showed a white screen when I tried to open the editor and add a new post.

This happens both with show_in_rest as True or as False.

I'm using WordPress 5.2.3 and creating a custom theme (not using some default WP Theme).

damn this guternberg

I have a custom post type video, enabled with guternberg editor
And I want to assign a custom taxonomy to it
After adding the taxonomy to the post type, the add/edit view turns white screen.
Disabling the gutenberg on the custom post type (show_in_rest to false), it's working but the editor is no longer gutenberg

        $cplural = 'Types';
        $csingular = 'Type';
        $clabels = array(
            'name'              => __( $cplural ),
            'singular_name'     => __( $csingular ),
            'search_items'      => __( 'Search '.$csingular ),
            'all_items'         => __( 'All '.$cplural ),
            'parent_item'       => __( 'Parent '.$csingular ),
            'parent_item_colon' => __( 'Parent '.$csingular.':' ),
            'edit_item'         => __( 'Edit '.$csingular ),
            'update_item'       => __( 'Update '.$csingular ),
            'add_new_item'      => __( 'Add New '.$csingular ),
            'new_item_name'     => __( 'New '.$csingular.' Name' ),
            'menu_name'         => __( $csingular ),
        );      
        $cargs = array(
            'hierarchical'      => true,
            'labels'            => $clabels,
            'show_ui'           => true,
            'show_admin_column' => true,
            'query_var'         => true,
            'show_in_rest'      => true,
            'rewrite'           => array( 'slug' => strtolower($csingular) ),
            'public'            => true
        );
        register_taxonomy( strtolower($csingular), array(), $cargs );
        register_taxonomy_for_object_type('type', 'videos' );

Any update on this? It's still happening in March 2020 (WP 5.3.2) and I can't find any solution.

Check the action hook you'r using. Gutenberg uses ajax/rest to get it's data. The custom post type has to be set before the ajax call is handled by the rest-api. My blank screen was fixed using a priority 5 on action hook 'init': add_action( 'init', 'your_function' , 5 );

Thank you @studionenontwerp. Your solution seems to fix the issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

spocke picture spocke  路  3Comments

pfefferle picture pfefferle  路  3Comments

franz-josef-kaiser picture franz-josef-kaiser  路  3Comments

BE-Webdesign picture BE-Webdesign  路  3Comments

maddisondesigns picture maddisondesigns  路  3Comments