[wp-trac] [WordPress Trac] #11863: Trashed items interfere with page/post slug generation

[WordPress Trac]

#11863: Trashed items interfere with page/post slug generation
------------------------------------+------------------------
 Reporter:  Denis-de-Bernardy       |       Owner:  ericlewis
     Type:  enhancement             |      Status:  assigned
 Priority:  normal                  |   Milestone:  4.5
Component:  Posts, Post Types       |     Version:  2.9
 Severity:  normal                  |  Resolution:
 Keywords:  make-flow dev-feedback  |     Focuses:
------------------------------------+------------------------

Comment (by coffee2code):

 Here's my take. Spoiler: I'm currently leaning toward option 3 (though I
 still contend option 1 was the best approach for the ''plugin'' to take).


 '''Option 1:'''

 As that's the approach I took for my plugin, I won't say much more than
 [comment:90 I've done so].

 * '''Action on unique slug generation (as for new post):''' [[br]] Check
 for conflict with trash. If so, give trashed post the new unique slug (but
 record its original) and allow use of desired slug by new post.
 * '''Action when post is trashed:'''[[br]] Nothing (post keeps its slug
 going into trash).
 * '''Action when trashed post is restored:'''[[br]] Check if original slug
 is in use. If not, restore original slug. If so, keep the unique slug it
 already has. No new unique slug regeneration occurs.


 '''Option 2:'''

 My main concern with this approach is the potential for having
 simultaneously existing conflicting slugs (a live post + one or more
 trashed posts). For this specific scope, it may not be an issue, but might
 there be an issue with other code out there that confidently worked
 knowing there would never be a slug conflict like that for posts?

 * '''Action on unique slug generation (as for new post):'''[[br]] Ignore
 posts in trash when checking for conflicts.
 * '''Action when post is trashed:'''[[br]] Nothing (post keeps its slug
 going into trash).
 * '''Action when trashed post is restored:'''[[br]] Check if original slug
 is in use. If not, slug can continue to be used. If so, generate a new
 unique slug via a call to `wp_unique_post_slug()`.


 '''Option 3:'''

 I kinda like this one. It seems more minimal of a change with less
 unexpected side effects.

 * '''Action on unique slug generation (as for new post):'''[[br]] Nothing.
 (`wp_unique_post_slug()` functions unchanged).
 * '''Action when post is trashed:'''[[br]] Change slug to append
 `%trashed%`. We'd either have to permit trashed posts to be able to have
 the same slug (which seems reasonable), or have to find a unique variation
 of the slug at this time (e.g. `about%trashed-2%`).
 * '''Action when trashed post is restored:'''[[br]] Remove `%trashed%`
 from slug and check if that is in use. If not, the post can be restored
 with that slug. If so, generate a new unique slug via a call to
 `wp_unique_post_slug()`.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/11863#comment:95>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform