Opened 17 years ago
Last modified 3 years ago
#4328 reviewing enhancement
Redirect Old Slugs feature needs to redirect slugs for pages, not just posts, and redirect old permalink structure
Reported by: | Denis-de-Bernardy | Owned by: | SergeyBiryukov |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 2.2 |
Component: | Canonical | Keywords: | needs-unit-tests needs-patch early |
Focuses: | Cc: |
Description
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.
Attachments (4)
Change History (67)
#3
@
17 years ago
- Milestone changed from 2.2.2 to 2.4
- Type changed from defect to enhancement
WP 2.1+ has it built in, but it only works with posts (by design). I just tested it on Trunk and 2.2, and it works as expected for posts.
Having it work for pages or having it track more than slug changes would be a new feature, so it doesn't belong in a 2.2.x release.
#4
@
17 years ago
- Summary changed from redirect old slug feature is very broken to Redirect Old Slugs feature needs to redirect slugs for pages, not just posts, and redirect old permalink structure
#9
@
15 years ago
- Component changed from Permalinks to Canonical
- Owner changed from ryan to markjaquith
#10
@
15 years ago
- Milestone changed from 2.9 to Future Release
As we are now feature frozen it is too late to include this into 2.9.
Moving to Future Release as there is currently no patch.
#11
@
15 years ago
4328.diff turns old slug redirect on for pages.
Two line patch seems to work fine... what are the edge cases?
Works with top level pages and child pages.
#12
@
15 years ago
comment:ticket:3202:2 by markjaquith says
Only works on posts. There doesn't seem to be a clean way of recognizing failed Page attempts... of course there is always my "Page Links To" plugin to take care of that. ;-)
Quote is 3 years old. Either there are some cases I didn't think of or it's no longer true :)
#14
@
15 years ago
The only side effect to this would be creating a page AND post of the same name, and then renaming one or both of them.. It might not have the intended path to follow through?
#19
@
14 years ago
According to Denis' comment on #15140:
If both the slug and the parent change, the redirect doesn't work.
However it seems to be working on current trunk (with the refreshed patch).
#23
@
12 years ago
Just stumbled upon this once again. I thought that _wp_old_slug
works for pages as well.
This ticket was mentioned in Slack in #polyglots by sergey. View the logs.
7 years ago
This ticket was mentioned in Slack in #core-editor by swissspidy. View the logs.
7 years ago
#30
@
7 years ago
This is still needed. It's confusing to have different behaviors for posts and pages. A setting to be able to turn this off would be good also.
10 years and counting...
#31
follow-up:
↓ 33
@
7 years ago
It's about time that this happens - does anyone want to pick this up and own it?
@SergeyBiryukov 4328.patch seems like it's really the only thing needed here (I've not looked into it) do you have any interest in running with this?
#33
in reply to:
↑ 31
@
7 years ago
- Keywords needs-patch added; has-patch needs-refresh removed
Replying to dd32:
4328.patch seems like it's really the only thing needed here (I've not looked into it)
I've been thinking about this, with an intent of trying some code out, however I think i should also note here this thought:
- For hierarchical post types, the
_wp_old_slug
value should be the full hierarchical path, for example, given/foo/bar/
and/bar/
being moved to/subpage/foo/bar/
and/subpage/bar/
respectively, I'd expect/foo/bar/
and/bar/
to redirect to the correct locations.
The current patch doesn't do that, as it'd only store bar
for both of these pages (Well, it wouldn't actually, as it only compares on slugs, but ignoring that..)
#34
@
7 years ago
Very interested in seeing this happen. I'd like to give it a shot. Will send something in tomorrow, probably.
#35
@
7 years ago
Related to what these guys are doing #15953 I hope we don't clash, especially with exotic rewrite rules, parent page structures, etc.
Here's a refresh that allow all custom post types through, not just pages.
I'm sure there are edge cases, but let's just get things going. We'll need a lot of new tests.
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
6 years ago
This ticket was mentioned in Slack in #core-php by sergey. View the logs.
6 years ago
#40
@
6 years ago
- Owner changed from markjaquith to SergeyBiryukov
- Status changed from new to reviewing
This ticket was mentioned in Slack in #core-docs by skorasaurus. View the logs.
6 years ago
This ticket was mentioned in Slack in #core by skorasaurus. View the logs.
6 years ago
#44
@
6 years ago
This ticket's original description is from 12 years ago and WordPress has changed since then and what was in the original description is no longer applicable.
WordPress will redirect from a page's old slug (post-name) to its current slug (post-name) in the following scenarios:
when the slug is changed;
when a page has a changed parent page
when the parent's page slug is changed.
when a parent page is added.
when its parent page is made to have another parent page.
I've only (manually) tested this on the post_type of 'page' and when the permalink setting (wp-admin/options-permalink.php) is set to post-name.
The scenarios where redirection will not work and what made me find this ticket are:
- when a page is added to have a 3rd parent page.
For example, a page with the slug of "3d-printing" and has two levels of parent pages (so its full url is: "subjects/technology/3d-printing/" is made to have a 3rd parent page (the new url is "library/subjects/technology/3d-printing/") ;
the redirect will not occur, and the user receives a 404.
- when a page with 2 parents is renamed
Example: a page with the slug 'book-club' and previous had 2 levels of parent pages (e.g. about/special-library/book-club) is renamed to "about/special-library/special-book-club"
The redirect is not made; and the user receives a 404.
This ticket was mentioned in Slack in #meta by dd32. View the logs.
5 years ago
#46
@
4 years ago
+1 for reviving this issue.
+1 for adding this functionality to all post types.
Either this or #9825 - keep a permalink history for posts. Not just slugs but the full hierarchical path too.
WP routing could really use some love.
This ticket was mentioned in Slack in #meta by sergey. View the logs.
4 years ago
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
4 years ago
#49
@
4 years ago
Can we revive the issue? We are looking into a new classification for end user documentation and we have several pages that will need to be redirected
This ticket was mentioned in Slack in #meta by estelaris. View the logs.
4 years ago
This ticket was mentioned in Slack in #docs by estelaris. View the logs.
4 years ago
This ticket was mentioned in Slack in #docs by dd32. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by estelaris. View the logs.
3 years ago
This ticket was mentioned in Slack in #docs by estelaris. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
3 years ago
#58
@
3 years ago
- Keywords early added
This ticket needs to be committed early
in a release cycle. Moving to Future release and adding early
keyword.
#60
@
3 years ago
This has already been pushed back in 2 releases and it is a blocker for the work on end-user documentation.
@SergeyBiryukov @audrasjb @dd32 please someone help with a patch.
#61
@
3 years ago
Additionally, a patch needs to be ready early
in the future release cycle so it has time to be properly tested.
adding to the above, the workflow would be:
on post save, cache the url in a custom field. if url is different, append previous value to the old urls.
on permalink structure change, do the above for every post and page on the site.
extra benefit: scanning for which post is requested can be simplified in many cases to something like: select from posts inner join postmeta where url_cache.
D.