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

 To justify the creation of this ticket a little more - let me spell out
 why I think we need to do this.

 I think primarily we should be focusing on the semantics of what data is
 readable, by who, what is public etc. Unfortunately the definitions of
 `public` in a post type is pretty fraught with exceptions, there's
 multiple ways in interpret `show_ui`, `publically_queryable` etc - for
 this reason, in the introduction of the REST API we put up a simple wall
 "show_in_rest" to just be simple about what data is included in the REST
 API. The obvious issues with this approach is that we 1: defaulted to
 true, and 2: divorced it of any association with what the user-access is
 on the data; it encourages the wrong approach.

 Perhaps it made sense at the time, given the REST API was a new thing
 where we wanted to be conservative - but now it's considered (for
 Gutenberg at least) the source of the data on the WordPress site. It
 doesn't make sense to have a technology-enabled flag anymore. 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. The
 REST API is no longer a new technology that is relegated to optional
 activation per cpt - it's a core part of the technology stack of
 WordPress, which is demonstrated more than ever in the building of
 Gutenberg.

 ''With the right access controls'', there should be no reason ''by
 default'' not to expose the data over the REST API. If you're a developer
 that's building a shadow post type, then sure - we have a way to opt out,
 but that's not the norm. The REST API should not be a myopic view into
 your whole WordPress data, on a developer-only opt-in basis, it should by
 default, contain access to as much of it as possible (assuming we of
 course have sane publicity defaults, which I think we pretty much already
 to).

 That all being said, its time to focus on specifics that `show_in_rest =
 true` is adversely cause.

 ---

 Random replies:

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

 This isn't true - this data could, and I think _would_ be in the RSS
 Feeds, for one thing. If a post type is registered as `public`, that's the
 closest we are ever going to get to say something is public.

 >  To the point above, I think it's important that we follow-up with
 another patch to force show_in_rest to true (for public CPTs and
 taxonomies) for loggedin users (other than subscribers) and not being only
 a default value, because people will expect to be able to use Gutenberg
 for all CPTs in the backend no matter the value set for show_in_rest.

 We should be thinking only in capabilities, not roles - or logged in
 state. Also, nit-pick "all CPTs in the backend no matter the value set for
 show_in_rest" this isn't true, users will expect to see any CPTs they
 ''know about''. Just like the rest of the admin, there's no such thing as
 "show all CTPs" (menus being one example).

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