[wp-trac] [WordPress Trac] #47988: Unexpected behaviour when draft post has the same page_name as published post

[WordPress Trac]

#47988: Unexpected behaviour when draft post has the same page_name as published
post
-------------------------------------------------+-------------------------
 Reporter:  ajfleming                            |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Posts, Post Types                    |     Version:  2.8
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-test-info has-    |     Focuses:
  patch has-unit-tests needs-testing             |
-------------------------------------------------+-------------------------
Changes (by jesusinica):

 * keywords:  good-first-bug has-test-info has-patch has-unit-tests => good-
     first-bug has-test-info has-patch has-unit-tests needs-testing


Comment:

 After investigating, I've chosen to implement solution #3 from
 @paulbonneau's analysis
 (fixing at the query level rather than modifying wp_unique_post_slug).

 Reasons for this approach:
 - It doesn't break existing behaviours that plugins/themes rely on
 - It doesn't modify how draft posts store their post_name
 - It specifically fixes the symptom (wrong post returned) without changing
 the slug
   lifecycle that has been stable for many years
 - It's less risky/invasive than modifying wp_unique_post_slug behavior

 The PR modifies WP_Query to prefer published posts when resolving singular
 slug
 queries without explicit post_status.

 Regarding the related tickets @SirLouen mentioned:
 - #61996: Has its own PR (#9675) addressing get_page_by_path() - different
 function
 - #47552: Race condition on insert - different problem, needs separate
 solution
 - #39942: Slug stealing on restore - different problem, needs
 wp_unique_post_slug fix

 I believe this ticket can be resolved independently with PR #10759.

 Does this approach work for you, @SirLouen, or would you prefer I pursue
 one of the other solutions?

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