WP REST API: allow separate add_post_type_support() for post when accessing via REST vs WP Admin

[lougreenwood]

I have a number of CPTs where I have disabled various features (post_title, author etc) so that these fields are disabled in WP Admin. However, I have code which is triggered aftershave which auto-sets values for these fields. The reason for disabling the fields in WP Admin is to maintain the integrity of these field values and know that the post_title will always be an auto-set value.

I also have functional tests which use WP REST API to check that these post_titles are automatically set correctly.

It seems that when features are disabled using add_post_type_support(), its not possible to override this when accessing WP REST API. this means that in my scenario it's not possible to pass my tests because post_title is not present in REST API response (because it's disabled using add_post_type_support())

I have an idea for a short term hack, which is to check for user ID or role (to identify a test user which I used by functional tests) and then enable these features when REST API is being used. but it seems overly hacky.

Is there any plan for separating add_post_type_support() for REST and standard WP?

[rmccue]

I'm not sure exactly what your use case is here; if you could elaborate exactly what you're trying to achieve, that would be pretty useful.

Are you using the add_post_type_support() calls simply to add/remove admin UI?

Generally speaking, the REST API represents the underlying data structures in WordPress, and thus it doesn't make sense for it to support different things to the admin. With that said, some of the post type supports are used ambiguously in WordPress; in particular, things like editor can control both whether you want the editor UI in the admin, and whether you have post content at all.

We may be able to introduce new filters to enable turning off the UI without changing the underlying post type support, which would probably be a better way to solve this, if it's what you're doing.

[lougreenwood]

@rmccue sure.

So, I have a bunch of CPTs, these have various afterSave() methods which will automatically save various values into the post fields when a save action hook is triggered.

One of these auto-saved fields in post_title. However, in this scenario, I need to disable post_title in wp-admin, but keep access to it using the REST API.

I'm using the Pods plugin to manage these CPTs and IIRC Pods uses add_post_type_support() to enable/disable post_title etc in wp-admin.

So, to recap, the scenario is:

• Multiple CPTs (managed by Pods.io plugin)
• Disabling post_title for some of these CPTs using add_post_type_support() or similar
• Still need to be able to access these fields which are hidden in wp-admin using REST

It seems that your suggestion is a better idea: keeping post_title enables but adding a filter to hide in wp-admin:

We may be able to introduce new filters to enable turning off the UI without changing the underlying post type support, which would probably be a better way to solve this, if it's what you're doing.

Ideally, this would be configurable on a per-field basis (both built in fields and custom fields).

CC @sc0ttkclark

EDIT:

I missed this, so to clarify, the answer to the following is yes:

Are you using the add_post_type_support() calls simply to add/remove admin UI?

[danielbachhuber]

@lougreenwood Rather than using remove_post_type_support() to disable the corresponding UI in the admin, I'd suggest unregistering the meta box instead. Unregistering the meta box is a bit more conceptually precise, as it's only impacting the UI.

Closing as wontfix because I don't think we'll be changing the REST API behavior at this point. Happy to chat in Slack if you want to discuss potential alternatives.