__group__,ticket,summary,owner,_component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
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
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 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,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,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,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
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
Tickets Awaiting Review,44899,redirect_canonical redirects to another URL when it should not,,Canonical,4.9.8,normal,critical,Awaiting Review,defect (bug),new,needs-unit-tests,2018-09-05T14:34:56Z,2018-09-06T07:32:25Z,"Hi,
on a fresh install of WordPress 4.9.8 :
http://sub.yourdomain.com/?xtor=AD-4970-%5BSocial%5D-%5B%5D-%5BPPL%5D-%5BFacebook%5D-%5B228284160&105478095%5D-%5B0%5D
will be redirected to :
http://sub.yourdomain.com/?xtor=AD-4970-%5BSocial%5D-%5B%5D-%5BPPL%5D-%5BFacebook%5D-%5B228284160&105478095]-%5B0%5D
Problem is : it does an 301. And, combined with Facebook mobile on Iphone link to the WordPress, it retries forever. 21 000 hits / 5 minutes on our server. Glad it was strong enough to sustain until we find the bug and temporarily deactivated
{{{
redirect_canonical
}}}
with :
{{{#!php
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,45687,URL params get lost because of canonical redirect on static front page,,Canonical,5.0.1,normal,minor,Awaiting Review,defect (bug),assigned,,2018-12-18T12:13:31Z,2018-12-18T12:24:43Z,"Please see #25143.
A shortcode that changes its output via (prettified) URL params, i.e. `/test/1/`.
Use the shortcode on a **static front page**.
The params are added either with `add_rewrite_rule()` or `add_rewrite_endpoint()`, but **without adding query vars**.
This is basically what the patch in #25143 fixed (3rd param ''false''):
{{{
add_rewrite_endpoint( 'test', EP_PERMALINK | EP_ROOT | EP_PAGES, false );
}}}
However, the later change on line 175 in changeset [36237] causes a request such as `/test/1/` to redirect to `/` **and the shortcode can't work with the param**.
On a side note, adding the params as query vars causes the intended static front page to use the posts template because `is_home()` is ''true''.\\
I understand that if I don't want URL params to modify the query, I should not register them as query vars (see [ticket:25143#comment:21 boonebgorges]). However, the template change feels rather wrong to me, too (see [ticket:25143#comment:20 mordauk]).
Thanks for listening.",captain.crash
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 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 Awaiting Review,42423,Warning in redirect_guess_404_permalink if $query->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 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
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,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,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
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
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 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 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
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,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,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
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,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,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,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,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
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
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,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 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,36355,Article URL redirects no longer working,,Canonical,4.0,normal,normal,,defect (bug),new,,2016-03-28T15:20:39Z,2019-06-04T19:35:41Z,"On multiple sites, we have started using article URLs with the post ID in them. Historically, this has allowed WordPress to find the post and do a 301 redirect when the slug, date, or other parts of the URL path changed.
For example, Permalink - %year%/%vertical%/%category%/%postname%-%post_id%/
All of these URLs should redirect us to this article: http://variety.com/2016/tv/news/the-loud-house-premiere-date-video-nickelodeon-1201740128/
http://variety.com/2015/tv-news/news/the-loud-house-premiere-date-video-nickelodeon-1201740128/
http://variety.com/2015/tv-news/news/test-url-slug-1201740128/
http://variety.com/the-loud-house-premiere-date-video-nickelodeon-1201740128/
http://variety.com/2016/the-loud-house-premiere-date-video-nickelodeon-1201740128/
While the first 2 examples work correctly, the last 2 URLs land on 404 page inspite of correct %pagename%-%post_id% combination.
If we have Permalink - %year%/%vertical%/%category%/%postname%/
The last 2 structure work correctly and reach correct article page. For example - http://hollywoodlife.com/2016/03/28/lip-sync-battle-the-walking-dead-sasha-vs-maggie-video/
http://hollywoodlife.com/lip-sync-battle-the-walking-dead-sasha-vs-maggie-video/
http://hollywoodlife.com/2013/lip-sync-battle-the-walking-dead-sasha-vs-maggie-video/
Since we have a correct %postname%-%post_id% combination in the first Permalink structure URL, we should be able to reach the correct article page in the last 2 examples there too.
",archanamandhare
Unpatched Bugs,36873,"Canonical redirect code does opposite of comment, breaks script when home_url starts with https",,Canonical,4.5.2,normal,normal,,defect (bug),new,,2016-05-18T03:43:01Z,2019-06-04T19:37:46Z,"The comment on line 444 in wp-includes/canonical.php says that it only changes the host if it's adding or removing ""www."". It changes the host to lowercase if capitalization is the only difference or if the change is NOT adding or removing ""www."". Either the comment or the code should be changed.
This is causing a problem when I try to run the script below. If the home url (used on line 176) is ""https://www.example.com/"", then the host is removed and redirect url changes to ""https:///"". This makes the parse_url call on line 69 return false and end processing.
I believe this is why the script fails. There's a lot of code here. Apologies if I have it wrong.
Here's the script:
define('WP_USE_THEMES', true);
require_once('/var/www/html/wp-blog-header.php');
I can workaround the bug by explicitly setting some server variables before calling that code:
$_SERVER = array (
'REQUEST_URI' => '/',
'HTTPS' => 'on',
'HTTP_HOST' => 'www.example.com',
);",thasmin
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
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
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,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
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
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
Tickets Awaiting Review,50065,Load balancers forwarding host header with port and redirect loop,,Canonical,,normal,normal,Awaiting Review,defect (bug),new,,2020-05-03T05:44:47Z,2020-05-03T10:05:07Z,"When running wordpress behind oracle cloud load balancer (ssl terminated there) redirection loop happens. After debugging its found oracle load balancer is appending port in host header.
eg for https://testwp.mydomain.com
request host header from load balancer is : https://testwp.mydomain.com:443
this causes redirect loop. Debugged issue to wp-includes/canonical.php
Fixed by adding `$_SERVER['HTTP_HOST']= 'testwp.mydomain.com'` in wp-config
Please find the attached screen shots
",priyanr
Tickets Awaiting Review,50084,redirect_canonical() need additional hook,,Canonical,,normal,normal,Awaiting Review,defect (bug),new,,2020-05-04T18:52:25Z,2020-05-05T11:18:25Z,"There is no hook in [redirect_canonical()](https://wp-kama.ru/filecode/wp-includes/canonical.php#L12-625) function that allow as to extend it's logic.
For example, I have the following permastructure `/%post_id%/%post_name%`. And I can visit the post by such URL `/123`. But I need the redirect to right URL `/123/postname`.
And if I try to use the `redirect_canonical` hook to fix this BUG, the hook won't work, because it's too late and the hook is never triggers.
At the bottom of the function [we have such code](https://wp-kama.ru/filecode/wp-includes/canonical.php#L572-605):
{{{#!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,49369,redirect_canonical() should strip trailing protocols,,Canonical,5.3.2,normal,major,Awaiting Review,defect (bug),new,needs-unit-tests,2020-02-05T11:23:02Z,2020-07-20T12:33:35Z,"I was crawling some of my sites as I was setting up SEO strategies and found really odd 301 redirects on all tested sites.
1. https://domain.com/http:// redirects to https://domain.com/http:/ (one forward slash less). So it's basically a nonexistent page redirecting to another nonexistent page
2. To figure what could be causing this I needed to check if this was happening to just this site or others. I discovered that all sites suffered the same issue regardless of host or webserver stack.
3. Wondering if Cloudflare a common plugin was causing it, I unproxied and entered all the sites in dev mode and had all plugins disabled and the problem still persists
Spiders/crawlers pick this up - appending http:// to end of root URLs manually is not required.
This issue persists - likely a bug in WordPress redirect API. Anybody care to replicate and confirm? Is this a bug?
",onlyonemj
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,51348,Trailing slash redirect removes pipes from query strings,,Canonical,5.5.1,normal,normal,Awaiting Review,defect (bug),new,,2020-09-18T15:31:29Z,2021-03-18T06:58:36Z,"We are using some query strings for tracking and campaign purposes and some of them contain pipes.
An example:
{{{https://example.com/page?key=value1|value2}}}
When using one of the template permalinks a trailing slash is added at the end and WordPress will redirect from non trailing slash url to a trailing slash one. Same goes the other way around when a custom permalink is set without a trailing slash and an url with a trailing slash is accessed.
We noticed, that during this redirect all pipes in the query string are lost/removed/stripped.
The example above will result in:
{{{https://example.com/page/?key=value1value2}}}",simjost
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,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,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 with Patches,12456,Canonical URL redirect issue with post_id/postname permalink structure,SergeyBiryukov,Canonical,2.9.2,normal,normal,Future Release,defect (bug),reopened,has-patch,2010-03-02T14:06:38Z,2021-08-04T18:32:02Z,"The issue:
Using /%post_id%/%postname%/ as permalink structure,
Most canonical redirects work fine, except:
domain.com/post_id/ brings you to the post but does not redirect to the canonical domain.com/post_id/postname/
Additional info:
The above permalink structure conforms to best practice as described in the codex:
http://codex.wordpress.org/Using_Permalinks#Structure_Tags
Therefore I figured this was a bug, given the attention given to redirecting to the canonical url ""So to avoid confusing search engines and to consolidate your rankings for your content, there should only be one URL for a resource.""
http://markjaquith.wordpress.com/2007/09/25/wordpress-23-canonical-urls/
",Frank.Prendergast
Tickets Awaiting Review,51733,redirect_canonical unneeded redirect,,Canonical,3.3,normal,minor,Awaiting Review,defect (bug),new,,2020-11-09T18:27:18Z,2021-08-25T13:38:31Z,"Recently caught an unneeded redirect in `redirect_canonical`. Started caching responses, and ended in a redirect loop.
tl;dr
Per [https://tools.ietf.org/html/rfc3986#section-2.2 RFC3986], `+` is a reserved character, and we should use `%20` to encode a space in URLs (percent encoding).
Per [https://tools.ietf.org/html/rfc1866#section-8.2.2 RFC1866], encode query args as `application/x-www-form-urlencoded` in which case a space is encoded as a `+`.
Posting here to discuss whether we want to fix this in core, or simply leave it as is.
To reproduce:
- Use any `twenty{year}` theme
- Customize homepage
- Select `A static page`
- Visit homepage with query args, e.g. https://vubuesinessplantest.help/?test=a+b+c
- A redirect occurs to https://vubuesinessplantest.help/?test=a%20b%20c
Considering we're using `parse_str()` to parse query variables, and it correctly parses both RFCs I'd argue we shouldn't redirect in the case when query args are the same.
Here's a filter I've written to skip redirects in this case:
{{{#!php
` 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 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 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 with Patches,43539,Custom feed types breaks redirect_canonical behavior,SergeyBiryukov,Canonical,4.9.4,normal,normal,Future Release,defect (bug),reviewing,has-patch,2018-03-13T15:54:47Z,2022-11-01T03:24:16Z,"Hi.
There's plugin ""fb-instant-articles"" which adds ""instant-articles"" feed type for facebook.
final url looks like http://localhost/feed/instant-articles.
But because ""redirect_canonical"" doesn't respect custom feed types it triggers 301 redirect to http://localhost/feed/instant-articles/feed/instant-articles/.
""instant-articles"" is registered with $wp_rewrite->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 Awaiting Review,49220,rel_canonical generates the wrong canonical structure for paginated pages.,,Canonical,4.6,normal,normal,Awaiting Review,defect (bug),new,,2020-01-17T17:31:20Z,2022-11-04T14:57:35Z,"`rel_canonical` is responsible for generating canonical permalink structures for pages. For example, when visiting the WordPress.org homepage, the canonical permalink is set to `https://wordpress.org/`.
`rel_canonical` has some built in handling of paginated page structures, but this does not seem to be doing the correct thing.
A paginated page has the url structure of `https://example.com/page/2`. However, on this page the canonical tag would be output as:
``
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,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,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
`.
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 ``. 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
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 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
''/%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 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
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 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 Awaiting Review,60721,redirect_canonical suddenly causes issues with paramter values and CDN,,Canonical,6.4.3,normal,minor,Awaiting Review,defect (bug),new,,2024-03-07T07:31:07Z,2024-03-07T07:31:07Z,"Hi there,
I was just wondering if anything has changed regarding https://developer.wordpress.org/reference/functions/redirect_canonical/?
`https://some-domain.tld/?my_param=a+a`
triggers a 301 redirect to
`https://some-domain.tld/?my_param=a a`
Now our CDN is set to pass URLs with `my_param` straight on to WordPress. Since that response with a 301, that's what gets cached by the CDN and causes a redirect loop.
Is that something new? I hadn't had that issue before, but also not 100% sure if I sent a value like ""a+a"" before. Trying to figure out why this redirect loop happens now after years.
I'll leave that ticket to be a bug, but if nothing has changed in redirect_canonical() then I guess it can just be closed.
Thanks for your help.",retrovertigo