[wp-trac] [WordPress Trac] #42785: Change default of `show_in_rest` in register_post_type and register_taxonomy

[WordPress Trac]

#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):

 > So, it's better we start planning for this now. I propose we define for
 each entity what's public, what's not, what capability is needed to see
 any field.

 Yes, +1 to this. I think this ticket needs to be a research project first,
 and implementation details later. Personally, I'd suggest tracking down a
 couple dozen real implementations of CPTs, and then begin evaluating from
 there.

 > There's undoubtedly some work to do to define exactly what post types
 can be read be unauthenticated users, and logged in ones. However,
 `show_in_rest` should not be this, and we should start to phase it's
 existence out.

 Exactly this. However, `show_in_rest` has historically meant "reveal in
 REST" (whether or not the data is exposed), so I don't think it makes
 sense to change this on a whim. Possibly, the intermediate implementation
 could be `editable_in_rest` and default to `true`.

 The key distinction (based on my understanding of the ticket description):

 * `show_in_rest` defaulting to `true` would mean the existence of the CPT
 is exposed to the world (and possibly have some unexpected information
 disclosure issues).
 * `editable_in_rest` would meant the CPT could be editable in the backend
 with appropriate authorization, but would expose no existence to the
 unauthorized world.

 > With the ''right access controls'', there should be no reason ''by
 default'' not to expose the data over the REST API.

 Correct. But these aren't present in 42785.4.diff. That patch, for
 instance, would give me (a WordPress.com user) access to every CPT
 registered on every CPT site. Not only that, but it also incorrectly
 overrides the value passed by the developer.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42785#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform