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
`compare_key`, introduced in #42409, previously supported only `=` and `LIKE`
operators. This changeset introduces a number of other operators: `!=`, `IN`,
`NOT IN`, `NOT LIKE`, `RLIKE`, `REGEXP`, `NOT REGEXP`, `EXISTS`, and `NOT EXISTS`
(the latter two aliased to `=` and `!=`, respectively). To support case-sensitive
regular expression key comparisons, the new `type_key` parameter will force
a MySQL `CAST` when 'BINARY' is passed.
Props soulseekah.
Fixes#43346.
Built from https://develop.svn.wordpress.org/trunk@46188
git-svn-id: http://core.svn.wordpress.org/trunk@46000 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
Ordering by `post__in` was introduced in [21776], but the code assumed that
`post__in` would be a comma-separated string listing post IDs. When an array
of post IDs was passed to the `post__in` query var, 'orderby=post__in' was
not respected. This changeset changes this behavior by handling
'orderby=post__in' in the same way as most other values of 'orderby',
which ensures that arrays as well as strings can be properly parsed.
The same treatment is given to the similar `post_name__in` and
`post_parent__in` options of 'orderby', so that most query generation for
orderby clauses happens in the same place, instead of in special cases.
A slight change in the resulting SQL (related to the whitespace around
parentheses and commas) necessitates a change to an existing REST API test
that does a string comparison against the SQL query.
Props mgibbs189, kelvink.
Fixes#38034.
Built from https://develop.svn.wordpress.org/trunk@44452
git-svn-id: http://core.svn.wordpress.org/trunk@44283 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`WP_Query::setup_postdata()` splits the post up by `<!--nextpage-->`, which causes invalid block data to be contained in the post content.
This change removes the `<!-- wp:nextpage -->` and `<!-- /wp:nextpage -->`, as well.
Props pento, youknowriad, azaozz, noisysocks.
Merges [43940] into trunk.
See #45401.
Built from https://develop.svn.wordpress.org/trunk@44276
git-svn-id: http://core.svn.wordpress.org/trunk@44106 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
The new `compare_key=LIKE` parameter works in conjunction with `key` in a
similar way to the `compare=LIKE` and `value`: by doing a "compares" `LIKE`
query. This allows developers to do partial matches against keys when
doing meta queries.
Props mariovalney, chasewg.
Fixes#42409.
Built from https://develop.svn.wordpress.org/trunk@42768
git-svn-id: http://core.svn.wordpress.org/trunk@42598 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42228
git-svn-id: http://core.svn.wordpress.org/trunk@42057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to about 2013, many class methods lacked even access modifiers which made the `@access` notations that much more useful. Now that we've gotten to a point where the codebase is more mature from a maintenance perspective and we can finally remove these notations. Notable exceptions to this change include standalone functions notated as private as well as some classes still considered to represent "private" APIs.
See #41452.
Built from https://develop.svn.wordpress.org/trunk@41162
git-svn-id: http://core.svn.wordpress.org/trunk@41002 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This parameter allows querying for posts with a specific value of
`comment_count`. It is also possible to query for posts that match
a `comment_count` comparison by passing an array with 'value' and
'compare' operators (eg `array( 'compare' => '>', 'value' => 5 )`).
Props ramon fincken.
Fixes#28399.
Built from https://develop.svn.wordpress.org/trunk@40978
git-svn-id: http://core.svn.wordpress.org/trunk@40828 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[38792] allowed `WP_Query`'s hyphen-as-exclusion-prefix feature to be
disabled via filter. A more general solution is to allow the prefix to
be filtered; returning an empty value from a filter callback works to
disable the feature.
Props dlh.
Fixes#38099.
Built from https://develop.svn.wordpress.org/trunk@38844
git-svn-id: http://core.svn.wordpress.org/trunk@38787 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WordPress 4.4 introduced "hyphen exclusion" for search terms, so that
"foo -bar" would return posts containing "foo" AND not containing "bar".
The new filter 'wp_query_use_hyphen_for_exclusion' allows developers
to disable this feature when it's known that their content will contain
semantically important leading hyphens.
Props chriseverson, choongsavvii.
Fixes#38099.
Built from https://develop.svn.wordpress.org/trunk@38792
git-svn-id: http://core.svn.wordpress.org/trunk@38735 1a063a9b-81f0-0310-95a4-ce76da25c4cd
