Re-implement logic for previewing WP_Query and introduce non-multiple postmeta

[westonruter]

This introduces a somewhat radical approach to getting customized data to appear as expected in previewed post queries: the customized data is UNION'ed with the wp_posts and wp_postmeta table via inline literal SELECTs which then serve as a subselect for the main select which gets the results. The effect is that we can rely on MySQL as normal to handle all of the various WP_Query vars, including any Meta Queries that may be thrown at it.

This fixes what the #247 PR set out to do, which was to hackily force a customized post to appear on the first page of results (even if it doesn't belong there). By going deep into the MySQL query to inject the customized data, it seems that we get complete support for WP Query, amazingly. It's still hard to believe that this works and I want to consider this experimental and get testing on it.

Fixes #246

Non-single (multiple) postmeta is credited to @PatelUtkarsh.

• Add unit tests for multi-postmeta.
• Change priority of the_posts filter to apply as early as possible since post fields will get hydrated there since SELECT literals will omit data not needed.
• Add customize_previewed_postmeta_rows filter to allow meta to be filtered before being injected into a query:

  wp-customize-posts/php/class-wp-customize-posts-preview.php

  Line 551 in 91b62a8

  foreach ( $postmeta_rows as $postmeta_row ) {

• Fix queries made when fields => ids is used.
• Ensure that customize_previewed_posts_for_query filter can indeed be removed.
• Consider reversing the order of the UNIONs so that customized posts will be returned first if a list of posts have identical values to orderby, as then the sorting becomes unstable, and the same order would not be previewed. This is an edge case.
• Preserve order of plural postmeta?

[PatelUtkarsh]

@westonruter Not accepting a case when $meta_value is an array. (Takes fist value and ignores other.)

[westonruter]

@PatelUtkarsh isn't that handled by the building up of the $postmeta_rows array above? It checks if it is not single, and of not, it iterates over each of the meta values to then add as separate rows here.

• One deficiency I do notice, however, is that it needs to maybe_serialize().

[PatelUtkarsh]

@westonruter oh my bad I didn't declare it single => false

[westonruter]

@PatelUtkarsh so you could integrate with the project by adding $single = false to the Customize_Postmeta_Multi_Setting class and it would then “just work”, right?

[PatelUtkarsh]

@westonruter I passed it in Customize_Postmeta_Multi_Setting 's constructor $args to make it work as $single property will be initialized in the constructor call of WP_Customize_Postmeta_Setting.

[westonruter]

@PatelUtkarsh that will work too.

I'm trying to figure out if it makes more sense for the customize_sanitize_{$this->id} filter to apply on each individual multii-postmeta value separately (as it is doing in this PR now), or if the array of values should be all passed into the applied filter once. If applied individually to each multi-value then it would allow the same callback to be used for single and non-single postmeta.

[PatelUtkarsh]

@westonruter I can not think of a use-case where I would need all multi-post meta values together for the filter. Maybe to limit the multi-meta or removing duplication but that can be handled by control.

Edit: Ordering of multiple-meta? Sync post meta code does not preserve order.

[westonruter]

• Skip exporting customized posts data into the query if it doesn't have a matching post_type queried.

The above would require re-deriving the post types being queried if $wp_query->get('post_type') is empty according to:

• https://github.com/xwp/wordpress-develop/blob/1a0effca1838b6d8e87ac74d04886567c198e946/src/wp-includes/class-wp-query.php#L1728-L1734
• https://github.com/xwp/wordpress-develop/blob/1a0effca1838b6d8e87ac74d04886567c198e946/src/wp-includes/class-wp-query.php#L1920
• https://github.com/xwp/wordpress-develop/blob/1a0effca1838b6d8e87ac74d04886567c198e946/src/wp-includes/class-wp-query.php#L1996-L2009
• https://github.com/xwp/wordpress-develop/blob/1a0effca1838b6d8e87ac74d04886567c198e946/src/wp-includes/class-wp-query.php#L2239-L2260

[westonruter]

Comparing some queries with and sans the customized data injected: https://gist.github.com/westonruter/36563b2356a7a3c891f178176fc99b3a

[westonruter]

@PatelUtkarsh let me know when you're confident this can be merged.

[PatelUtkarsh]

@westonruter Should I update the code for preserve an order of plural postmeta?

[westonruter]

@PatelUtkarsh I'm leading towards no. It's current behavior for the order to not be stable in the entities plugin, right? As such, making the order stable would be an enhancement. But if you think otherwise, please do amend the PR with persistent ordering.

[valendesigns]

@westonruter Are you suggesting the order in the Select2 is an enhancement?

[westonruter]

@valendesigns this is about the order in which the plural postmeta are written into the database, whether existing postmeta which are unchanged should be deleted so that they can be reinserted with a meta_id that increments correspondingly to the order in the plural meta. The non-singlular postmeta code in this PR is replicated from the plural-postmeta class in the entities plugin that @PatelUtkarsh wrote previously. So this PR wouldn't change that existing behavior.

[westonruter]

@PatelUtkarsh please connect with @sayedwp and @miina as the ordering of the plural postmeta may indeed be what is affecting the ordering of repeater controls. If so, then we should simplify the update logic to delete all postmeta for a given key, and then re-add each value for the plural meta to ensure that the meta_id is auto-incrementing and preserves the order of the meta that were originally saved.

[PatelUtkarsh]

@westonruter There is no such need for preserving order right now, Even in repeater control we don't need the order of plural post-meta as we are storing it in serialize for ordering and grouping(because grouping is difficult with plural post-meta).

If any special case arises we can handle it by overriding update method as you mentioned.