[wp-trac] [WordPress Trac] #42785: Change default of `show_in_rest` in register_post_type and register_taxonomy
WordPress Trac
noreply at wordpress.org
Fri Mar 30 18:17:07 UTC 2018
#42785: Change default of `show_in_rest` in register_post_type and
register_taxonomy
-------------------------------------------------+-------------------------
Reporter: joehoyle | Owner: pento
Type: enhancement | Status: assigned
Priority: normal | Milestone: 4.9.6
Component: REST API | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-unit-tests needs- | Focuses:
refresh |
-------------------------------------------------+-------------------------
Comment (by danielbachhuber):
> Do you have any link to discussions explaining the need for
`show_in_rest`, I'd love to learn more about those compromises?
Sure, here's some of the genesis (with links to corresponding Slack
conversations):
* [https://github.com/WP-API/WP-API/issues/136 Add register_post_type
argument for API exposure]
* [https://github.com/WP-API/WP-API/issues/710 Clarify expectations and
impact of the 'show_in_json' Post Type flag]
* [https://github.com/WP-API/WP-API/issues/419 Private taxonomy data
shouldn't be exposed without appropriate capabilities]
The nut of it is that we can't expose information publicly unless we can
''prove'' that it can be public. For instance, a registered CPT could be
using `post_excerpt` for some secret notes. Because they're secret, the
developer hasn't exposed the field in the theme templates. And there's no
way for us to declaratively know whether this custom use of data is safe
to reveal unless the developer has explicitly marked `show_in_rest=true`.
If we want to transition WordPress to an API-driven world, we need a
better plan than default `show_in_rest=true` and hope there's no impact.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/42785#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list