[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:
     Type:  enhancement              |      Status:  reopened
 Priority:  normal                   |   Milestone:  Future Release
Component:  Trash                    |     Version:  2.9
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch ux-feedback  |
-------------------------------------+-----------------------------

Comment (by johnbillion):

 I'd like to ask that this issue be revisited. Granted, it's not a major
 issue, but it's a frustrating one for users when it happens.

 As Westi pointed out, this was discussed at length by the core devs,
 however this discussion now took place two years ago. WordPress is in a
 much stronger position to test UX issues than it was two years ago and
 maybe in the intervening two years some core devs have noticed this issue
 and how counter-intuitive it is.

 The reason I'd like to revisit the issue is this.

 '''Scenario A:''' A user trashes a page with slug xyz, attempts to create
 a new page with slug xyz, ends up with xyz-2 and gets confused. "Damnit, I
 just deleted the page called xyz, why can't I create it again?"

 The reason this happens is because we are reserving the trashed post's
 slug solely in case the post is subsequently restored from the trash. Due
 to the "perma"-ness of a permalink, it is considered that a restored post
 should not have its slug changed under any circumstance.

 '''Reality check:''' How likely is the following scenario compared to
 Scenario A?

 '''Scenario B:''' A user trashes a page with slug xyz, creates a new page
 with slug xyz, then subsequently un-trashes the original page with slug
 xyz (''and'' expects it to still be available at its original permalink).

 Yes of course it can happen, but in reality the frequency with which that
 happens is vastly smaller than Scenario A.

 The current situation is addressing a situation where trashed posts should
 have preference over newly-created posts with the same slug just in case
 it's ever subsequently restored, rather than the far more common situation
 where a post is trashed and then someone attempts to create a new post
 with the same slug.

 My opinion is that the current behaviour chooses to addresses an edge case
 rather than addressing a more common scenario, and this should be changed
 in order to improve UX. Trashed post slugs should not be taken into
 consideration when creating new posts. In the uncommon scenario where a
 user attempts to restore a post which shares the same slug as a
 subsequently created post, they should be notified. In addition, there
 could be a notice displayed below such posts when viewing the Trashed
 posts screen.

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