The logic for sending the `X-Pingback` header for single posts that allow pings was recently moved from `WP::handle_404()` to a more appropriate place in `WP::send_headers()`.
To check whether pings are open for a particular post, that logic relies on the `$wp_query` global, which is declared in `WP::handle_404()`, but not in `WP::send_headers()`
This commit ensures that `$wp_query` is globalized in `WP::send_headers()` too, so that the check works as expected.
Follow-up to [54250].
Props strategio, sabernhardt, dlh, davidbaumwald, SergeyBiryukov.
Fixes#56840.
Built from https://develop.svn.wordpress.org/trunk@54636
git-svn-id: http://core.svn.wordpress.org/trunk@54188 1a063a9b-81f0-0310-95a4-ce76da25c4cd
By running `WP::send_headers()` after posts have been queried, we can ensure that conditional tags like `is_front_page()`, `is_home()`, etc. work as expected.
This provides better context and more flexibility when adjusting HTTP headers via the `wp_headers` filter or `send_headers` action.
Previously, the earliest action where conditional tags worked correctly was `wp`.
Includes moving the `X-Pingback` header, previously sent in `WP::handle_404()` after posts have been queried, to a more appropriate place in `WP::send_headers()`.
Follow-up to [2627], [34442].
Props jonoaldersonwp, joostdevalk, peterwilsoncc, adamsilverstein, SergeyBiryukov.
Fixes#56068.
Built from https://develop.svn.wordpress.org/trunk@54250
git-svn-id: http://core.svn.wordpress.org/trunk@53809 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
There are a number of ways to mitigate this:
* If it is an accidental typo for a declared property: fix the typo.
* For known properties: declare them on the class.
* For unknown properties: add the magic `__get()`, `__set()`, et al. methods to the class or let the class extend `stdClass` which has highly optimized versions of these magic methods built in.
* For unknown ''use'' of dynamic properties, the `#[AllowDynamicProperties]` attribute can be added to the class. The attribute will automatically be inherited by child classes.
Trac ticket #56034 is open to investigate and handle the third and fourth type of situations, however it has become clear this will need more time and will not be ready in time for WP 6.1.
To reduce “noise” in the meantime, both in the error logs of WP users moving onto PHP 8.2, in the test run logs of WP itself, in test runs of plugins and themes, as well as to prevent duplicate tickets from being opened for the same issue, this commit adds the `#[AllowDynamicProperties]` attribute to all “parent” classes in WP.
The logic used for this commit is as follows:
* If a class already has the attribute: no action needed.
* If a class does not `extend`: add the attribute.
* If a class does `extend`:
- If it extends `stdClass`: no action needed (as `stdClass` supports dynamic properties).
- If it extends a PHP native class: add the attribute.
- If it extends a class from one of WP's external dependencies: add the attribute.
* In all other cases: no action — the attribute should not be needed as child classes inherit from the parent.
Whether or not a class contains magic methods has not been taken into account, as a review of the currently existing magic methods has shown that those are generally not sturdy enough and often even set dynamic properties (which they should not). See the [https://www.youtube.com/watch?v=vDZWepDQQVE live stream from August 16, 2022] for more details.
This commit only affects classes in the `src` directory of WordPress core.
* Tests should not get this attribute, but should be fixed to not use dynamic properties instead. Patches for this are already being committed under ticket #56033.
* While a number bundled themes (2014, 2019, 2020, 2021) contain classes, they are not a part of this commit and may be updated separately.
Reference: [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties].
Follow-up to [53922].
Props jrf, hellofromTonya, markjaquith, peterwilsoncc, costdev, knutsp, aristath.
See #56513, #56034.
Built from https://develop.svn.wordpress.org/trunk@54133
git-svn-id: http://core.svn.wordpress.org/trunk@53692 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the `Last-Modified` header of comments feed was using the date/time of the last comment. This behavior was breaking caching and causing feed readers to believe there is no new content even when there might be new posts.
This commit changes this behavior to use the newest date from both `get_lastcommentmodified()` and `get_lastpostmodified()` functions instead of only using the result from `get_lastcommentmodified()`.
Props xiven, mauteri, costdev, audrasjb.
Fixes#47968.
Built from https://develop.svn.wordpress.org/trunk@53233
git-svn-id: http://core.svn.wordpress.org/trunk@52822 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Developers of plugins and themes can use the `do_parse_request` filter to hot-wire requests and hook in early to render custom pages. However, even through these request may not need post queries and 404 lookups to be run, they run anyway. This can results in unnecessary SQL queries running on these requests. By adding a return value to the `parse_request` method of the `WP` class, these queries can now be skipped.
Props junsuijin, ryan, westi, sivel, dd32, wonderboymusic, arnee, tyxla, DrewAPicture, lukecavanagh, SergeyBiryukov, davidbaumwald, Spacedmonkey, pbearne.
Fixes#10886.
Built from https://develop.svn.wordpress.org/trunk@52814
git-svn-id: http://core.svn.wordpress.org/trunk@52403 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids an `array_keys() expects parameter 1 to be array, null given` PHP warning for the `query_vars` property in `WP::build_query_string()` when disabling request parsing via the `do_parse_request` filter.
Props dd32, SergeyBiryukov.
Fixes#55222.
Built from https://develop.svn.wordpress.org/trunk@52804
git-svn-id: http://core.svn.wordpress.org/trunk@52393 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As per the PHP manual:
> If the `component` parameter is omitted, an associative array is returned.
> If the `component` parameter is specified, `parse_url()` returns a string (or an int, in the case of `PHP_URL_PORT`) instead of an array. If the requested component doesn't exist within the given URL, `null` will be returned.
Reference: [https://www.php.net/manual/en/function.parse-url.php#refsect1-function.parse-url-returnvalues PHP Manual: parse_url(): Return Values]
In this case, `parse_url()` is called with the `PHP_URL_PATH` as `$component`. This will return `null` in the majority of cases, as – exсept for subdirectory-based sites – `home_url()` returns a URL without the trailing slash, like `http://example.org`.
The return value of `parse_url()` was subsequently passed to `trim()`, leading to a `trim(): Passing null to parameter #1 ($string) of type string is deprecated` notice on PHP 8.1.
Fixed by adjusting the logic flow to:
* Only pass the return value of `parse_url()` to follow-on functions if it makes sense, i.e. if it isn't `null`, nor an empty string.
* Preventing calls to `preg_replace()` and `trim()` further down in the function logic flow, when `preg_replace()`/`trim()` would have nothing to do anyhow.
Follow-up to [25617].
Props jrf, hellofromTonya, SergeyBiryukov.
See #53635.
Built from https://develop.svn.wordpress.org/trunk@51622
git-svn-id: http://core.svn.wordpress.org/trunk@51228 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This extension is necessary because the comment approval notification opt-in form introduced in [47887] uses the same mechanism, and the previous limit of one minute meant that users on a slow connection, using assistive technology, with limited motor skills, or who are generally indecisive may not complete the opt-in action within one minute, and therefore not see the confirmation message.
Props joedolson, imath, hellofromTonya, peterwilsoncc, alexstine, davidbaumwald
Fixes#52406
Built from https://develop.svn.wordpress.org/trunk@50271
git-svn-id: http://core.svn.wordpress.org/trunk@49916 1a063a9b-81f0-0310-95a4-ce76da25c4cd
“The WordPress open source community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included.”
With this commit, all occurrences of “whitelist” and “blacklist” (with the single exception of the `$new_whitelist_options` global variable) are removed. A new ticket has been opened to explore renaming the `$new_whitelist_options` variable (#50434).
Changing to more specific names or rewording sentences containing these terms not only makes the code more inclusive, but also helps provide clarity. These terms are often ambiguous. What is being blocked or allowed is not always immediately clear. This can make it more difficult for non-native English speakers to read through the codebase.
Words matter. If one contributor feels more welcome because these terms are removed, this was worth the effort.
Props strangerstudios, jorbin, desrosj, joemcgill, timothyblynjacobs, ocean90, ayeshrajans, davidbaumwald, earnjam.
See #48900, #50434.
Fixes#50413.
Built from https://develop.svn.wordpress.org/trunk@48121
git-svn-id: http://core.svn.wordpress.org/trunk@47890 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids displaying duplicate content of the home page under different URLs with appended page numbers.
This change only affects the `<!--nextpage-->` pagination (`page` query variable) and not the regular multiple posts pagination (`paged` query variable).
The posts page does not support the `<!--nextpage-->` pagination, so requests for invalid page numbers should be redirected to the page permalink, applying the logic previously implemented for single posts or pages.
Follow-up to [34492], [47727].
Props jeremyfelt, sachit.tandukar, SergeyBiryukov.
Fixes#45337. See #40773, #28081, #11694.
Built from https://develop.svn.wordpress.org/trunk@47760
git-svn-id: http://core.svn.wordpress.org/trunk@47536 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids displaying duplicate content of the same post under different URLs and ensures the canonical URL is correct.
Previously, requests for invalid page numbers were only redirected to the post permalink if the post was actually paginated using the `<!--nextpage-->` marker.
Follow-up to [34492].
Props jeremyfelt, prografika, sachit.tandukar, subrataemfluence, hronak, ekatherine, henry.wright, chesio, dd32, SergeyBiryukov.
Fixes#40773. See #45337, #28081, #11694.
Built from https://develop.svn.wordpress.org/trunk@47727
git-svn-id: http://core.svn.wordpress.org/trunk@47504 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
Noteable changes:
- The `magic_quotes_runtime` and `magic_quotes_sybase` settings were removed in PHP 5.4, so no longer need to be set.
- Some functions that use external libraries can generate errors that can't be tested for, so are globally allowed to silence errors.
- Quite a few functions would cause errors if `safe_mode` was set. This setting was removed in PHP 5.4.
- Only a handful of `header()` calls needed corresponding `headers_sent()` checks for unit tests to pass, but more may need to be added as the nightlies builds are tested.
See #46732.
Built from https://develop.svn.wordpress.org/trunk@45611
git-svn-id: http://core.svn.wordpress.org/trunk@45422 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Use of `date()` in core depends on PHP timezone set to UTC and not changed by third party code (which cannot be guaranteed).
`gmdate()` is functionally equivalent, but is not affected by PHP timezone setting: it's always UTC, which is the exact behavior the core needs.
Props nielsdeblaauw, Rarst.
Fixes#46438. See #44491.
Built from https://develop.svn.wordpress.org/trunk@45424
git-svn-id: http://core.svn.wordpress.org/trunk@45235 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
Fixes bug where an invalid Last-Modified value would be returned in feed requests for sites that had 0 items to return. Comment or post feeds will now return the current timestamp as the Last-Modified header value. Example: a request for the comments feed for a site without any comments.
Replaced use of the local static variable `$cache_lastcommentmodified` to store the modified date in `get_lastcommentmodified()` with the Object Cache API. The `get_lastcommentmodified()` function returns early if there is a cached value and returns `false` if there where no comments found. Introduced `_clear_modified_cache_on_transition_comment_status()` to flush the `lastcommentmodified` cache key when a comment enters or leaves approval status. In `get_lastpostmodified()` return early if there is a cached value and return `false` if there are no posts found.
Props swissspidy, rachelbaker, dllh, leobaiano.
Fixes#38027.
Built from https://develop.svn.wordpress.org/trunk@38925
git-svn-id: http://core.svn.wordpress.org/trunk@38868 1a063a9b-81f0-0310-95a4-ce76da25c4cd
It is possible to delegate pingback processing to a service function outside of WordPress itself. All other calls in default themes (and likely other themes) uses `bloginfo` which automatically adds the filter argument of "display". This adds consistency.
Props dshanske.
Fixes#34633.
Built from https://develop.svn.wordpress.org/trunk@38671
git-svn-id: http://core.svn.wordpress.org/trunk@38614 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This private query var allows the hierarchical page query on the Pages listing screen to query for `wp_posts.ID, wp_posts.post_parent` instead of `wp_posts.*`. This introduces large memory and time savings when the site contains a large number of Pages. Combined with the processing time savings introduced in [31730] this makes the Pages listing screen considerably more performant.
Fixes#34982
Props rodrigosprimo
Built from https://develop.svn.wordpress.org/trunk@38451
git-svn-id: http://core.svn.wordpress.org/trunk@38392 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The rewrite rule matching code in WP::parse_request() used an unclear variable `$request` to represent the requested path (e.g. "2016/05/03") as well as a deceptively named variable `$request_uri`, which actually represents the requested file when an install used PATHINFO links.
Those variables are replaced with `$requested_path` and `$requested_file` respectively for clarity.
Fixes#36674.
Built from https://develop.svn.wordpress.org/trunk@37356
git-svn-id: http://core.svn.wordpress.org/trunk@37322 1a063a9b-81f0-0310-95a4-ce76da25c4cd
