Previously, `wp_favicon_request()` was introduced in [13205] to avoid a performance hit of serving a full 404 page on every favicon request.
While working as intended, that implementation did not provide a way for theme or plugin authors to manage the behavior of favicon requests.
This changeset implements the following logic (only applied if WordPress is installed in the root directory):
* If there is a Site Icon set in Customizer, redirect `/favicon.ico` requests to that icon.
* Otherwise, use the WordPress logo as a default icon.
* If a physical `/favicon.ico` file exists, do nothing, let the server handle the request.
Handling `/favicon.ico` is now more consistent with handling `/robots.txt` requests.
New functions and hooks:
* Introduce `is_favicon()` conditional tag to complement `is_robots()`.
* Introduce `do_favicon` action to complement `do_robots` and use it in template loader.
* Introduce `do_favicon()` function, hooked to the above action by default, to complement `do_robots()`.
* Introduce `do_faviconico` action to complement `do_robotstxt`, for plugins to override the default behavior.
* Mark `wp_favicon_request()` as deprecated in favor of `do_favicon()`.
Props jonoaldersonwp, birgire, joostdevalk, mukesh27, SergeyBiryukov.
Fixes#47398.
Built from https://develop.svn.wordpress.org/trunk@47018
git-svn-id: http://core.svn.wordpress.org/trunk@46818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Add missing translator comments.
* Fix placement of some translator comments. Translator comments should be on the line directly above the line containing the translation function call for optimal compatibility with various `.pot` file generation tools. The CS auto-fixing, which changed some inconsistent function calls to multi-line function calls, is part of the reason why this was no longer the case for a select group of translator comments.
Includes minor code layout fixes.
Polyglots, rejoice! All WordPress core files now have translator comments for all strings with placeholders!
Props jrf, subrataemfluence, GaryJ, webdados, Dency, swissspidy, alvarogois, marcomartins, mihaiiceyro, vladwtz, niq1982, flipkeijzer, michielatyoast, chandrapatel, thrijith, joshuanoyce, FesoVik, tessak22, bhaktirajdev, cleancoded, dhavalkasvala, garrett-eclipse, bibliofille, socalchristina, priyankkpatel, 5hel2l2y, adamsilverstein, JeffPaul, pierlo, SergeyBiryukov.
Fixes#44360.
Built from https://develop.svn.wordpress.org/trunk@45926
git-svn-id: http://core.svn.wordpress.org/trunk@45737 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces `$post` parameters to `get_the_content()` and
`wp_trim_excerpt()`. When a `$post` object is passed to one of these functions,
the functions will operate on the data from that object, rather than from the
post globals (`$authordata`, `$page`, etc). This ensures that the functions work
in a predictable manner when used outside of the regular post loop.
The global-mismatch problem is surfaced in cases where `get_the_excerpt()` is
called outside of the post loop, on posts that don't have a defined excerpt. In
these cases, the post globals - used to generate a fallback excerpt - may refer
to the incorrect object, resulting in PHP notices or other unpredictable
behavior. See #36934 for a related issue.
Props spacedmonkey, kraftbj, Shital Patel.
Fixes#42814.
Built from https://develop.svn.wordpress.org/trunk@44941
git-svn-id: http://core.svn.wordpress.org/trunk@44772 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
