safe-redirect-manager
safe-redirect-manager copied to clipboard
Allow response codes 400 and up
Use wp_safe_redirect, but actually allow response code of 400 and higher. Redirect will not happen. Related to https://github.com/10up/safe-redirect-manager/issues/205
Description of the Change
This will send custom HTTP response following code base of wp_safe_redirect. But will actually allow 400+ response codes
Alternate Designs
no other options since WordPress core is limited to 300-399 response codes.
Benefits
This will allow main response code of 410 Gone to send signal to google that page were actually removed.
Possible Drawbacks
Require manual update in case WordPress function wp_safe_redirect() will get updated.
Verification Process
- How did you verify that all new functionality works as expected?
tested code on development website
- How did you verify that all changed functionality works as expected?
tested responses higher than 399
- How did you verify that the change has not introduced any regressions? It is new
Checklist:
- [ x ] I have read the CONTRIBUTING document.
- [ x ] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my change.
- [ ] All new and existing tests passed.
Applicable Issues
https://github.com/10up/safe-redirect-manager/issues/205
Changelog Entry
add custom http response
I incorporated the changes noted above into my local copy of the plugin, but it does not redirect to another page for any of the 4xx statuses - it simply shows the default browser status message. For pages with a 4xx status, I would expect that if a user went to that page, they should see an error page, similar to how the default 404 behavior is handled in wordpress using the 404.php
template.
I have modified the above code to produce this behavior. This requires further modification to actually include some default 4xx.php
templates in the plugin, but I have written it so that if there isn't a template, you get a simple error message. I am providing a 410.php
template in my theme.
if ( in_array( $matched_redirect['status_code'], srm_get_valid_status_codes(), true ) ) {
if ( $matched_redirect['status_code'] > 399 ) {
$status = $matched_redirect['status_code'];
if ( ! $is_IIS && 'cgi-fcgi' !== PHP_SAPI ) {
status_header( $status ); // This causes problems on IIS and some FastCGI setups.
}
//display an error template based on the status
if( ! locate_template( $status.'.php', true ) )
echo 'Sorry, the page you requested has been permanently removed.';
exit;
} else {
wp_safe_redirect( $matched_redirect['redirect_to'], $matched_redirect['status_code'] );
exit;
}
} else {
wp_safe_redirect( $matched_redirect['redirect_to'] );
}
@aosmichenko Thanks for the PR! This looks like a good start to me but I think there's some changes we need here. Let me know if you're still interested in working on this or if you'd like me to finish this off.
If someone is using these 4** status codes, we don't actually want to redirect, we want to either output an error message or render a template that can have a message (and ensure we output the right status code in both instances). There some good direction in the comment from @okadots, so I'd recommend looking at that.
Looking at your code, we can get rid of anything that looks at the $location
, since we aren't going to be redirecting. I think we can also get rid of the filters around the location and status params, since I don't think those will be needed either.
In short, if the status code is above 399, we want to output the right status code and then try loading a template. If that template doesn't exist (open to suggestions on if we should add templates to our plugin or just rely on those templates being added to themes), we should output an error message and ensure that message has a filter around it so it can be easily changed.
Closing in favor of #300.