WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`wp_check_for_changed_dates()`, `_find_post_by_old_slug(), `_find_post_by_old_date()`, and the `old_slug_redirect_post_id` filter were intended to land in 4.9.2, but didn't quite make it. Instead, they'll be landing in 4.9.3.
See #15397.
Built from https://develop.svn.wordpress.org/trunk@42588
git-svn-id: http://core.svn.wordpress.org/trunk@42417 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When a post slug is changed, we store a copy of the old slug, so that we can redirect visitors visiting the old URL to the new URL.
In the same way, this stores a copy of the old date, when the post date changes, so we can redirect visitors to the new URL.
Props nickmomrik.
Fixes#15397 for trunk.
Built from https://develop.svn.wordpress.org/trunk@42401
git-svn-id: http://core.svn.wordpress.org/trunk@42230 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
