[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 needs-unit-tests      |     Focuses:
  needs-patch has-test-info                      |
-------------------------------------------------+-------------------------
Changes (by SirLouen):

 * keywords:   => good-first-bug needs-unit-tests needs-patch has-test-info
 * version:   => 2.8
 * milestone:  Awaiting Review => Future Release


Comment:

 == Reproduction Report
 === Description
 ✅ This report validates that the issue can be reproduced.

 === Environment
 - WordPress: 6.9-alpha-60093-src
 - PHP: 8.2.29
 - Server: nginx/1.29.1
 - Database: mysqli (Server: 8.4.6 / Client: mysqlnd 8.2.29)
 - Browser: Chrome 140.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.3
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.0

 === Testing Instructions
 Use the instructions provided in the OP

 === Actual Results
 1.  ✅ Error condition occurs (reproduced).

 === Additional Notes

 This can be tracked down to #9726/[11467]. We don't have a pinch of
 context of why it was decided to add this here. 16 years later, things
 have changed massively, and this has been left behind. Looking at the
 current unit tests, they were published in #5305/[32604]. Browsing through
 the ticket, I cannot really see a single reference to the particular unit
 test that is actually testing this:
 `test_whitelisted_post_statuses_should_not_be_forced_to_be_unique`

 This brings me to a question: Why provisional post statuses (draft, auto-
 draft and pending) were meant to not be forced to be unique? Isn't this
 causing the conflict? I'm assuming that probably in the origin, they were
 expecting that permalinks were not considering provisional posts, hence
 not using the slug. That could be a fix in the permalinks section.

 But there is another take, like @ajfleming suggests: when creating this
 through the admin interface, provisional posts are saved without a
 `post_name`. So I think we should expect the same behaviour in this
 particular case. On the provisional posts, since `post_name` is expected
 to be empty, Gutenberg picks the potential slug from the post, but this
 doesn't mean that the `post_name` gets stored.

 Reviewing the idea of the patch
 [https://core.trac.wordpress.org/attachment/ticket/47988/47988-20190906-1249.diff
 47988-20190906-1249.diff], looks good at first.

 The problem is that this conditional encompasses several scenarios, not
 only the three provisional statuses, but also post types like "revision",
 which actually have a preset slug, and other exotic post types like
 `user_request` which in fact, this breaks the functionality if we force
 set the slug to empty.

 So this little conditional has become a little of a hodgepodge that we
 must untangle.

 My review for the current patch is simply, extracting the 3 provisional
 statuses, setting them to empty, and leaving the rest as-is.

 Note that current unit tests must also be fixed, as they are only
 accounting for the provisional states, and expecting an untouched slug. So
 first we must introduce in the data provider the additional statuses.
 Also, the new expected result with an "empty" slug can be set in the same
 data provider.

 If anyone builds the patch taking this information in mind, don't submit a
 `.patch`, but a GitHub PR. Moreover, after submitted to GitHub, please
 comment here after this so I can receive a notification (GitHub PR does
 not notify).

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