[wp-trac] [WordPress Trac] #39254: When in Customizer Preview, starter content posts are not displayed in the loop

[WordPress Trac]

#39254: When in Customizer Preview, starter content posts are not displayed in the
loop
--------------------------+---------------------------------------
 Reporter:  tiagonoronha  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.8
Component:  Customize     |     Version:  4.7
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  administration, template
--------------------------+---------------------------------------
Changes (by westonruter):

 * keywords:   => needs-patch
 * version:  trunk => 4.7
 * milestone:  Awaiting Review => 4.8


Comment:

 @tiagonoronha you're absolutely right. The underlying issue is that the
 starter content posts have the `auto-draft` status and so they are
 naturally excluded from being included in `WP_Query` loops that
 predominantly query for posts with the `publish` status. The fix for this
 has been researched and implemented in the [https://github.com/xwp/wp-
 customize-posts Customize Posts] plugin. However, it was not included in
 the core merge partially because the primary post type in focus for
 starter content was `page` and its placement in nav menus, for which the
 `auto-draft` status doesn't pose a problem. The solution developed in
 Customize Posts is also somewhat “out there” although so far it seems to
 work flawlessly and allows changes to posts to be previewed anywhere they
 appear.

 The solution can be seen in the [https://github.com/xwp/wp-customize-
 posts/pull/248 pull request], and specifically the method
 `\WP_Customize_Posts_Preview::filter_posts_request_to_inject_customized_state()`
 which is added as a filter for `posts_request`:  https://github.com/xwp
 /wp-customize-posts/blob/ccf7d89/php/class-wp-customize-posts-
 preview.php#L584-L744

 Note that Customize Posts also does filtering for postmeta SQL to ensure
 that meta queries will also work seamlessly. This wouldn't have to be part
 of the scope for just adding support for starter content since postmeta is
 not part of the scope, while previewing changes to posts and postmeta are
 the scope for the Customize Posts plugin.

 When the solution in Customize Posts was being developed, I did do a
 sanity check with @pento on the approach, and he couldn't see a
 fundamental problem with it. Two of the primary concerns I have with the
 approach is when plugins have added custom fields to the `wp_posts` table,
 as currently this would cause problems with the `UNION`s. Another concern
 with the approach is plugins which offload queries to an index like
 Elasticsearch: the plugin is currently attempting to prevent such
 offloading by supplying `'es' => false`, but in reality the query indexing
 plugins should probably be looking at the customized state and selectively
 turning off their indexed queries when detecting that there is post/page
 data in the customized state.

 I'm milestoning this for 4.8 because I think that generally themes will be
 using pages instead of posts among their starter content, and also because
 the scope of the fix is somewhat large. Perhaps the resolution of this
 defect would include a merge of the key infrastructure pieces of Customize
 Posts, including the `WP_Customize_Post_Setting` and
 `WP_Customize_Postmeta_Setting` classes. The UI as found in Customize
 Posts would naturally need complete UX review and overhaul prior to merge,
 where the UI could end up in the form of frontend editing.

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