[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 joehoyle):

 >  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.

 I don't think this is the right approach, and also I don't think anything
 is changing on a whim. Forget any "REST" based flag, we should be saying
 what is public, and what isn't, and for not-public things, who has access
 to read them. We have to deal with the backwards compat of `show_in_rest`
 (hence this ticket), but introducing more technology specific flags has to
 be the wrong direction.

 This is precisely what I've proposed in this ticket:

 >  I propose we default show_in_rest to true in the following scenarios:

 >    Object types registered with public => true (only).
 >    Object types registered with publicly_queryable => true.

 Because those ''are'' already public. I think there are more cases to open
 up more "private" post types to the REST API, however I'm not trying to
 boil the ocean with this ticket. Even if we think that `public => true` is
 too broad, there has to be a case for `publicly_queryable => true`, as I
 can get that data from any WordPress site by adding a query var to the
 URL.

 >  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.

 Yes, I think 42785.4.diff is a very bad hack and should not be committed -
 `is_user_logged_in` means next to nothing.

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