Enable Gutenberg without making content public
-
Hi and thanks for a great plugin.
Is there a setting for a pod that makes it possible to use the Gutenberg editor without also making the all posts accessible through the public REST API endpoints (wp-json/v2/)?
-
If the content type should not be public at all, uncheck “public” and “publicly queryable” in the Advanced Settings tab of the Pod.
If the content should be public, but not the REST endpoint, see https://ww.wp.xz.cn/plugins/disable-wp-rest-api/
Thanks for the quick reply.
In this case, the content should not be public at all. I’ve disabled both “public” and “publicly queryable” under the Advanced tab. Under “Review Access Rights for Pods”, the content privacy is set to “private” and dynamic features are disabled. The pod’s post’s content can however still be read by unauthenticated visitors through the REST API if I enable it.
I’ve set up a fresh WordPress install with Pods Framework as the only plugin and created a pod with the same settings. If you go to the address below, you can see the content of the pod’s post.
https://demo86.nikkasystems.com/pods/wp-json/wp/v2/demo
Here’s the configuration.
{ "@meta": { "version": "3.2.1", "build": 1712638805 }, "settings": { "types_only": "0", "watch_changed_fields": "0", "metadata_integration": "0", "metadata_override_get": "0", "register_meta_integration": "0", "media_modal_fields": "0", "session_auto_start": "0", "dynamic_features_allow": "1", "dynamic_features_enabled": [ "display", "form" ], "show_access_restricted_messages": "0", "show_access_admin_notices": "1", "dynamic_features_allow_sql_clauses": "0", "display_callbacks": "customized", "display_callbacks_allowed": "esc_attr,esc_html", "wisdom_opt_out": "", "active_components": [ "migrate-packages", "templates" ] }, "pods": [ { "name": "demo", "id": 6, "label": "Demo pods", "description": "", "type": "post_type", "storage": "meta", "label_singular": "Demo pod", "public": "0", "show_ui": "1", "publicly_queryable": "0", "dynamic_features_allow": "0", "rest_enable": "1", "supports_title": "1", "supports_editor": "1", "_migrated_28": "1", "show_in_menu": "1", "menu_position": "0", "show_in_nav_menus": "1", "show_in_admin_bar": "1", "supports_quick_edit": "1", "exclude_from_search": "1", "groups": [ { "name": "more_fields", "id": 7, "label": "More Fields", "description": "", "weight": 0, "fields": [ { "name": "example-field", "id": 8, "label": "Example Field", "description": "", "weight": 0, "type": "text", "text_allowed_html_tags": "strong em a ul ol li b i", "text_max_length": "255", "repeatable": "0", "repeatable_format": "default", "default_evaluate_tags": "0", "default_empty_fields": "0", "roles_allowed": "administrator", "revisions_revision_field": "0", "enable_conditional_logic": "0", "rest_pick_response": "array", "rest_pick_depth": "1", "required": "0" } ] } ] } ] }Do you see any obvious configuration mistakes from my side?
The core WP REST API specifies public and show_in_rest as separate arguments. I would expect not public but show in REST to enforce authentication, but this may not be the case, as REST registrations sometimes have their own authentication callbacks.
The linked plugin is not very long; it basically boils down to the
rest_authentication_errorsfilter noted as an example in the REST FAQ. One could hypothetically modify this filter to check the requested URL or post type in addition into authentication to disable only some types for anonymous users.One might argue that it’s a reasonable expectation that not public plus show in rest equals require authentication. Filing a Feature Request with the configuration you shared above may help expedite a look into how to refine that behavior.
The topic ‘Enable Gutenberg without making content public’ is closed to new replies.