Gutenberg: Custom Post type: If param 'publicly_queryable' = 'false' the editor shows "Updating failed" notice.

[heldervilela]

If the custom post type is 'publicly_queryable' => false the editor show the notice "Updating failed" when it tries to save the draft.

Because of this error:

Let me know if more info is needed.

Additional context

• WordPress 5.0.

[danielbachhuber]

Thanks for the report, @heldervilela.

In your Developer Tools, can you take a screenshot of and share the API request / response itself? I'm curious whether the JSON is properly formed, and what sort of HTTP response you're getting from WordPress.

[heldervilela]

@danielbachhuber I'm glad to help

From what I saw when comparing with another CPT the answer is the same.

Request:

Response:

[danielbachhuber]

Oh, interesting. And there's no preview_link value because the post isn't publicly_queryable.

I think the Gutenberg JavaScript shouldn't be trying to access the preview_link in this case. I've flagged this as a bug for WordPress 5.0.1.

[aduth]

Would you be able to share the full code of your custom post type registration?

I've been unable to reproduce the save failure / error notice using the following code:

<?php

/**
 * Plugin Name: Demo CPT
 */
add_action( 'init', function() {
    register_post_type( 'book', [
        'label' => 'Book',
        'show_in_rest' => true,
        'public' => true,
        'publicly_queryable' => false,
        'supports' => [ 'title', 'editor' ],
    ] );
} );

[heldervilela]

You have to add revisions to supports.

[danielbachhuber]

I can reproduce the issue with WordPress 5.0 and Gutenberg the plugin at b7e343d

add_action( 'init', function() {
    register_post_type( 'book', [
        'label' => 'Book',
        'show_in_rest' => true,
        'public' => true,
        'publicly_queryable' => false,
        'supports' => [ 'title', 'editor', 'revisions' ],
    ] );
} );

Here's a GIF of my experience:

And here's the final state:

[danielbachhuber]

Ah, here's the earlier report of this too: https://core.trac.wordpress.org/ticket/45404

[aduth]

The error happens here, where the passed url is undefined, thus indexOf will throw:

https://github.com/WordPress/gutenberg/blob/1a1dc7c15f556a5298c2549e219fdc79fb951304/packages/url/src/index.js#L170

This happens with the fallback case of the editor's handling of save completion, where it attempts to set a query parameter to the post url:

https://github.com/WordPress/gutenberg/blob/1a1dc7c15f556a5298c2549e219fdc79fb951304/packages/editor/src/store/reducer.js#L1218

The problems are:

• post is a revision, so it doesn't include link
• preview_link is _set_ on post, but it is an empty string (the || triggers the RHS logic because the falsiness of empty string)

The reason it is assigned as an empty string can be tracked to the preview_link assignment in the autosaves controller:

https://github.com/WordPress/wordpress-develop/blob/5.0/src/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php

The value is null because when a post type is publicly_queryable => false, it is not "viewable":

https://github.com/WordPress/wordpress-develop/blob/5.0/src/wp-includes/link-template.php#L1235-L1243
https://github.com/WordPress/wordpress-develop/blob/5.0/src/wp-includes/post.php#L1781

There's a few action items here:

• addQueryArgs should never throw. Based on the equivalent behavior from add_query_arg, I suspect it should return the string with only query arguments.
• The previewLink reducer should not return a new value if neither preview_link nor link are usable
  
  
  
  • Verify no regressions in preview behavior if the preview link can't be assigned
  
  
• Consider: Should preview_link be assigned even if 'publicly_queryable' => false ? I'm unsure of the repercussions of changing get_preview_post_link

[aduth]

Verify no regressions in preview behavior if the preview link can't be assigned

We already handle this: The preview button will not be shown if the post type is not viewable, following the same logic noted previously considering publicly_queryable.

[aduth]

• addQueryArgs should never throw. Based on the equivalent behavior from add_query_arg, I suspect it should return the string with only query arguments.

See: #12803

• The previewLink reducer should not return a new value if neither preview_link nor link are usable

See: #12800