[wp-trac] [WordPress Trac] #19292: Not found errors due to sanitization in sanitize_title_with_dashes

[WordPress Trac]

#19292: Not found errors due to sanitization in sanitize_title_with_dashes
--------------------------+------------------
 Reporter:  xknown        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.3
Component:  General       |     Version:
 Severity:  blocker       |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------

Comment (by dd32):

 > attachment 19292-dont-update-slug-sanitize-type-on-update.diff  added

 For comparison purposes, here's my thought process for it.

 Put simply: (note: "post" is used here to refer to any post type, This
 ticket is primarily focusing on pages, but posts suffer the same problem,
 canonical just stuck a bit of wallpaper over the crack in the wall)
  * If we've got no slug; it's a new post, it gets new sanitization
  * If we've got a slug; it's either a pre-3.3 post, or a 3.3+ post
   * First of all, check to see if the current slug passed IS the same as
 what would be used for a Query, If it is, it's a post with a older
 (pre-3.3)pre-sanitized name OR the slug sanitizes using both algorithms
 the same OR the name doesn't require sanitization (ie. single word)
   * Otherwise, lets sanitize it using the new 3.3+ stuff

 I believe there's a edge case in there however that I've not accounted
 for, for example, "tricking" it into using the older sanitization by
 altering the the post_name field directly.. while i can't seem to cause a
 problem with that, it feels like it's possilble

 My prime thought process here was: Do not update slugs for existing
 content, Canonical is there to help when the slug was specifically
 changed, but we shouldn't use it to change existing URL's.

 Of course, next time we alter something, my approach may fail once again,
 because we'll have multiple "save" contexts/remove_accent contexts. but
 nacin's approach has a similar problem, the slug sanitization just uses
 the old style for hierarchical post types, rendering any enhancements to
 the slug generation moot, we can add canonicalisation for the pages, but
 this isn't going to help old content, unless we process every page on
 upgrade.

 Ultimately: Nacin's approach feels hacky to me, and something that should
 only be used as a bandaid, but it does prevent yet-another-sanitization-
 type happening to hierarchical post types slugs, allowing for us to have
 easier migrations in the future to a _wp_old_slug/_wp_old_path process for
 pages

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19292#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software