While web crawlers are able to discover pages from links within the site and from other sites, XML sitemaps supplement this approach by allowing crawlers to quickly and comprehensively identify all URLs included in the sitemap and learn other signals about those URLs using the associated metadata.
See https://make.wordpress.org/core/2020/06/10/merge-announcement-extensible-core-sitemaps/ for more details.
This feature exposes the sitemap index via `/wp-sitemap.xml` and exposes a variety of new filters and hooks for developers to modify the behavior. Users can disable sitemaps completely by turning off search engine visibility in WordPress admin.
This change also introduces a new `esc_xml()` function to escape strings for output in XML, as well as XML support to `wp_kses_normalize_entities()`.
Props Adrian McShane, afragen, adamsilverstein, casiepa, flixos90, garrett-eclipse, joemcgill, kburgoine, kraftbj, milana_cap, pacifika, pbiron, pfefferle, Ruxandra Gradina, swissspidy, szepeviktor, tangrufus, tweetythierry.
Fixes#50117.
See #3670. See #19998.
Built from https://develop.svn.wordpress.org/trunk@48072
git-svn-id: http://core.svn.wordpress.org/trunk@47839 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If a site is using `/%post_id%/%postname%/` as permalink structure, and is missing the `postname`, the site won't redirect to the appropriate URL. This change ensure that the redirect happens.
Fixes: #12456.
Props: Frank.Prendergast, dd32, Otto42, hlanggo, wonderboymusic, atimmer, seth17, calvin_ngan, Niresh12495, anbumz, SergeyBiryukov, donmhico.
Built from https://develop.svn.wordpress.org/trunk@47937
git-svn-id: http://core.svn.wordpress.org/trunk@47710 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, the `@` operator was used to prevent possible warnings emitted by `parse_url()` in PHP < 5.3.3 when URL parsing failed.
Now that the minimum version of PHP required by WordPress is 5.6.20, this is no longer needed.
Props netpassprodsr, Howdy_McGee.
Fixes#49980. See #24780.
Built from https://develop.svn.wordpress.org/trunk@47617
git-svn-id: http://core.svn.wordpress.org/trunk@47392 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
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
Previously attempted in [40256], which caused the test for decoded curly quotes to fail in some environments.
`$_SERVER['REQUEST_URI']` contains the encoded URI, so this version removes the failing tests and only checks for encoded curly quotes.
Props joostdevalk, lancewillett, SergeyBiryukov.
Fixes#20383.
Built from https://develop.svn.wordpress.org/trunk@41991
git-svn-id: http://core.svn.wordpress.org/trunk@41825 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[37262] changed a check in `redirect_canonical()` so that it checked
categories in the object cache rather than querying the database. However,
the check was based on the identity of `WP_Term` objects, which in
certain cases can be augmented by the main WP query routine, causing
failures of the `in_array()` check. This caused unnecessary redirects
for URLs where `is_single()` is true, but the URL is different from the
post permalink, such as the `embed` endpoint.
`has_term()` also checks the cache, but does not sufer from this bug.
Props cmillerdev.
Fixes#36602.
Built from https://develop.svn.wordpress.org/trunk@38216
git-svn-id: http://core.svn.wordpress.org/trunk@38157 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
[34561] instituted the policy of forcing pagination for comments. This strategy
was intended to avert problems when 'page_comments' is set to 0 - as it is by
default - and the number of comments on a given post rises into the hundreds or
thousands. By forcing pagination in all cases, we ensured that WordPress would
not time out by processing unwieldy numbers of comments on a given pageload.
The strategy proves problematic, however, because comment permalinks are
generated using the page of the comment. Forcing pagination for posts that
were not previously paginated would change the URL of all comments that do not
appear on the default comment page.
This changeset reintroduces the 'page_comments' setting and its corresponding
checkbox on Settings > Discussion. A number of tests, which were written after
[34561], are modified to work now that 'page_comments' will, once again, be
disabled by default.
See #8071.
Built from https://develop.svn.wordpress.org/trunk@35331
git-svn-id: http://core.svn.wordpress.org/trunk@35297 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, the 'page_comments' toggle allowed users to disable comment
pagination. This toggle was only superficial, however. Even with
'page_comments' turned on, `comments_template()` loaded all of a post's
comments into memory, and passed them to `wp_list_comments()` and
`Walker_Comment`, the latter of which produced markup for only the
current page of comments. In other words, it was possible to enable
'page_comments', thereby showing only a subset of a post's comments on a given
page, but all comments continued to be loaded in the background. This technique
scaled poorly. Posts with hundreds or thousands of comments would load slowly,
or not at all, even when the 'comments_per_page' setting was set to a
reasonable number.
Recent changesets have addressed this problem through more efficient tree-
walking, better descendant caching, and more selective queries for top-level
post comments. The current changeset completes the project by addressing the
root issue: that loading a post causes all of its comments to be loaded too.
Here's the breakdown:
* Comment pagination is now forced. Setting 'page_comments' to false leads to evil things when you have many comments. If you want to avoid pagination, set 'comments_per_page' to something high.
* The 'page_comments' setting has been expunged from options-discussion.php, and from places in the codebase where it was referenced. For plugins relying on 'page_comments', we now force the value to `true` with a `pre_option` filter.
* `comments_template()` now queries for an appropriately small number of comments. Usually, this means the `comments_per_page` value.
* To preserve the current (odd) behavior for comment pagination links, some unholy hacks have been inserted into `comments_template()`. The ugliness is insulated in this function for backward compatibility and to minimize collateral damage. A side-effect is that, for certain settings of 'default_comments_page', up to 2x the value of `comments_per_page` might be fetched at a time.
* In support of these changes, a `$format` parameter has been added to `WP_Comment::get_children()`. This param allows you to request a flattened array of comment children, suitable for feeding into `Walker_Comment`.
* `WP_Query` loops are now informed about total available comment counts and comment pages by the `WP_Comment_Query` (`found_comments`, `max_num_pages`), instead of by `Walker_Comment`.
Aside from radical performance improvements in the case of a post with many
comments, this changeset fixes a bug that caused the first page of comments to
be partial (`found_comments` % `comments_per_page`), rather than the last, as
you'd expect.
Props boonebgorges, wonderboymusic.
Fixes#8071.
Built from https://develop.svn.wordpress.org/trunk@34561
git-svn-id: http://core.svn.wordpress.org/trunk@34525 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Awesome rewrite bug: the `page` query var was being set to `'/4'` in `$wp`. When cast to `int`, it returns `0` (Bless you, PHP). `WP_Query` calls `trim( $page, '/' )` when setting its own query var. The few places that were checking `page` before posts were queried now have sanity checks, so that these changes work without flushing rewrites.
Adds/updates unit tests.
Props wonderboymusic, dd32.
See #11694.
Built from https://develop.svn.wordpress.org/trunk@34492
git-svn-id: http://core.svn.wordpress.org/trunk@34456 1a063a9b-81f0-0310-95a4-ce76da25c4cd
