Opened 4 years ago
Last modified 8 months ago
#51725 new defect (bug)
Canonical redirect and user_trailingslashit()
Reported by: | mbis | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | trivial | Version: | 5.5.2 |
Component: | Canonical | Keywords: | has-patch needs-unit-tests |
Focuses: | Cc: |
Description
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 function disable_feed() { if(is_feed() && is_front_page()) { redirect_canonical(); } } add_action('template_redirect', 'disable_feed', 1);
Now, when one tries to access the feed URL linked to front page, (eg. http://example.com/feed), the above hook will be triggered and visitor redirected to the canonical URL (http://example.com/feed => http://example.com).
The problem is that the PHP notice is displayed then:
<b>Notice</b>: Undefined index: path in <b>/var/www/vhosts/maciejbis.net/example.com/wp-includes/canonical.php</b> on line <b>576</b><br />
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
$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 '/':
$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:
if ( $wp_rewrite->use_trailing_slashes ) {
$string = trailingslashit( $string );
} else {
$string = untrailingslashit( $string );
}
can be replaced with:
if ( $wp_rewrite->use_trailing_slashes ) {
$string = trailingslashit( $string );
} else if ( $string !== '/' ) {
$string = untrailingslashit( $string );
}
Attachments (1)
Change History (6)
This ticket was mentioned in PR #705 on WordPress/wordpress-develop by maciejbis.
4 years ago
#1
- Keywords has-patch added
Both code changes should prevent malformed output of _user_trailingslashit()_ function when the input value is a single slash:
$foo = user_trailingslashit('/');
This is the case, when the trailing slashes are removed from WP permalinks:
$wp_rewrite->use_trailing_slashes = false
and _redirect_canonical()_ function is used to force the canonical redirect on front page.
Trac ticket: https://core.trac.wordpress.org/ticket/51725
github-actions[bot] commented on PR #705:
4 years ago
#2
Hi @maciejbis! 👋
Thank you for your contribution to WordPress! 💖
It looks like this is your first pull request, so here are a few things to be aware of that may help you out.
No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description.
Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this one mirrors. But please feel free to use pull requests to work on any contribution you are making.
More information about how GitHub pull requests can be used to contribute to WordPress can be found in this blog post.
Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook.
If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook.
The Developer Hub also documents the various coding standards that are followed:
- PHP Coding Standards
- CSS Coding Standards
- HTML Coding Standards
- JavaScript Coding Standards
- Accessibility Coding Standards
- Inline Documentation Standards
Please remember that the WordPress project is largely maintained by volunteers
Thank you,
The WordPress Project
#3
@
4 years ago
- Component changed from Permalinks to Canonical
- Focuses performance coding-standards removed
- Keywords needs-unit-tests added
#4
@
3 years ago
This was the fix in my case, I'm using relative permalinks without trailing slash.
<?php add_filter( 'redirect_canonical', function( $redirect_url, $requested_url ) { $redirect = parse_url( $redirect_url ); $requested = parse_url( $requested_url ); // Prevent redirect to exact same page if ( strtolower($redirect['path']) == strtolower($requested['path']) ) { return false; } }, 101, 2 );
Permalink settings