Returning a non-null value from the new `posts_pre_query` filter will cause
`WP_Query` to skip its database query, so that posts data can be provided from
elsewhere. This is useful in cases where post data may be mirrored in a
separate location, such as an external search application.
Developers should note that the `WP_Query` properties generally used to
calculate pagination - specifically, `found_posts` and `max_num_pages`, which
are determined by default in `set_found_posts()` - must be provided explicitly
when using the `posts_pre_query` filter; since `WP_Query` will not be
contacting the database, it will have no access to `SELECT FOUND_ROWS()`.
The `WP_Query` instance is passed to `posts_pre_query` by reference, so that
these properties can be set manually if needed.
Props jpdavoutian, tlovett1.
Fixes#36687.
Built from https://develop.svn.wordpress.org/trunk@37692
git-svn-id: http://core.svn.wordpress.org/trunk@37658 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The process of lazy-loading can be resource intensive for object that have
terms in large numbers of taxonomies and are running a persistent object cache.
This new parameter allows the feature to be disabled in these cases.
Props DBrumbaugh10Up.
See #36953.
Built from https://develop.svn.wordpress.org/trunk@37589
git-svn-id: http://core.svn.wordpress.org/trunk@37557 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also use 'back-compat' in some inline comments where backward compatibility is the subject and shorthand feels more natural.
Note: 'backwards compatibility/compatibile' can also be considered correct, though it's primary seen in regular use in British English.
Props ocean90.
Fixes#36835.
Built from https://develop.svn.wordpress.org/trunk@37431
git-svn-id: http://core.svn.wordpress.org/trunk@37397 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
Built from https://develop.svn.wordpress.org/trunk@37342
git-svn-id: http://core.svn.wordpress.org/trunk@37308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Query` discards most non-array date values ('year', 'monthnum', etc) by
casting to integer. Since [25138], the 'm' parameter has been handled
as a string; see #24884. However, the string-handling introduced in [25138]
blindly attempted to handle arrays and other non-scalar types as strings,
resulting in PHP notices and invalid MySQL syntax.
Props vortfu.
Fixes#36718.
Built from https://develop.svn.wordpress.org/trunk@37324
git-svn-id: http://core.svn.wordpress.org/trunk@37290 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This reverts part of [34659] due to excessive canonical problems it's caused in 4.4.x.
Remove the unit tests which are no longer supported.
This also removes the `is_feed()` code to avoid confusion - only pages & embeds will be redirected.
Merges [36280] and [36281] to trunk.
Props dd32.
See #21602, #35344.
Built from https://develop.svn.wordpress.org/trunk@37075
git-svn-id: http://core.svn.wordpress.org/trunk@37042 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Query` allows random ordering; `'orderby' => 'rand'` translates to
`ORDER BY RAND()`. This syntax results in random ordering that is not
consistent from request to request. MySQL supports the passing of a seed value
to random sorts, such as `ORDER BY RAND(3)`, which will return the same
random value each time it's called. `WP_Query` now supports this syntax, by
passing `RAND(3)` (or whatever integer seed value you'd like) as the value
of `'orderby'`.
Props hlashbrooke.
Fixes#35692.
Built from https://develop.svn.wordpress.org/trunk@36632
git-svn-id: http://core.svn.wordpress.org/trunk@36599 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Another chapter in the Storied Annals of Weird `in_array()` Behavior:
`in_array( 4, array( "4-cool-dudes" ) );` resolves to `true`, such that
`is_page( 4 )` was returning true for posts with the name `'4-cool-dudes'`.
We work around this behavior by ensuring that values passed to the `is_`
methods are cast to strings before the `in_array()` checks. ID checks still
work as expected; see #24674.
Props mikejolley, swissspidy, boonebgorges.
Fixes#35902.
Built from https://develop.svn.wordpress.org/trunk@36625
git-svn-id: http://core.svn.wordpress.org/trunk@36592 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
Lazyloading for comment meta and term meta, introduced into `WP_Query` in
4.4, used flags - `updated_term_meta_cache` and `updated_comment_meta_cache` -
in an attempt to prevent cache priming from happening more than once per query
object. This technique was mostly effective, but not entirely efficient, since
the flag didn't prevent the `lazyload_*_meta` callbacks from running. The
obvious solution - removing the filter callback after it'd be run once - was
dismissed for 4.4 because of concerns that `remove_filter()` could disable
lazyloading too generally in the context of nested queries, due to the way
`_wp_filter_build_unique_id()` doesn't always build sufficiently unique IDs for
similar objects. However, further testing shows that this concern is only valid
in a very small subset of cases, while the cost of keeping the query objects in
memory, via the `$wp_filter` global, is quite significant. As such, this
changeset removes the flags in favor of the `remove_filter()` technique.
See #35454, #35816.
Built from https://develop.svn.wordpress.org/trunk@36524
git-svn-id: http://core.svn.wordpress.org/trunk@36491 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This provides better parity with `get_queried_object()`, which will return the
first taxonomy/term matched by the current query.
[29891] introduced the abnormal behavior for the 'taxonomy' and 'term'
query vars.
Props Chouby.
Fixes#35619.
Built from https://develop.svn.wordpress.org/trunk@36484
git-svn-id: http://core.svn.wordpress.org/trunk@36451 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The introduction of negative search terms in 4.4 [34934] introduced the
possibility that the ORDER BY clause of a search query could be assembled in
such a way as to create invalid syntax. The current changeset fixes this by
ensuring that the ORDER BY clause corresponding to the search terms is
excluded when it would otherwise be empty.
Props salvoaranzulla.
Fixes#35361.
Built from https://develop.svn.wordpress.org/trunk@36251
git-svn-id: http://core.svn.wordpress.org/trunk@36218 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After [34659], it became possible to cause an incorrect redirect, by changing the slug of a post, then creating a new post with the old slug. The correct behaviour is to prevent redirecting to the old post.
Props dd32, pento.
Fixes#35031 for trunk.
Built from https://develop.svn.wordpress.org/trunk@36128
git-svn-id: http://core.svn.wordpress.org/trunk@36094 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Twelve years later, after no fewer than three themes have intentionally implemented popup comments in their functionality, before being abandoned for at least the last six years, we've reached a time where we can put this era behind us. A time when we can remove comment popup functionality from WordPress.
If this breaks the internet, I'll eat my hat.
Fixes#28617
Built from https://develop.svn.wordpress.org/trunk@35848
git-svn-id: http://core.svn.wordpress.org/trunk@35812 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Pass a keyword with a leading hyphen to exclude posts containing that keyword.
For example, 'taco -onions' will return posts that contain the word 'taco' but
do not contain the word 'onions'.
Props akibjorklund.
Fixes#33988.
Built from https://develop.svn.wordpress.org/trunk@34934
git-svn-id: http://core.svn.wordpress.org/trunk@34899 1a063a9b-81f0-0310-95a4-ce76da25c4cd
For the past 6 years, WordPress has operated as an oEmbed consumer, allowing users to easily embed content from other sites. By adding oEmbed provider support, this allows any oEmbed consumer to embed posts from WordPress sites.
In addition to creating an oEmbed provider, WordPress' oEmbed consumer code has been enhanced to work with any site that provides oEmbed data (as long as it matches some strict security rules), and provides a preview from within the post editor.
For security, embeds appear within a sandboxed iframe - the iframe content is a template that can be styled or replaced entirely by the theme on the provider site.
Props swissspidy, pento, melchoyce, netweb, pfefferle, johnbillion, extendwings, davidbinda, danielbachhuber, SergeyBiryukov, afercia
Fixes#32522.
Built from https://develop.svn.wordpress.org/trunk@34903
git-svn-id: http://core.svn.wordpress.org/trunk@34868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
