WordPress.org

Make WordPress Core

Opened 9 years ago

Last modified 2 years ago

#9825 assigned enhancement

Enforce permalink history, outright

Reported by: Denis-de-Bernardy Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.8
Component: Permalinks Keywords: needs-patch dev-feedback needs-unit-tests
Focuses: Cc:

Description

currently, we enforce old slugs and www pref (not even sure that works, since I ended up fixing it in a plugin). canonical doesn't work for pages, or hardly.

we should enforce permalink history, outright. store it in a a db field, and query against it to optimize url2post().

Change History (21)

#1 follow-up: @Denis-de-Bernardy
9 years ago

  • Component changed from Canonical to Permalinks
  • Owner changed from markjaquith to ryan

see also #6603 and #9824, the many tickets related to permalinks not being international compliant (#9591), and many others.

I don't mind tackling this one since it's a plugin I had in mind. But it's going to be a rather huge patch, complete with schema changes, and the odds are it'll become stale almost on the spot. So I'd like some kind of explicit dev-feedback over here saying "yes", to make sure I'm not wasting my time if I spend a couple days on it. So it needs to be early 2.9 (or early 3.0) and get committed on the spot or nearly so when ready.

Likely needed prerequisites (which I'd tackle at the same time):

  • generalized meta table (#5183, so as to store taxonomy meta)

#3 @Denis-de-Bernardy
9 years ago

  • Milestone changed from Future Release to 2.9
  • Owner changed from ryan to Denis-de-Bernardy
  • Status changed from new to accepted

#5 in reply to: ↑ 1 @mikeschinkel
9 years ago

Replying to Denis-de-Bernardy:

Will you implement in such a way that a plugin that implements fully-custom URLs will not be hampered by this update and will also be able to hook in and submit it's older URLs?

I have a plugin I've built that handles fully custom URLs based on post slug (mostly to support custom post types) and I want to ensure that it won't break and can also be able to record obsolete URLs for redirection.

#6 follow-up: @Denis-de-Bernardy
9 years ago

@mike: Dunno... Just for reference, what I'd like to do is add some extra meta:

On display with permalinks active, store the permalink in meta for future reference in case it's not in the meta already. In such a case, scan post_meta for other occurrences of this permalink. On conflict, delete the older one in order to give pre-eminence to the newer data.

(It's worth discussing doing the same for unpaged taxonomy and author pages as well.)

On 404, the canonical redirect would then scan old permalinks in case the REQUEST_URI is a known one, and redirect with a 301 code if a piece of data is found.

So, basically the same as what's done with the old_slug meta, except that it would work for anything stored in the posts table (rather than merely posts), and that it would work when the post's date changes, when a page's parent changes, when the site's permalink structure changes, etc.

Anyway, I'm assuming your plugin would continue to work fine as long as WP isn't returning a 404 error when your data gets called.

#7 @dd32
9 years ago

I'd personally like to see this take the route of an established plugin being included in core rather than a new item built.. Or at least, A looking at existing plugins, and deciding to go from scratch if theres a real reason to.

#8 @Denis-de-Bernardy
9 years ago

@dd32: What I'm described above is what's being done in an existing plugin. It's not very well written, though. Or rather, it wasn't when I checked over a year and a half ago.

#9 in reply to: ↑ 6 @mikeschinkel
9 years ago

Replying to Denis-de-Bernardy:

On display with permalinks active, store the permalink in meta for future reference in case it's not in the meta already. In such a case, scan post_meta for other occurrences of this permalink. On conflict, delete the older one in order to give pre-eminence to the newer data.
So, basically the same as what's done with the old_slug meta, except that it would work for anything stored in the posts table (rather than merely posts), and that it would work when the post's date changes, when a page's parent changes, when the site's permalink structure changes, etc.

Hmm. So only URLs that have a corresponding entry in wp_posts? While most of what I used it for are URLs for custom post types I do have URLs that are completely
virtual. It would be nice to preferable to have a list of links rather than have it be required to be associated with a post.

#10 follow-up: @Denis-de-Bernardy
9 years ago

... or a hook that you could use to plug your virtual urls into.

#11 in reply to: ↑ 10 @mikeschinkel
9 years ago

Replying to Denis-de-Bernardy:

... or a hook that you could use to plug your virtual urls into.

Oh yes, of course.

#12 @Denis-de-Bernardy
9 years ago

  • Owner Denis-de-Bernardy deleted
  • Status changed from accepted to assigned

#13 @Denis-de-Bernardy
9 years ago

  • Type changed from enhancement to task (blessed)

#14 @matt
9 years ago

  • Type changed from task (blessed) to enhancement

#15 @sivel
9 years ago

  • Cc matt@… added

#16 @scribu
8 years ago

  • Cc scribu@… added
  • Keywords needs-patch dev-feedback added

#17 @ryan
8 years ago

  • Milestone changed from 2.9 to Future Release

#18 @hakre
7 years ago

Related: #15140

#20 @chriscct7
3 years ago

The downside to this seems to be if you run a large site, like Time magazine or something and you start storing tens of millions of history URLs, you will start exponentially slow down load time. While its a nice to have feature, any patch that's brought forth for this would need to be extremely well tested for performance

#21 @chriscct7
2 years ago

  • Keywords needs-unit-tests added
Note: See TracTickets for help on using tickets.