__group__ ticket summary owner _component _version priority severity milestone type _status workflow _created modified _description _reporter Tickets Awaiting Review 53574 404 redirect guessing should not apply on URLs with trailing slashes Canonical normal normal Awaiting Review defect (bug) new 2021-07-01T16:21:27Z 2021-07-01T16:21:27Z "The original intent of the 404 redirect guessing functionality was to resolve URLs that got split in half by e-mail clients and the like. Some of them would see a dash in a URL and assume they could wrap it to the next line like a multi-syllable word, so you'd have people clicking links like `https://example.com/some-post-` because `with-a-long-slug/` got wrapped to the next line in the e-mail. But currently if you navigate to `https://example.com/bad-slug/` where that doesn't exist, but `https://example.com/bad-slug-exists/` does, you'll get redirected. This doesn't make much sense. The trailing slash on `https://example.com/bad-slug/` conclusively indicates that you didn't click a slug-truncated URL. In this case, it makes more sense to just let it be a 404." markjaquith Tickets Awaiting Review 44559 Alias redirected when page is set as a homepage Canonical 4.9.7 normal normal Awaiting Review defect (bug) new 2018-07-10T16:56:46Z 2018-07-10T16:56:46Z "I have two domains: - `example1.com` (hosting with WP installation) - `example2.com` (only domain, alias to `example1.com`) When I access `example2.com`, content for `example1.com` should be displayed, but instead of it, `example2.com` is redirected to `example1.com`. But when I access particular page (or post) `example2.com/contacts`, everything works and content from `example1.com/contacts` is displayed (but not redirected). It seems to me that problem is related only to homepage which is set as a `page_on_front`, see https://core.trac.wordpress.org/browser/tags/4.9.7/src/wp-includes/canonical.php#L177" pavelevap Tickets Awaiting Review 46061 Canonical prevents accessing paginated results of feed-named tags Canonical 2.7.1 normal normal Awaiting Review defect (bug) new 2019-01-22T05:41:38Z 2022-11-01T03:22:24Z "Given a tag of the name 'rss' (or any of `(feed|rss|rdf|atom|rss2)`) Canonical will cause a redirect for a paginated result to an incorrect url lacking the 'rss' For example: {{{ $ curl -Is http://wordpress.dev/tag/rss/page/2/ | grep Location Location: http://wordpress.dev/tag/page/2/ }}} This appears to be caused by https://core.trac.wordpress.org/browser/trunk/src/wp-includes/canonical.php?rev=43571&marks=297-302#L290 This was originally reported as https://meta.trac.wordpress.org/ticket/2945" dd32 Tickets Awaiting Review 51725 Canonical redirect and user_trailingslashit() Canonical 5.5.2 normal trivial Awaiting Review defect (bug) new needs-unit-tests 2020-11-07T01:06:54Z 2024-01-25T11:39:58Z "Hi, this bug is quite difficult to spot and it appears only when ''redirect_canonical()'' function is used to force the canonical redirect on front page and the trailing slashes are not added to the permalinks. Happily it is nothing serious. **How to reproduce this bug?** **Step 1. Remove the trailing slashes from WP permalinks:** First of all, you need to use ""Custom structure"" mode in Permalinks settings and remove the trailing slash (''/%postname%/'' => ''/%postname%'') in the adjacent input field. Therefore, the value of ''$wp_rewrite->use_trailing_slashes'' is changed to false. **Step 2. Trigger the canonical redirect on front page** Now let's disable the feed URL by redirecting the visitors trying to access it: {{{#!php ''http://example.com''). The problem is that the PHP notice is displayed then: ''Notice: Undefined index: path in /var/www/vhosts/maciejbis.net/example.com/wp-includes/canonical.php on line 576
'' I guess that the source of the problem is here (line 501): https://core.trac.wordpress.org/browser/tags/5.5.1/src/wp-includes/canonical.php#L501 {{{#!php $redirect['path'] = user_trailingslashit( $redirect['path'] ); }}} Unfortunately because of ''user_trailingslashit()'' function, the slash is removed and value is set to ''null''. The value of `$redirect['path']` should not be changed in this particular case (value '/' should be preserved). My first suggestion is to exclude ''user_trailingslashit()'' function there and not use it when value of `$redirect['path']` variable is just a single slash '/': {{{#!php $redirect['path'] = ( $redirect['path'] === '/' ) ? $redirect['path'] : user_trailingslashit( $redirect['path'] ); }}} Another idea is to do the same but directly in ''user_trailingslashit()'' function: https://core.trac.wordpress.org/browser/tags/5.5.1/src/wp-includes/link-template.php#L51 Basically this piece of code: {{{#!php if ( $wp_rewrite->use_trailing_slashes ) { $string = trailingslashit( $string ); } else { $string = untrailingslashit( $string ); } }}} can be replaced with: {{{#!php if ( $wp_rewrite->use_trailing_slashes ) { $string = trailingslashit( $string ); } else if ( $string !== '/' ) { $string = untrailingslashit( $string ); } }}} " mbis Tickets Awaiting Review 55880 Custom post type isn't redirected to its canonical URL Canonical normal normal Awaiting Review defect (bug) new 2022-05-31T11:54:44Z 2023-08-04T06:50:43Z "At the opposite of a custom taxonomy term which is redirected to its pretty URL when we use its plain permalink, a custom post type is not. 1. Set a custom permalink structure in WordPress permalinks settings like /%postname%/ 2. Register a custom taxonomy and custom post type by using the code below for example {{{#!php 'Custom taxonomies', 'singular_name' => 'Custom taxonomy', 'menu_name' => 'Custom taxonomies', ); register_taxonomy( 'custom_tax', 'custom_post', array( 'labels' => $custom_tax_labels, 'public' => true, 'rewrite' => true, 'hierarchical' => true, ) ); $custom_post_labels = array( 'name' => 'Custom posts', 'singular_name' => 'Custom post', 'menu_name' => 'Custom posts', ); register_post_type( 'custom_post', array( 'labels' => $custom_post_labels, 'public' => true, 'rewrite' => true, 'has_archive' => true, 'taxonomies' => 'custom_tax', ) ); } add_action('init', 'test_custom_taxonomy_and_post_type'); }}} 3. Create a custom taxonomy term: Custom term example (slug: custom-term-example) 4. Create a custom post: Custom post example (slug: custom-post-example) and link it to Custom term example 5. Try to get the plain permalink of the custom taxonomy http://example.org/?custom_tax=custom-term-example. We are redirected to the pretty URL http://example.org/custom_tax/custom-term-example/ 👌 6. Do the same with the custom post example plain permalink URL http://example.org/?custom_post=custom-post-example. We aren't redirected to its canonical URL which should be http://example.org/custom_post/custom-post-example 7. Notice that the {{{}}} is correctly set in the HTML source code by the {{{wp_get_canonical_url()}}} function https://github.com/WordPress/WordPress/blob/6.0/wp-includes/link-template.php#L3913 8. Note that the custom post type archive page isn't redirected either. http://example.org/?post_type=custom_post should be redirected to http://example.org/custom_post " manooweb Tickets Awaiting Review 42512 Domain with special character redirect loop on homepage Canonical 4.5 normal normal Awaiting Review defect (bug) new 2017-11-11T11:31:53Z 2018-03-14T01:39:00Z "Hi, i am experiencing a problem with wordpress starting with 4.5 i think. Since this commit [1] i always get redirect loops on the home page. this issue seemed to be fixed, and i can confirm this on various wordpress instances. But one instance has a '''domain with a special character''' (""ö"" - german Umlaut), and the problem persists there. Also i am not the only user who can confirm this issue [2]. Currently i have to reset the line [3] to the old value after every update since it gets overwritten. This is not a solution, only a very bad workaround. Of course i already have tried to disable all plugins, themes etc. which could cause the issue. I can say, that the problem is not caused by the hoster since i have many wordpress instances running on the same hoster and no other does have this problem (and no other have a special character in the domain) Regards [1] https://github.com/WordPress/WordPress/commit/84a3b4407f9e03311aa591004f3bec0639f3ba3f?diff=unified [2] https://wordpress.org/support/topic/45-causes-infinite-redirect-on-static-front-page/page/2/#post-8156893 [3] https://github.com/WordPress/WordPress/commit/84a3b4407f9e03311aa591004f3bec0639f3ba3f?diff=unified#diff-dc3247fd3fa65f15e6fc5ce8c6fa2d42L175" stefan-niedermann Tickets Awaiting Review 41577 Fix Notice fixing Canonical 4.8.1 normal normal Awaiting Review defect (bug) new 2017-08-07T00:09:12Z 2021-03-19T11:53:15Z "The file wp-includes/canonical.php produces Notices for undefined indexes when a requested uri has no path or query. The attached patch sets the indexes to empty strings. #6977 (which was not used) had a different approach. The currently used ""Notice fixing"" approach does not fix up $original which is used afterwards. " glehner Tickets Awaiting Review 54758 Front page not embeddable when using a static page_on_front Canonical normal normal Awaiting Review defect (bug) new has-patch 2022-01-07T06:01:48Z 2022-01-07T09:11:15Z "When a site is configured with a page_on_front, Canonical kicks in and redirects the user to the homepage. This is caused by Canonical not being embed-aware. As an example, the WordPress.org homepage should be embeddable: {{{ $ curl -Is https://en-au.wordpress.org/embed/ | grep -E '^(HTTP|location)' HTTP/2 301 location: https://en-au.wordpress.org/ }}} The non-pretty embeds do however work, unfortunately WordPress doesn't link to these when rewrites are enabled: {{{ $ curl -Is https://en-au.wordpress.org/?embed=1 | grep -E '^(HTTP|location)' HTTP/2 200 }}} After the PR attached to this ticket: {{{ $ curl -ILs https://en-au.wordpress.org/embed/ | grep -E '^(HTTP|location)' HTTP/2 200 }}} The fix attached is a combination bugfix/enhancement, as I've fixed the bug by making canonical embed aware, so it redirects to the canonical embed location. The PR isn't complete, as it appears to still fail on one of the test-cases I added, and appears to have altered (Potentially fixed?) the behaviour of another canonical test. A more targeted fix would be to disable canonical when `is_embed()` is truthful." dd32 Tickets Awaiting Review 51916 Incorrect URL encoding and redirect in redirect_canonical Canonical 5.5.3 normal normal Awaiting Review defect (bug) new 2020-12-02T13:50:46Z 2020-12-02T13:50:46Z "1. Setup a site with pretty permalinks. 2. Visit a URL in the following format, where p=10 must be a valid post ID: https://mywordpress.site/?p=10&a%26b%3dc=1 3. WordPress core will redirect you to a cannonical URL. However it fails to escape the URL query correctly and you end up here: https://mywordpress.site/post-id-10-slug?a=b&c=1" pavoleichler Tickets Awaiting Review 45459 Infinite Loop By redirect_canonical (canonical.php) due to mishandling of Port Information in URL creation/rebuilt Canonical 4.9.8 normal major Awaiting Review defect (bug) new 2018-12-02T05:14:24Z 2018-12-06T22:30:32Z "**Background** Fresh install version 4.9.8 for a simple website (no SSL, using standard theme twentyseventeen). Standard installation went well without any hiccup. However immediately after installation ""Too many redirect errors"" occurred using any browser. **Infinite loop Symptoms** * Happen on URL that required index.php e.g: http://[domain.com] , http://[domain.com]/ (with or without trailing slash) * Full permalink URL such as: * http://[domain.com]/2018/12/01/hello-world/ * http://[domain.com]/category/uncategorised/ will render without any problem This symptom actually is actually has happened before in this particular server and all my other website on this server requiring the removal of redirect_canonical function. Applied in functions.php of the themes file as follow: {{{ remove_filter('template_redirect', 'redirect_canonical'); }}} With the removal of redirect_canonical above, the infinite loop is mitigated. But I decided this time to try to pin out the real problem because removing canonicalization is not a very good thing for SEO. **Investigation** * This fresh install infinite loop happen in my server that uses ""reverse proxy"" setting using Nginx, i.e the requested url is passed around between reverse proxy and upstream server using http://[domain.com]:80 and http://[domain.com]:8080 (or any other arbitrary port) * Trace the problem to canonical.php and catch the bug as follows * Original snippet of canonical.php (in wp-includes) {{{ 530 if ( $do_redirect ) { 531 // protect against chained redirects 532 if ( !redirect_canonical($redirect_url, false) ) { 533 wp_redirect($redirect_url, 301); 534 exit(); 535 } else { 536 // Debug 537 // die(""1: $redirect_url
2: "" . redirect_canonical( $redirect_url, false ) ); 538 return; 539 } 540 } else { 541 return $redirect_url; 542 } }}} * Minor modification to catch the bug (reverse the logic in line 532 so it goes to the debug section and add $requested_url to be printed as well): {{{ 530 if ( $do_redirect ) { 531 // protect against chained redirects 532 if ( redirect_canonical($redirect_url, false) ) { 533 wp_redirect($redirect_url, 301); 534 exit(); 535 } else { 536 // Debug 537 die(""1: $redirect_url
2: $requested_url
3: "" . redirect_canonical( $redirect_url, false ) ); 538 return; 539 } 540 } else { 541 return $redirect_url; 542 } }}} * From the print out of the debugging, it is confirmed that the differences between the $requested_url and $redirect_url is causing the infinite loop: (i.e: the port "":80"" is missing in the $redirect_url, causing it to recursively redirected to the same http://[domain.com]/) * $redirect_url: http://[domain.com]/ * $requested_url: http://[domain.com]:80/ If the url were http://[domain.com]/2018/12/01/hello-world/ it will not produce the infinite loop as the result of the debugging is: * $redirect_url: http://[domain.com]/2018/12/01/hello-world/ * $requested_url: http://[domain.com]/2018/12/01/hello-world/ (no port number produced by the function) * Trace further how the function handle port, and found this ""lazy"" snippet (original): {{{ 386 // Handle ports 387 if ( !empty($user_home['port']) ) 388 $redirect['port'] = $user_home['port']; 389 else 390 unset($redirect['port']); 391 }}} Apparently from the code above, if the $WP_HOME doesn't have port component it just removes the component for redirection. Seems a bit lazy to me. True enough, I add below line in wp-config.php and fix the problem {{{ define('WP_HOME','http://[domain.com]:80'); }}} But of course, it is never that simple. While the infinite loop for the home page is handled, the other link is affected. In this case, going back to the debuging mode, the result os requesting url http://[domain.com]/2018/12/01/hello-world/ produced: * $redirect_url: http://[domain.com]:80/2018/12/01/hello-world/ * $requested_url: http://[domain.com]/2018/12/01/hello-world/ (i.e: the port "":80"" is now added on the $redirect_url) * Trace further up as the source of the port, it seems that it come from $original[] variable within the function {{{ 70 $original = @parse_url($requested_url); }}} which sometimes have port information parsed, but sometimes is not. **TEMPORARY SOLUTION (so far okay)** The idea is how the code could handle ""port"" better: * if there is no port information in $original variable, why bother adding port info to the redirection * but if there is one, the redirection needs to also include the port info to prevent mismatch (hence infinite loop) i.e http://[domain.com]:80/ redirect to http://[domain.com]/ which then redirect to http://[domain.com]:80/ and so on. Here is the code that I come up that solve this issue so far {{{ 386 // Handle ports 387 if ( isset($original['port']) && !empty($original['port'])) { 388 if ( !empty($user_home['port']) ) 389 $redirect['port'] = $user_home['port']; 390 else { 391 $redirect['port']='443'; 392 if (isset($original['scheme']) && !strcmp($original['scheme'],'http')) $redirect['port']='80'; 393 } 394 } }}} i.e: if user is using exoctic/unusual port they need to put it on the $WP_HOME anyway - otherwise assuming 80 and 443 would be quite common. What causing the port number to come up? I assume it is due to the reverse proxy configuration in 1 server where parameter passing is using the port number that is not common. (e.g between https:443 to http:8080), but nevertheless, the more proper handling of port info as described above should be logical and necessary to prevent the unnecessary infinite loop. I categorize this bug initially as ""major"" because it happens without any variety of user data, it is from a fresh install and reverse-proxy caching is a common technique used even in a shared hosting environment. The expert at WordPress can determine whether the solution is robust enough to be implemented in more permanently. So, with modification of that, people that use reverse proxy setting can still use canonicalization feature from WordPress without infinite loop problem. Also they can remove: {{{ remove_filter('template_redirect', 'redirect_canonical'); }}} from their functions.php Thanks, hope this helps." dkristanda Tickets Awaiting Review 58803 Infinite loop in canonical.php Canonical 6.2 normal minor Awaiting Review defect (bug) new 2023-07-13T17:49:02Z 2023-08-30T17:44:26Z "A site 24x7 monitor that points to a URL on our website leads to an error with infinite loops reported. This error started after the page being pointed by the monitor received a new Slug, leading to HTTP redirection due to autocomplete to the closest URL. Still, I believe it occurs only during periods of transient availability of our shared host. Looking at the source code [REF2] I believe there is potential for an infinite loop on line 800. Possible fix in [REF3]. By assigning the result of redirect_canonical() to a variable ($chained_redirect) before the if statement, we ensure that the same value is used throughout the if block preventing unnecessary recursive calls. References ---------- [REF1] HTTP/1.1 508 Loop Detected Server : nginx ... [REF2] https://github.com/WordPress/wordpress-develop/blob/6.2/src/wp-includes/canonical.php#L780-812 [REF3] // Protect against chained redirects. $chained_redirect = redirect_canonical($redirect_url, false); if (!$chained_redirect) " emerlen Tickets Awaiting Review 51700 Infinite redirect loop error when blog site is rewritten and real domain on another server Canonical 5.5.2 normal normal Awaiting Review defect (bug) new 2020-11-03T14:02:07Z 2020-11-03T15:45:55Z "I have my main site at: http://mainsite.com hosted on server A. I have my wordpress blog hosted on some other domain however it is rewritten to http://mainsite/blog (although under the hood is is on another domain http://myblogonmyserver.com) and it is hosted od server B. Both machines are Windows Server machines and PHP is 7.4 altought version of php is not an issue here. This bug is there for at least year. I found solution and source of bug. It is inside canonical.php file (around line 65) In latest version of wordpress (5.5.3) it is in fact around line 71 . I just added this part of code: {{{#!php false`. {{{#!php 'Genre', 'public' => true, 'rewrite' => false, ); register_taxonomy( 'genre', array( 'post' ), $args ); }}} 2. Create a term with URL-encoded slugs. ( example: 🏠, ワードプレス ) 3. Set Permalink structure to to something other than Plain. 4. Go to the archive of the created term. 5. Redirect loop. `remove_action( 'template_redirect', 'redirect_canonical' )`, it will not occur. " Toro_Unit Tickets Awaiting Review 43249 Redirection issue with Japanese characters in query string on static front page Canonical 4.9.4 normal normal Awaiting Review defect (bug) new 2018-02-07T17:15:03Z 2018-02-09T10:54:03Z "Hello, I have found a bug that when a static page option is enabled from here: http://jom.x10.mx/wp-admin/options-reading.php Then, you accessed the home page with the Japanese characters on the query string, it causes redirection issues “ERR_TOO_MANY_REDIRECTS”. Example links are: http://jom.x10.mx/?%E3%83%89%E3%83%A0%E3%83%BB%E3%83%88%E3%83%AD%E3%83%94%E3%82%AB%E3%83%AB%E3%83%86%E3%82%B9%E3%83%88%E3%82%BF%E3%82%A4%E3%83%97 http://jom.x10.mx/index.php?%E3%82%B6%E3%82%AF%E2%85%A1F%E5%9E%8B%EF%BC%88%E7%A0%B2%E6%92%83%E8%A3%85%E5%82%99%EF%BC%89 You can test this on any self hosted WordPress installation with the “static page” option enabled. This causes our client’s SERP to have been ruined. http://www.almondmarketing.co.uk/index.php?%E3%83%89%E3%83%A0%E3%83%BB%E3%83%88%E3%83%AD%E3%83%94%E3%82%AB%E3%83%AB%E3%83%86%E3%82%B9%E3%83%88%E3%82%BF%E3%82%A4%E3%83%97 http://www.almondmarketing.co.uk/index.php?%E3%82%B6%E3%82%AF%E2%85%A1F%E5%9E%8B%EF%BC%88%E7%A0%B2%E6%92%83%E8%A3%85%E5%82%99%EF%BC%89" jomgapuz Tickets Awaiting Review 57260 Static home page redirect error using post name premalinks behind reverse proxy Canonical 6.1.1 normal normal Awaiting Review defect (bug) new 2022-12-02T14:07:29Z 2022-12-02T16:42:02Z "In a WP site behind a reverse proxy all was working ok. I then set a static home page and all was still working. After I set post name permalinks, all pages kept working except home page, which had redirect errors. After some time spent researching the problem, I found that the problem was on line 69 of wp-includes/canonical.php: {{{#!php post_type is an array instead of a string Canonical 4.8.3 normal normal Awaiting Review defect (bug) new 2017-11-02T20:02:01Z 2019-02-01T12:30:46Z "I am not familiar enough with WordPress to know if this is an issue or intended. redirect_guess_404_permalink has a block that looks like: wp-includes/canonical.php:594 {{{#!php // if any of post_type, year, monthnum, or day are set, use them to refine the query if ( get_query_var('post_type') ) $where .= $wpdb->prepare("" AND post_type = %s"", get_query_var('post_type')); else $where .= "" AND post_type IN ('"" . implode( ""', '"", get_post_types( array( 'public' => true ) ) ) . ""')""; }}} This works in the case that post_type is a single value, but if it has been changed to an array of values then this looks to trigger the warning: wp-includes/wp-db.php:1353 {{{#!php _doing_it_wrong( 'wpdb::prepare', __( 'The query only expected one placeholder, but an array of multiple placeholders was sent.' ), '4.9.0' ); }}}" augustuswm Tickets Awaiting Review 60173 "Warning: Undefined array key ""host""" Canonical normal normal Awaiting Review defect (bug) new has-patch 2024-01-01T08:39:34Z 2024-02-15T16:25:25Z "I encountered an issue on my WordPress website where an ErrorException is thrown, displaying the following error message: {{{ ErrorException Warning: Undefined array key ""host"" }}} This error occurs in the canonical.php file on line 718 of the /wp-includes/ directory. Here is the relevant code snippet: `$compare_original = array( $original['host'], $original['path'] );` Additionally, the error stack trace includes the following information: `/wp-includes/canonical.php in redirect_canonical at line 718` " ainsleyclark Tickets Awaiting Review 55993 Wrong canonical redirect for paged posts page Canonical normal normal Awaiting Review defect (bug) new has-patch 2022-06-16T13:55:21Z 2022-11-07T08:22:34Z "- Setup a site with a static front page and a posts page (let's call it ""Posts""). - Take note of the page_id of the posts page. 265 in my case. - Make sure to use pretty permalinks. - Create sufficient posts to be able to display the page 2 of the posts page. - In the address bar, type `https://mysite.com/?page_id=265` (the posts page plain permalink) => The site is correctly redirected to `https://mysite.com/posts/` - In the address bar, type `https://mysite.com/?paged=2&page_id=265` (the paged posts page plain permalink) => The site is wrongly redirected to `https://mysite.com/page/2/` and displays an empty content. I would expect the url to be redirected to `https://mysite.com/posts/page/2/` " Chouby Tickets Awaiting Review 41712 canonical infinite redirect bug Canonical normal normal Awaiting Review defect (bug) new has-patch 2017-08-23T15:27:56Z 2021-01-11T17:20:29Z "I had an infinite redirection problem caused by ""redirect_canonical"" (wp-includes\canonical.php) I have a query string parameter ex: ""http://mysite.com/mypage/?q=test%2C+test"" and it was redirected infinitly to itself because of: {{{#!php ` As well as simply being wrong, this can conflict with WordPress's `wp_guess_url` functionality. For example, https://central.wordcamp.org/page/5/ canonicalises to https://central.wordcamp.org/5/, which when visited redirects to the ""5-reasons-you-should-attend-wordcamp-nyc"" post (due to the presence of ""5"" in the slug). I would imagine this could seriously confuse some search engines. This situation is made worse by the fact that only a small proportion of pages created through WordPress have legitimate pagination. In these cases the page should canonicalise to the first page, but I believe handling of non-paginated pages would be better considered in a separate ticket. This has come to light as a result of the following meta tickets which are contributing to the current SEO issues on wordpress.org: https://meta.trac.wordpress.org/ticket/4198 https://meta.trac.wordpress.org/ticket/4564 This bug is only affecting sites with pretty permalinks enabled." bradleyt Tickets Awaiting Review 50149 url issue on category slugs Canonical 5.4.1 normal normal Awaiting Review defect (bug) new 2020-05-12T11:09:34Z 2020-05-12T17:53:32Z "This url structure is used to split the posts of a category into pages. {{{ .../category/{category_name}/page/2/ }}} However, if you use /0 before the /page/2/ section, the system ignores /0 and it does not redirect to the 404 page and opens the /page/2 archive page. But in this page, the single_cat_title() function does not return a value. {{{ .../category/{category_name}/0/page/2/ }}} Even all parameters entered before /0 are ignored too {{{ .../category/{category_name}/1/2/3/4/5/abc/0/page/2/ }}} " ersinkurtdal Tickets Awaiting Review 51508 Fix for canonical.php Canonical 2.3 normal trivial Awaiting Review enhancement new 2020-10-13T12:20:40Z 2020-11-15T07:09:35Z "In extremely rare cases it is impossible to determine the path {{{#!php set( 'post_type', [ 'post', 'portfolio', 'page' ] ); } add_action( 'pre_get_posts', '_debug_php_warning_on_404' ); }}} Then try a missing page slug __domain.test/missing-content__ it will show a warning: wpdb::prepare was called incorrectly. The query only expected one placeholder, but an array of multiple placeholders was sent. Please see Debugging in WordPress for more information. (This message was added in version 4.9.0.) The fix is to replace line 700 and check for array ""post_type"" query var: {{{ if ( $post_type = get_query_var( 'post_type' ) ) { if ( is_array( $post_type ) ) { $where .= "" AND post_type IN ('"" . implode( ""', '"", esc_sql( $post_type ) ) . ""')""; } else { $where .= $wpdb->prepare( ' AND post_type = %s', $post_type ); } } }}}" arl1nd Tickets Awaiting Review 40082 Pretty links for users when searching Canonical 4.7.3 normal normal Awaiting Review enhancement reopened 2017-03-09T15:12:23Z 2018-08-14T09:50:45Z "When using the site search, users are shown the ugly URL when taken to the results page: > example.com/?s=keyword It appears as though search results can have pretty URLs: > example.com/search/keyword Maybe show the pretty URL in the browser instead?" henry.wright Tickets Awaiting Review 52865 Strip 'enclosed' trailing spaces in URLs Canonical low normal Awaiting Review enhancement new 2021-03-19T10:32:40Z 2021-03-19T10:42:06Z "#20383 made improvements that strip trailing punctuation from URLs. E.g., https://ma.tt/2012/03/productivity-per-square-inch%20 redirects correctly to the canonical URL. However, URLs like https://ma.tt/2012/03/productivity-per-square-inch%20/ (which 'enclose' the trailing space with a trailing slash) are ''not'' redirected. It, and others like it, typically return a 404 error. This kind of 'broken link' pattern is ''extremely'' common on the web; particular as a trailing slash is often appended to a malformed URL ''before'' WP runs (e.g., via a server/htaccess/nginx configuration). We should refine the canonical redirect logic (in `redirect_canonical`) to also consider and redirect these types of requests. **Considerations** - The ""''Remove trailing spaces and end punctuation from the path''"" section of `redirect_canonical` doesn't consider the presence of trailing slashes in the URL. This could/should be adapted to catch those. - There might be cases where a user 'legitimately' has a permalink structure (or slug) that ends in `%20` or `%20/`. That might(?) make a fix more complicated than just sniffing for whether the permalink structure ends with `/`. - It looks like it's inconsistent in WP where `%20` (and/or `%20/` ) can be added to slugs or structures. It's stripped in some places, but not in others. - ''Should'' a permalink or slug be 'allowed' to contain, or end in, a space character? If this is being stripped in some parts of WP, maybe that's a good argument to prevent it elsewhere/everywhere. In which case, fixing this becomes a lot simpler. " jonoaldersonwp Tickets Awaiting Review 35248 "WordPress should remove domain trailing dot (as/like it removes ""www."")" Canonical 4.4 normal normal Awaiting Review enhancement reopened 2015-12-29T00:35:21Z 2020-01-31T16:22:59Z "I think, WordPress should redirect from address with trailing dot of domain to version without the dot, like it redirects from address with ""www."". I have read about which version is correct and seems version without dot is allowed according to RFCs, and it is very widely used, and even almost nobody know that trailing dot can be used. ( https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol ""The first definition of HTTP/1.1, the version of HTTP in common use, occurred in RFC 2068 in 1997, although this was obsoleted by RFC 2616 in 1999"" -> https://tools.ietf.org/html/rfc2616#section-14.23 ""The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL."" -> https://tools.ietf.org/html/rfc2616#section-3.2.1 ""For definitive information on URL syntax and semantics, see ""Uniform Resource Identifiers (URI): Generic Syntax and Semantics,"" RFC 2396 ..."" -> http://tools.ietf.org/html/rfc2396#section-3.2.2 ""The rightmost domain label of a fully qualified domain name will never start with a digit, thus syntactically distinguishing domain names from IPv4 addresses, and may be followed by a single ""."" if it is necessary to distinguish between the complete domain name and any local domain."" )" qdinar Candidates for Closure 36737 Single site reachable on multiple subdomains always redirected to site_url Canonical 4.5 normal normal Awaiting Review defect (bug) new close 2016-05-03T07:21:29Z 2021-01-14T22:11:33Z "We run a site which is reachable by multiple subdomains (nb. not multisite) For example customer1.site.nl, customer2.site.nl. A plugin uses the subdomain to display different data for each customer. The site url is set to www.site.nl. Since a recent update this stopped working. The visitor is always redirect to the site url www.site.nl. I tracked down the problem to canonical.php. When I replace this file with the version from 4.4.2 the old behaviour is back, ie. the subdomains are not redirected. There are no rewrite rules for these sub domains. " jsoft Candidates for Closure 36420 A more forgiving redirect guesser Canonical normal normal Awaiting Review enhancement new dev-feedback 2016-04-05T14:13:37Z 2017-08-16T19:53:17Z " I would like the redirect guesser to be more forgiving using SOUNDS LIKE . Here's a small suggestion: {{{#!php function redirect_guess_404_permalink() { global $wpdb; if ( get_query_var('name') ) { $where = $wpdb->prepare(""(post_name SOUNDS LIKE %s"", $wpdb->esc_like( get_query_var('name') ) ); $where .= $wpdb->prepare("" OR post_name LIKE %s)"", $wpdb->esc_like( get_query_var('name') ) . '%'); .... }}} It would be even better if it could be implemented using levenstein distance if that is not too heavy on resources. https://github.com/fza/mysql-doctrine-levenshtein-function " gorillum Tickets Needing Feedback 34800 Canonical 301 redirects go to request origin instead of site_url Canonical 4.3.1 normal normal defect (bug) new reporter-feedback 2015-11-27T11:48:52Z 2019-06-04T19:33:12Z "I have a problem with canonical redirect using a CDN setup. Let's say we have an origin server at `origin.example.com`, and the CDN at `www.example.com`. When I request `https://www.example.com/page-x`, it redirects me to `https://origin.example.com/page-x/` instead of `https://www.example.com/page-x/`, altough both `site_url` and `home_url` are set to `https://www.example.com`. I suspect that Wordpress doesn't use `site_url` when composing the redirect URL, it's just using the request URL with a trailing slash added (which is in fact `https://origin.example.com/page-x` as the CDN translates the request). The expected behaviour would be to either: * use the correct absolute URL in the header, like `Location: + ` * use a relative URL, like `Location: ` I also checked the Redirection plugin, which returns relative URLs in the 301 redirects, and those work fine with my setup. Thanks for looking into this! Sevcsik " sevcsik Tickets Needing Feedback 37115 recent canonical change is giving an infinite 301 redirect loop Canonical 4.4.2 normal normal defect (bug) new dev-feedback 2016-06-16T16:26:39Z 2019-06-04T19:39:05Z "Hello, For 4.5.2 in canonical.php line 175, in prior versions there was an elseif condition which was removed. Can you please add it back? && isset($wp_query->queried_object) && For example, when we have akamai injecting GET parameters to our home page, it just goes in an infinite 301 loop due to line 175 now evaluating TRUE when in the past it would evaluate as FALSE, and we'd like that back. Please and thank you awesome wordpress team!" solomon123br Tickets Needing Feedback 31300 redirect_canonical returns too early Canonical normal normal defect (bug) new dev-feedback 2015-02-11T17:00:31Z 2019-12-06T10:01:04Z "If `$redirect_url` is not set or is not equal to `$requested_url` then `redirect_canonical()` returns early and does not trigger the `redirect_canonical` filter. This prevents plugins from being able to alter the canonical URL. This bug was partially addressed in #8975 (it still returned early when the redirect and requested URL are the same), but this was reverted in #11700 without any indication as to why. The attached patch ensures the filter triggers even when the `$redirect_url` is not set or is the same as `$requested_url`." stephenharris Tickets with Patches 39535 Canonical redirects disallow tag named comments Canonical normal normal Future Release defect (bug) new needs-unit-tests 2017-01-10T09:04:05Z 2019-02-28T19:41:33Z "The `redirect_canonical` function includes a regular expression replacement which effectively disallows tags named ""comments"" to have an RSS feed: https://github.com/WordPress/WordPress/blob/master/wp-includes/canonical.php#L285 For example: /blog1/tag/comments/feed/ This is redirected to: /blog1/tag/feed/ Could / should the regular expression on line 285 could pay attention to the first placeholder it matched (`comments/?`) or check whether the page is a tag request?" dwc Tickets with Patches 43274 Changing $(comments|feed)_base of WP_Rewrite causes errors because of hardcoded strings in redirect_canonical() Canonical normal normal Future Release defect (bug) new needs-unit-tests 2018-02-09T21:11:37Z 2019-01-14T22:41:57Z "When you change `$comments_base`/`$feed_base` for `WP_Rewrite` instance, URLs with that base will not work because `comments` and `feed` strings are hardcoded in a few places in `redirect_canonical()`. Changing these to use `$wp_rewrite->comments_base` and `$wp_rewrite->feed_base` respectively will fix this issue. NOTE: When testing feed URLs, changing `feed` with `feed_base` in `example.com/feed/` will not work. Feed URLs work in two places: `example.com/(feed|rss2?|rdf|atom)` and `example.com/feed_base/(feed|rss2?|rdf|atom)` ([https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-rewrite.php?rev=42343#L860 see rules]). When you open `example.com/feed/` you match first rule where `feed` is type of feed. You need second rule to test it. There is quick workaround though: {{{#!php add_action( 'after_setup_theme', function() { $GLOBALS['wp_rewrite']->feed_base = 'mycustomfeedbase'; $GLOBALS['wp_rewrite']->feeds[] = 'mycustomfeedbase'; } ); add_action( 'parse_query', function( $q ) { if ( $GLOBALS['wp_rewrite']->feed_base == $q->get( 'feed' ) ) { $q->set( 'feed', 'feed' ); } } ); }}} Don't forget to flush rewrite rules." dimadin Tickets with Patches 14773 Error in slug parsing leads to unlimited URLs for the same article = duplicate content Canonical 2.5 normal normal Future Release defect (bug) reviewing has-patch 2010-09-03T14:20:45Z 2023-10-19T20:10:42Z "an example says more than 1000 words: right url: http://ahmongwoman.wordpress.com/2010/09/02/i-am-not-hmong-and-i-dont-speak-spanish/ wrong urls: http://ahmongwoman.wordpress.com/2010/09/02/i-am-not------hmong-and-i-dont-speak-spanish/ http://ahmongwoman.wordpress.com/2010/09/02/i----am-not-hmong-and-i-dont-speak-spanish/ http://ahmongwoman.wordpress.com/2010/09/02/i-am-not-----hmong-and-i-------dont-speak---------spanish/ Problem: Wordpress returns the article with HTTP status code 200 for the wrong URLs. This is a serious issue for people regarding search engine optimization (duplicate content). Expected results: Wordpress returns HTTP Status code 301 with Location-Header and right URL to the client." thermoman Tickets with Patches 33821 redirect_canonical does not consider port in $compare_original Canonical 2.3 normal normal Future Release defect (bug) new needs-unit-tests 2015-09-11T03:18:16Z 2019-09-23T21:12:34Z "In the `wp-includes/canonical.php` file the `$requested_url` is built starting at line 64. It combines `is_ssl()` for protocol, `$_SERVER['HTTP_HOST']`, and `$_SERVER['REQUEST_URI']` - but it does not consider `$_SERVER['SERVER_PORT']` This causes a redirect loop for us because we run HTTPS on port 8443. I suggest checking to see if a port other than 80 or 443 is being used and adding that as part of the comparison - suggested patch attached." willshouse Tickets with Patches 34353 redirect_canonical() – Undefined indexes 'host' and 'scheme' Canonical 4.3.1 normal normal Future Release defect (bug) reopened needs-unit-tests 2015-10-19T08:47:03Z 2023-08-19T00:05:18Z "Hello, We have a problem on our Blog (http://blog.mila.com). Since over half a year, we get these notifications on top of our wordpress blog: '''Notice: Undefined index: HTTP_HOST in /opt/wordpress/wp-includes/canonical.php on line 66''' '''Notice: Undefined index: HTTP_HOST in /opt/wordpress/wp-includes/nav-menu-template.php on line 558''' The notifications come and go, so i don't know what the problem is.. This is line 66 in the canonical file: {{{#!php '/', 'HTTPS' => 'on', 'HTTP_HOST' => 'www.example.com', );" thasmin Unpatched Bugs 37505 Filtering pagination when the pagenumber doesn't exist. Canonical 4.5.3 normal normal defect (bug) new 2016-07-29T05:10:50Z 2019-06-04T19:40:25Z "Hello :). `WP_Query::page` or `$GLOBALS['page']` or `get_query_var( 'page' );` will return whatever value is set by the visitor on a non-paginated page or post. On a paginated page/post, it will 301 redirect the visitor to the first page, this is OK. '''An example, on a post or page without pagination:''' The output of the page will be incorrect, specifically on these two parts (both Title and Canonical URL show pagination). URL: `http://example.com/2016/07/29/hello-world/123/` {{{ Hello world! – Page 123 – Example.com ... ... }}} This is a major concern for SEO, as it will output duplicated pages. Abusers could mark otherwise good pages as duplicated by simply linking to a non-existing non-paginated page. '''My suggestion:''' Check against `$GLOBALS['multipage']` (or `$GLOBALS['numpages']`) prior to creating the above output. " Cybr Unpatched Bugs 35847 Issue with blog roll pagination on static frontpage Canonical 4.4.2 normal major defect (bug) new 2016-02-17T02:00:09Z 2019-06-04T19:34:46Z "This is a follow-up to #35344. Still having this problem on 4.4.2 with or without [https://core.trac.wordpress.org/attachment/ticket/35344/35344.2.diff 35344.2.diff] applied. The query.php in 4.4.2 is way too different to apply [https://core.trac.wordpress.org/attachment/ticket/35344/35344.diff 35344.diff]. In my case this bug only affects the blog roll on a static front page, and instead of redirecting to the homepage it strips the page number from the URL and tries to load sitename.com/page/ which, in turn, returns a 404. The same page, unset from being the frontpage, works fine." finomeno Unpatched Bugs 35562 Single post pagination redirect back to page one with nextpage tag - WordPress 4.4.1 Canonical 4.4 normal normal Future Release defect (bug) new 2016-01-21T18:07:31Z 2017-02-07T19:11:07Z "When a single post post content, {{{$post->post_content}}}, does not contain the {{{}}} tag, and we append more pages to the single post through the {{{content_pagination}}} filter, pagination works as expected Sample code to test {{{ add_filter( 'content_pagination', function ( $pages ) { $pages[] = 'This is another page we want to append'; return $pages; }); }}} However, when we add the {{{}}} tag inside the post content ($post->post_content}}} and run the same sample code, any appended page simply redirects back to page one as a 404 header is set on appended pages. I tracked this down to the following block of code (lines 623 - 628) inside the {{{WP}}} class ({{{wp-includes/class-wp.php}}} which seems to be introduced in either v4.4.0 or 4.4.1 {{{ // check for paged content that exceeds the max number of pages $next = ''; if ( $p && false !== strpos( $p->post_content, $next ) && ! empty( $this->query_vars['page'] ) ) { $page = trim( $this->query_vars['page'], '/' ); $success = (int) $page <= ( substr_count( $p->post_content, $next ) + 1 ); } }}} Removing those lines fixes the issue. What I recommend is that instead of simply checking for the {{{}}} and returning a 404 according to that, we must rather have a check that acts on the amount of pages we have counted immediately after the {{{content_pagination}}} filter and then return a 404 if the current page exceeds the amount of pages after the {{{content_pagination}}} filter" pietergoosen Unpatched Bugs 30631 posts_per_page causing infinite duplicate content Canonical 4.0.1 normal normal defect (bug) new 2014-12-08T20:05:26Z 2019-06-04T19:27:15Z "While using the posts_per_page in the pre_get_posts, if you set it to -1. It will output all the posts. The issue is that if you use this with the main query on a taxonomy archive page, then it will create unlimited number of subpages with all the same content as the main page : taxonomy-1/ taxonomy-1/page/2/ taxonomy-1/page/3/ ... taxonomy-1/page/500/ etc... It is probably not really the expected behavior... " firebird75 Unpatched Bugs 35794 redirect_canonical doesn't strip off custom feed endings Canonical 3.9 normal normal defect (bug) new 2016-02-10T13:54:41Z 2019-06-04T19:34:38Z "The pattern used for matching URL's with feed endings (e.g. /feed/atom/) isn't matching any custom defined feeds. For example, if you add 'json' as a new type of feed, the redirect_canonical function adds up the feed ending to the current request URL. This is caused by fixed regular expressions used to match such feed URL's. These regular expressions should be generated using the $wp_rewrite->feeds variable: {{{#!php $feedssubpattern = implode('|', array_map(function($val) { return preg_quote($val, '#'); }, $wp_rewrite->feeds)); $pattern = '#/(comments/?)?(' . $feedssubpattern . ')(/+)?$#'; }}}" huyby Unpatched Enhancements 35437 dot in permalinks Canonical normal normal Future Release enhancement new 2016-01-13T06:49:02Z 2019-01-08T13:53:11Z "Just try to add dot in request uri (begin or end of any part) – it will return status 200, but should 404 or may be it should redirect to url without dots, otherwise it generates duplicate pages that is not so good. For example. Correct url is http://site.com/some/url/ Let's try: http://site.com/.some/url/ – will return status 200 and open the correct page. The same behavior if: http://site.com/some./url/ http://site.com/some/.url/ http://site.com/some/url./ Temporary solution in functions.php helpful for me: {{{#!php $s) { if( $s[0] == '.' || $s[strlen($s)-1] == '.' ) $parts[$k] = clear_uri($s); } if( $clear_processed ) { $location = '/' . implode('/', $parts) . '/'; header(""Location: "" . $location, true, 301); exit; } }}} " vk_code Tickets Needing Feedback 16133 "Pagination issue with tag ""rss""" Canonical 3.0 normal normal defect (bug) new dev-feedback 2011-01-07T09:39:10Z 2019-06-04T19:22:09Z "When posts use ""RSS"" as a tag, and the /tag/rss/ page has more posts than it is set to display on one single page, the link to page 2: /tag/rss/page/2/ is redirected to: /category/page/2/ Tested on Paolo Belcastro test WordPress.org : http://test.belcastro.com/tag/rss/ Running 3.1-RC2-17229 with only Debug Bar plugin activated This is not theme related, same behaviour with TwentyTen or Thematic on this install." paolal Tickets Needing Feedback 18734 Subcategory archive does work with any name as parent category in URL Canonical 3.0.1 normal normal Future Release defect (bug) new dev-feedback 2011-09-21T15:10:46Z 2022-05-16T02:25:51Z "Parent category is ''parentcategory'' and his sub category is ''subcategory''. The URL will be ''domain.com/category/parentcategory/subcategory''. The problem is, that you will get the same page if you use any words as ''parentcategory''. Examples: - ''domain.com/category/xxx/subcategory'' - ''domain.com/category/subcategory'' - ''domain.com/category/foo/bar/subcategory'' IMO {{{redirect_canonical}}} should do his work here (and sometimes it does). In 3.1 it does redirect. In 3.1.4 it doesn't redirect; after r17549. In 3.2.1 it doesn't redirect. Duck_ found that it does redirect before r18079. In current trunk it doesn't redirect. " ocean90 Tickets Needing Feedback 18385 "Canonical redirections not suited for Queries with multiple query vars and ""pretty permalinks"" in general" Canonical 3.2 normal normal enhancement new dev-feedback 2011-08-12T09:05:03Z 2019-06-04T19:22:40Z "When the Canonical code was originally written, it served it's purpose quite well. However, over the years the number of Query vars which can be used to access content via has increased, and so have the number of archive views. This has lead to increased complexity in the Taxonomy canonical code which has needlessly caused bugs. What I'm proposing, is that it might be time to lay to rest the current `if.. elseif.. elseif..` style checks, It's not possible for 1 if branch to handle every single access point without duplicating another branch. As a result, I've put a half-finished together alternate version of Canonical, It's based on tallying up which query vars have been used/accounted for and removing any duplicates.. It's certainly not the best, but it's fairing better with the unit tests so far. {{{ Unit Testing: http://unit-tests.trac.wordpress.org/browser/wp-testcase/test_includes_canonical.php Before: FF.......FFFF..FFF.....F......FFFFFF.F....F.....FF....FF... After: FF...........FFF..................FF..................F.... }}} It's a work in progress, but it's worth considering IMO. Attaching a diff, and the full file (since the diff is going to be rather unreadable in some sections)" dd32 Tickets Needing Feedback 20283 Create new variable or function in $wp_query object to get canonical URL of any site's page Canonical 3.3.1 normal normal enhancement new dev-feedback 2012-03-22T14:42:36Z 2019-06-04T19:22:53Z "For the sake of Search Engine Optimization it's recommended to set canonical URL inside tag in any site's page. Incorrect URL can exist in search engine index. For example: http://example.com?some_param=some_val&cat=3,4. URL points to categories with id equals 3 and 4, but we have another unnecessary parameter 'some_param'. It's malicious! We must set canonical URL to http://example.com?cat=3,4. So It's advance to have canonical URL generated some way. I propose to set function or variable inside WP_Query class to retrieve canonical URL to any opened page. In WP_Query we have variable WP_Query::query which consists of all necessary parameters for that propose. But we must use $wp_rewrites also. Any thoughts? " egorpromo Tickets with Patches 20388 ?cpage=N URLs do not have canonical redirection Canonical normal normal defect (bug) new has-patch 2012-04-07T05:43:02Z 2019-06-04T19:22:58Z ?cpage=N URLs aren't redirected to their pretty URL counterparts. They should be. markjaquith Tickets with Patches 17661 Appending date & author based query vars to a permalink overrides the permalink Canonical 3.1 normal normal defect (bug) new needs-unit-tests 2011-06-02T11:05:05Z 2019-06-04T19:22:31Z "Some canonical code branches are not properly accounting for extra query variables being specified via the url. For example, these url's are not handled properly: {{{ /2008/?author=1 redirects to /author/admin/ /author/admin/?year=2008 redirects to /year/2008/ /category/uncategorized/?year=2008 redirects to /2008/ }}} This happens with most date based branches, as once a higher priority canonical rule is hit, the permalink component is ignored. The canonical code includes a branch to add any ""forgotten"" `$_GET` variables back onto the url, however this doesn't help when it's the rewritten variables are being lost." dd32 Tickets with Patches 23074 Changing post's URL and then setting it back causes redirect loop (wp_old_slug_redirect) Canonical 3.5 normal major Future Release defect (bug) reopened has-patch 2012-12-29T00:44:50Z 2024-02-17T14:30:35Z This morning, I changed the URL of one of my posts, but then changed my mind and set it back. When you change the URL of your post, WP automatically creates a redirect from the old page to the new page, which is good, but in this case it led to an unintended consequence: after I changed the link from A to B and then back to A, it set up a redirect from A to B and a redirect from B to A, causing anyone trying to access A or B to end up in a redirect loop between the two (or possibly it created a redirect loop from A to A; I'm not sure). It should check for such loops when you update the URL to avoid this problem. vbuterin Tickets with Patches 21602 redirect_canonical can lead to infinite loop on index navigation if site url is not all lower case Canonical normal blocker Future Release defect (bug) assigned needs-unit-tests 2012-08-15T21:31:17Z 2023-04-29T00:09:21Z "The function redirect_canonical in wp-includes/canonical.php (WordPress 3.4.1) on line 406 and 422 makes the following check: {{{ if ( !$redirect_url || $redirect_url == $requested_url ) return false; }}} This ensures that it does not attempt to redirect you to the page you requested in the first place. However this function is not case sensitive so if the redirect URL is in a different case than the requested URL then the user can enter an infinite redirect loop. (For example if the Site Address (URL) of the site is set to be in all upper case.) This function should do a case-insensitive string comparison since domain names are case-insensitive. The issue only appears to happen with certain plugins installed (ShareThis and PilotPress both led to this issue,) I haven't figured out yet why it's only an issue with certain plugins but it should still be fixed in WordPress to make the proper string comparison. " sreedoap Unpatched Bugs 22879 Canonical Link Missing on Front Page Canonical 3.4.2 normal normal defect (bug) new 2012-12-12T11:03:05Z 2019-06-04T19:23:43Z "Canonical links are provided for posts, so if someone links to /2012/12/my-post/?whatever then Google will know it is a duplicate of /2012/12/my-post/ But if someone links to /?whatever there is no canonical address." miqrogroove Unpatched Bugs 14201 Canonical redirect kicks in in case of category/tag base containing other chars then a-z, 0-9, _ and - Canonical normal normal defect (bug) new close 2010-07-05T09:03:39Z 2019-06-04T19:21:57Z "'''Expected behaviour''' Whatever the category base is, if we go to a properly formed category pretty permalink, canonical redirects shouldn't kick in. '''Actual behaviour''' If the category base is non-ASCII (for example: баба), the canonical redirect tries to redirect to the same URL. The redirect sanitizer removes the category base from the URL, because it is non-ASCII and redirects to {{{//category-name/}}}. This prevents endless redirects and usually results in 404. '''Why does it happen?''' Category base is always used verbatim. It can't be URL-encoded, because the percent signs will be interpreted as permalink variables. Because of that the generated urls will be always in the form: {{{/баба//}}}. The contents of {{{$_SERVER['REQUEST_URI']}}} are always URL-encoded, so the requested URI is: {{{/%D0%B1%D0%B0%D0%B1%D0%B0//}}}. Canonical redirect functionality assumes the requested URL would be the same as the generated term URL and since they are different tries to redirect. '''Solutions''' The easiest one is to assume that if we had come to the right category page without any get variables, we don't need the logic for redirecting to the canonical category page. This is valid statement, because that logic relies only on removing get arguments. The only disadvantage with that solution is that doesn't solve the more general problem of discrepancies between generated and requested URLs. But for now it will do a good job." nbachiyski Unpatched Bugs 23602 "Incorrect canonical redirect if p=123 query argument present in ""paged"" archives" Canonical 3.5 normal normal defect (bug) new needs-unit-tests 2013-02-25T08:34:19Z 2019-06-04T19:23:57Z "URLs that include `page/n` AND `p=n` query variable, such as: http://example.com/page/3/?p=123 will issue a 301 redirect to the homepage. This is being reported as incorrect behaviour in Google Webmaster Tools, because: The target URL does not exist and your server is not returning a 404 (file not found) error. Your server is redirecting requests for a non-existent page, instead of returning a 404 response code. This creates a poor experience for searchers and search engines. A fix would be to strip the `p=` query variable and redirect to the paged archive. From: http://example.com/page/3/?p=123 to: http://example.com/page/3/ " kasparsd Unpatched Bugs 35689 Pagination issue on front page after 4.4.1 update Canonical 4.4.1 normal normal defect (bug) reviewing 2016-02-01T14:36:06Z 2019-06-04T19:34:14Z "This is a spinoff of the remainder of #35344. See ticket:35344#comment:60 and on. > It seems to be that the remaining issues being experienced is this scenario, which is sounding like a combination of #35482 and this ticket. > * Static page on front, no posts page defined > * `query_posts()` or `$wp_query = new WP_Query()` used within the template to display the first page of posts > * /page/2/ would then load page 2 of the posts index with no static page in sight. > The problem I face, is that /page/2/ should NOT be the archive of posts, it should be the second page of the static home page (You can paginate posts/pages using the tag in your content). " samuelsidler Unpatched Bugs 21700 Problem obtaining the Feed of an archive of tag “RSS” Canonical 3.4.1 normal normal defect (bug) new 2012-08-27T10:40:33Z 2019-06-04T19:23:18Z "I'm using RSS as a tag for some of my blog posts, and I was using them without any problem. '''myblog.com/tag/rss/''' But I've just realised that Google Webmaster Tools gives me some related errors. The issue is this: when trying to retrieve the feed of this tag, from '''myblog.com/tag/rss/feed/''' it gets redirected to '''myblog.com/tag/feed/''' And this gives an error." xavivars Unpatched Bugs 20386 "Year permalinks ""win"" against category permalinks" Canonical normal normal defect (bug) new needs-unit-tests 2012-04-07T05:20:55Z 2019-06-04T19:22:56Z "We need to decide whether category permalinks should take priority over year permalinks. e.g. /2008/?category_name=cat-a Should that stay the same, or redirect to: /category/cat-a/?year=2008 We have a unit test which is failing." markjaquith Tickets with Patches 20902 redirect_canonical() on using permalink: Not all $_GET being redirected chriscct7 Canonical 3.4 normal normal defect (bug) reviewing has-patch 2012-06-11T09:30:08Z 2019-06-04T19:23:06Z "Using permalink, I suppose that all query_var entered manually on URL or using $_GET will be redirected to proper permalink. Apparently not all being redirected at all. AFAIC: 1. /?post_format=image : should be redirected to /type/image/ 2. /?pagename=blog : should be redirected to /blog/ 3. /?author_name=admin : should be redirected to /author/admin/ Unfortunately, they are not. It can be done by filtering redirect_canonical() but it will be better if it's being done by default as we can see that /?category_name=cat will be redirected to /category/cat/" arieputranto Tickets with Patches 13041 Canonical redirection will redirect a non-exitant page to a post. dd32 Canonical 3.0 normal normal defect (bug) reviewing has-patch 2010-04-18T06:14:20Z 2019-06-04T19:21:48Z "Following on from #12601 Canonical redirection will kick in for http://localhost/wordpress-commit/apage/something and redirect it to http://localhost/wordpress-commit/2010/02/13/something-else/ #12601 limited redirect_guess_404_permalink() to only searching in the same post_type if one was provided, for posts and pages however, which are builtin, these vars are not set. I'm attaching a patch which will prevent a Page -> Post redirection, but not the other way around. - this patch was originally added to the other ticket." dd32 Tickets with Patches 50163 Perform a canonical redirect when paginated states of the front page are not found hellofromTonya Canonical normal normal Future Release defect (bug) assigned needs-unit-tests 2020-05-14T06:44:54Z 2022-04-04T05:37:27Z "As a followup to #45337, [34492], and [47727]. When example.com/ has a static front page assigned and uses `` accessing non-existing pages uses example.com/page/3/ and Canonical won't kick in. This is because paged states of the front page use the `paged` query var, not the `page` query var. Should also fix https://meta.trac.wordpress.org/ticket/5184 :)" dd32 Tickets with Patches 18660 Enhance rel_canonical function, add filter joostdevalk Canonical 3.3 normal normal Future Release enhancement assigned has-patch 2011-09-14T15:59:03Z 2019-10-16T10:07:49Z "I think it's a bit shortsighted to think that only singular pages need the canonical tag output in the ``. Considering the fact that just about any page on your site can be accessed with a malformed URL, I think it's time to enhance this function. The attached patch is just a first pass. But I think it gets us started in the right direction. There's also a filter before output, so themes and plugins can further enhance the output of this plugin (related #14458). Patch is against [438126]." nathanrice Unpatched Bugs 30581 http/https pages have different canonical URLs joostdevalk Canonical 2.9 normal normal Future Release defect (bug) assigned 2014-12-02T22:40:18Z 2019-04-03T12:48:19Z "If you have SSL turned on, but don't force redirect, http and https pages will have different URLs. Ideally, I think the canonical URL should always use http unless `FORCE_SSL` is turned on. Even a filter for `rel_canonical` would be better than what we have now. Unhooking and creating your own version of `rel_canonical()` works, but if multiple plugins do this, you end up with multiple canonical URLs set on every page. Related: #18660, #14458" betzster Unpatched Bugs 11856 URL for 1st comments page is not canonical markjaquith Canonical 3.0 normal normal Future Release defect (bug) new dev-feedback 2010-01-10T19:17:42Z 2023-10-19T20:04:59Z "When WP generates URL for comments, it always includes comments page number. It should not do this when URL is for 1st comments page - in this case post URL is sufficient. WP should also redirect to canonical URL version when someone will try to load URL like site.com/some-post/comment-page-1." sirzooro Unpatched Bugs 10690 WordPress does not support non-ascii characters in the domain name markjaquith Canonical 2.8.4 normal normal defect (bug) reopened needs-unit-tests 2009-08-26T18:26:13Z 2019-06-04T19:21:34Z WordPress' clean_url() strips out most characters, which are non-ascii for security reasons. This is causing problems, if you want to run a WordPress blog on a domain containing non-ascii-characters (e.g. müller.com), because WordPress generates wrong URLs on redirects. paddya Tickets with Patches 44744 Bug on canonical redirect with Hebrew query string. SergeyBiryukov Canonical 4.9.8 normal major Future Release defect (bug) reviewing needs-unit-tests 2018-08-06T14:52:40Z 2019-11-09T10:42:56Z "Hello, Example URL: http://domain.com/?שלום The example comes after having problems with Woocommerce product filters. Line 491-493 in {{{/wp-includes/canonical.php}}} we have this: {{{#!php feeds but this property isn't respected in ""redirect_canonical"" method: http://take.ms/kq0zJ http://take.ms/cbRPm We need there to support custom types too like that for example: http://take.ms/ljija " satantime Tickets with Patches 39827 notice in wp-includes/canonical.php:392 SergeyBiryukov Canonical 4.7.2 normal normal Future Release defect (bug) reopened needs-unit-tests 2017-02-10T02:28:03Z 2024-02-15T09:23:06Z "Hello, We're getting notice in wp-includes/canonical.php:392, but it requires some specific steps to obtain it. Steps: 1. Setup a clean install of WPML 2. Set permalinks to postname without ending slash: /%postname% 3. Create a page in secondary language 4. Set this page as Home Page (under Settings/Reading) but only in the secondary language When you enter ""home page"", you get 404 because a page for original language does not exist. In line 121, you get {{{$redirect_url = get_permalink($redirect_post);}}} and value of $redirect_url is for instance ""http://testsite.dev?lang=fr"". As you see, there is no ""/"" before ""?"", that's why path is empty. You have already fixed the similar issue in line:77-79 {{{#!php // Notice fixing if ( !isset($redirect['path']) ) $redirect['path'] = ''; }}} I suspect, we need the same fix before line: 392 {{{#!php $redirect['path'] = preg_replace('|/' . preg_quote( $wp_rewrite->index, '|' ) . '/*?$|', '/', $redirect['path']); }}} " jakubbis Unpatched Enhancements 4328 Redirect Old Slugs feature needs to redirect slugs for pages, not just posts, and redirect old permalink structure SergeyBiryukov Canonical 2.2 normal normal Future Release enhancement reviewing needs-unit-tests 2007-05-24T01:52:44Z 2022-01-25T14:30:12Z "Create a page, browse to it, edit it, change its slug, WP redirects to the old page's slug and serves a 404. Wasn't WP 2.1 or WP 2.2 supposed to make the redirect old slug feature built-in? Along the same lines, it would be sweet if instead of simply redirect old slugs, WP would redirect old urls. When the date changes, when the page parent changes, or when the permalink structure changes, the url changes but neither of WP, the redirect old slug plugin, the permalink redirect plugin, or anything else catches this." Denis-de-Bernardy Tickets with Patches 28081 Do a canonical redirect for pages when query var 'paged' is set SergeyBiryukov* Canonical normal normal Future Release defect (bug) accepted needs-unit-tests 2014-04-30T19:53:12Z 2023-03-22T13:28:23Z "Example: http://make.wordpress.org/core/features-as-plugins/page/2323/ You can append /page/{any number} to a page and still get the same content as http://make.wordpress.org/core/features-as-plugins/ The same doesn't happen for posts. [source:/trunk/src/wp-includes/canonical.php#L274]: Seems like l274 and l276 should be !is_singular() as it was before [6115]. (Block was changed in [9697].) Want to use this ticket to get some reasons for [6115]. Currently I only can think of custom page templates which are using a custom pagination, so maybe wontfix." ocean90 Unpatched Bugs 53362 Invalid paginated requests not treated as such SergeyBiryukov* Canonical 5.7.2 normal normal Future Release defect (bug) accepted 2021-06-08T20:38:20Z 2023-06-29T18:20:08Z "This is a follow-up to #40773. The security department that scans our WordPress websites identified the issue resolved in #40773 as cross-site scripting, as our themes add the webpage's precise URL to Open Graph data (`og:url`) in the ``. So, we were happy to see the resolutions applied in that ticket. Unfortunately, while testing, we found that adding `/0/` to any URL is still possible, e.g. https://example.com/about-us/0/ does not redirect back to the canonical https://example.com/about-us/. Additionally, we have found that it is possible to append `/page/` followed by a number to the URL of a page that does not support pagination, e.g. https://example.com/about-us/page/0/, https://example.com/about-us/page/12345/, etc. In the latter example, the `` also changes from ""About Us"" to ""About Us – Page 12345"" as WordPress seems to think this is a valid paginated page. The `paged-12345` and `page-paged-12345` classes are also added to the `<body>`. These specific tests were done using the Twenty Twenty-One theme. Furthermore, appending `/page/0/` to the page that displays blog posts does not trigger a 404 or a redirect, e.g. https://example.com/blog/ is ""identical"" to https://example.com/blog/page/0/." daleharrison Unpatched Enhancements 17653 Canonical Redirect when space(s) are used instead of hyphens when requesting a page SergeyBiryukov* Canonical 3.0 normal normal Future Release enhancement accepted 2011-06-02T01:25:08Z 2018-08-19T03:31:39Z "Create a page with a slug that contains a hyphen (eg. /page-name/). If you then visit /page name/ (ie. use a space instead of a hyphen), WordPress currently manages to locate and display the page-name page. This could cause duplicate content issues. The same issue occurs if multiple spaces are used instead of a hyphen. As an example, this is the original page: http://jamesc.id.au/test-page/ This page is accessible via: * http://jamesc.id.au/test%20page/ * http://jamesc.id.au/test%20%20page/ * http://jamesc.id.au/test%20%20%20page/ * http://jamesc.id.au/test%20%20%20%20page/ and so on. WordPress should either output a 404 error, or redirect to /page-name/. Tested using the latest 3.2 trunk (r18110)." jamescollins Unpatched Bugs 30905 Theme Preview - Not working preview when front page setting stevenkword Canonical 4.1 normal normal defect (bug) assigned 2015-01-05T09:24:15Z 2019-06-04T19:27:22Z "I'm sorry if there are already ticket for same problem. Preview is not working well (not live preview/customizer). Is this a bug? or specification? Steps to reproduce: 1. Settings to '''Front page'''(anyting page) and select the '''A static page''' of Front page displays of Reading of Settings. 2. Access the Themes screen of Appearance with Editor(Editor already have capability to switch_themes). 3. Click to the '''preview button''' of per not activated themes. Tested in: Google Chrome 39.0.2171.95 m And I think this happen is affect to following. {{{ wp-includes/canonical.php line 48 - 54 }}} Theme preview is not have post ID. But that it become to have post ID after the Front page settings. And I have tentatively avoiding the problem in this way. {{{ function test_redirect_canonical( $redirect_url , $requested_url ) { if( get_query_var( 'preview' ) && !empty( $_GET['template'] ) && !empty( $_GET['stylesheet'] ) && !empty( $_GET['preview_iframe'] ) ) { if( current_user_can( 'switch_themes' ) ) { $redirect_url = false; } } return $redirect_url; } add_filter( 'redirect_canonical' , 'test_redirect_canonical' , 10 , 2 ); }}}" gqevu6bsiz