Registration is now based solely on object type, which allows the code around this to be simplified significantly.
In the process of making this adjustment:
* `register_meta()`, `unregister_meta_key()`, `get_registered_metadata()`, and `registered_meta_key_exists()` no longer return `WP_Error` objects.
* The recently introduced `wp_object_type_exists()` function and the restriction on object type has been removed.
Note: No guarantee of uniqueness is made across object subtypes. Registered meta keys should be uniquely prefixed to avoid conflict.
Fixes#35658.
Built from https://develop.svn.wordpress.org/trunk@38095
git-svn-id: http://core.svn.wordpress.org/trunk@38036 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When using `register_meta()` with the function signature from 4.5 and earlier, the `auth_{$type}_meta_{$key}` and `sanitize_{$type}_meta_{$key}` filters are used. Any calls to `register_meta()` expecting this behavior should continue to work. The new filters, which take advantage of object subtypes, should not be added unless the proper `$args` array is passed.
See #35658.
Built from https://develop.svn.wordpress.org/trunk@38041
git-svn-id: http://core.svn.wordpress.org/trunk@37982 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If auth and/or sanitize callbacks are specified in the arguments for
`register_meta()`, filters are added to handle these callbacks. These
should be removed when calling `unregister_meta_key()` to avoid
unintentional filtering.
See #35658.
Built from https://develop.svn.wordpress.org/trunk@38040
git-svn-id: http://core.svn.wordpress.org/trunk@37981 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In doing this, non-core object types are no longer forcibly blocked and are instead checked against `wp_object_type_exists()` which has a filterable return value. Still, filter that at your own risk.
props Faison for the initial patch.
see 35658.
Built from https://develop.svn.wordpress.org/trunk@37991
git-svn-id: http://core.svn.wordpress.org/trunk@37932 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`register_meta()` has been altered to accept an array of arguments as the third parameter in order to support its usage beyond XML-RPC, notably in the REST API and other projects that may build on top of meta, such as a potential Fields API. Arguments are whitelisted to reserve the right for core to add more later.
New functions added to complement this expansion are:
* `registered_meta_key_exists()`
* `unregister_meta_key()`
* `get_registered_meta_keys()`
* `get_registered_metadata()`
* A "private" function for the aforementioned whitelisting.
There still need to be lots of tests written for previous and new behaviors, and many things are subject to change. Maybe things will explode. #yolo
props jeremyfelt, ericlewis, sc0ttkclark, helen, rmccue, ocean90, voldemortensen.
see #35658.
Built from https://develop.svn.wordpress.org/trunk@37924
git-svn-id: http://core.svn.wordpress.org/trunk@37865 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Comment and term meta lazyloading for `WP_Query` loops, introduced in 4.4,
depended on filter callback methods belonging to `WP_Query` objects. This meant
storing `WP_Query` objects in the `$wp_filter` global (via `add_filter()`),
requiring that PHP retain the objects in memory, even when the local variables
would typically be expunged during normal garbage collection. In cases where a
large number of `WP_Query` objects were instantiated on a single pageload,
and/or where the contents of the `WP_Query` objects were quite large, serious
performance issues could result.
We skirt this problem by moving metadata lazyloading out of `WP_Query`. The
new `WP_Metadata_Lazyloader` class acts as a lazyload queue. Query instances
register items whose metadata should be lazyloaded - such as post terms, or
comments - and a `WP_Metadata_Lazyloader` method will intercept comment and
term meta requests to perform the cache priming. Since `WP_Metadata_Lazyloader`
instances are far smaller than `WP_Query` (containing only object IDs), and
clean up after themselves far better than the previous `WP_Query` methods (bp
only running their callbacks a single time for a given set of queued objects),
the resource use is decreased dramatically.
See [36525] for an earlier step in this direction.
Props lpawlik, stevegrunwell, boonebgorges.
Fixes#35816.
Built from https://develop.svn.wordpress.org/trunk@36566
git-svn-id: http://core.svn.wordpress.org/trunk@36533 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `$delete_all` flag in `delete_metadata()` triggers cache invalidation for
multiple objects. Previously, invalidation took place for all objects matching
the `$meta_key` parameter, regardless of whether `$meta_value` was also set.
This resulted in overly aggressive invalidation.
Props rahal.aboulfeth.
Fixes#35797.
Built from https://develop.svn.wordpress.org/trunk@36511
git-svn-id: http://core.svn.wordpress.org/trunk@36478 1a063a9b-81f0-0310-95a4-ce76da25c4cd
A meta_query containing an `OR` relation can result in the same record matching
multiple clauses, leading to duplicate results. The previous prevention against
duplicates [18178] #17582 became unreliable in 4.1 when `WP_Meta_Query`
introduced support for nested clauses. The current changeset adds a new method
`WP_Meta_Query::has_or_relation()` for checking whether an `OR` relation
appears anywhere in the query, and uses the new method in `WP_User_Query` to
enforce distinct results as necessary.
Props maxxsnake.
Fixes#32592.
Built from https://develop.svn.wordpress.org/trunk@32713
git-svn-id: http://core.svn.wordpress.org/trunk@32683 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The implementation of `meta_query` orderby introduced in [31312] put clause
identifiers into a 'name' parameter of the clause. For greater clarity, this
changeset updates the syntax to use the associative array key used when
defining `meta_query` parameters, instead of the 'name' parameter.
Props Funkatronic, DrewAPicture.
Fixes#31045.
Built from https://develop.svn.wordpress.org/trunk@31340
git-svn-id: http://core.svn.wordpress.org/trunk@31321 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Meta_Query` clauses now support a 'name' parameter. When building a
`WP_Query` object, the value of 'orderby' can reference this 'name', so that
it's possible to order by any clause in a meta_query, not just the first one
(as when using 'orderby=meta_value'). This improvement also makes it possible
to order by multiple meta query clauses (or by any other eligible field plus
a meta query clause), using the array syntax for 'orderby' introduced in [29027].
Props Funkatronic, boonebgorges.
Fixes#31045.
Built from https://develop.svn.wordpress.org/trunk@31312
git-svn-id: http://core.svn.wordpress.org/trunk@31293 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It's necessary for hook docs to directly precede hook lines so the parser can correctly match them up. This change relocates hook docs for `update_{$meta_type}_meta`, `update_postmeta`, `updated_{$meta_type}_meta`, and `updated_postmeta`.
Fixes#11683.
Built from https://develop.svn.wordpress.org/trunk@30149
git-svn-id: http://core.svn.wordpress.org/trunk@30149 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Per our inline documentation standards, no further use of the `@uses` tag is recommended as used and used-by relationships can be derived through other means. This removes most uses of the tag in core documentation, with remaining tags to be converted to `@global` or `@see` as they apply.
Fixes#30191.
Built from https://develop.svn.wordpress.org/trunk@30105
git-svn-id: http://core.svn.wordpress.org/trunk@30105 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Passing orderby=meta_value and meta_key=foo to WP_Query should require that
each matched post have a meta value with the key 'foo'. To make this
requirement compatible with meta_query params that have the relation OR, we
nest the meta_query param, and join it using AND to a meta_query clause
generated from the meta_key/meta_compare/meta_type query vars.
Fixes#25538.
Built from https://develop.svn.wordpress.org/trunk@29964
git-svn-id: http://core.svn.wordpress.org/trunk@29711 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The logic used to generate clause SQL in `WP_Meta_Query` is somewhat arcane,
stemming mostly from an ongoing effort to eliminate costly table joins when
they are not necessary. By systematizing the process of looking for shareable
joins - as was done in `WP_Tax_Query` [29902] - it becomes possible to simplify
the construction of SQL queries in `get_sql_for_clause()`. Moreover, the
simplified logic is actually considerably better at identifying shareable
joins, such that certain uses of `WP_Meta_Query` will see joins reduced by 50%
or more.
Includes integration tests for a representative cross-section of the query
clause combinations that result in shared table aliases.
Props boonebgorges, sc0ttkclark.
See #24093.
Built from https://develop.svn.wordpress.org/trunk@29940
git-svn-id: http://core.svn.wordpress.org/trunk@29691 1a063a9b-81f0-0310-95a4-ce76da25c4cd
