[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                      |
-------------------------------------------------+-------------------------

Comment (by paulbonneau):

 Hello @SirLouen,

 I tried implementing what you proposed and it led me to dig deeper into
 the subject of WordPress `draft` post status constraints. For now, I don't
 have a patch to submit because I think there may be a collective
 discussion and decision to be made on this subject.

 Feel free to tell me if it is not ok to answer a ticket without patch or
 if the type of answer you'll find below should be made somewhere else
 (Slack, Github ..?).

 == About the proposed solution in your last answer

 It does not seem desirable to implement it because there are already tests
 that expect certain behaviors (and probably third party plugins and
 themes):
 - After being updated with wp_insert_post and without an explicit
 `post_name` in `wp_insert_post` args, the `post_name` shouldn't be emptied
 (cf.
 `test_wp_insert_post_for_customize_changeset_should_not_drop_post_name`,
 linked to https://core.trac.wordpress.org/changeset/38810 and
 https://make.wordpress.org/core/2016/10/12/customize-changesets-technical-
 design-decisions/).
 - After being untrashed, a post have the `draft` status. The expected
 behavior for the `post_name` during this state change is that the
 `post_name` should stay the same (cf.
 `test_trashed_posts_original_post_name_should_be_reassigned_after_untrashing`,
 linked to https://core.trac.wordpress.org/ticket/11863)

 Based on these findings I searched for other uses of `wp_unique_post_slug`
 accross the WordPress API and found this interesting occurence :
 If you check `/wp-includes/rest-api/endpoints/class-wp-rest-posts-
 controller.php` l.749 (search for "`wp_unique_post_slug()` returns the
 same slug for 'draft' or 'pending' posts."), you'll see that people
 implementing the REST post creation mechanics had a similar problem.
 They opted for forcing the post_status to `publish` in the
 `wp_unique_post_slug` post_status args in order to get around this
 behavior.

 == Possible solutions
 Based on this solution, I think we have several solutions to solve the
 problem raised by @ajflemming :
 - introduce a similar exception as the one in the WP REST API into the WP
 CLI API;
 - rethink the draft post status lifecycle and conditions in order to
 address this problem;
 - not trying to untangle draft post_status functioning as the issue
 described here could be addressed in the function used to retrieve posts
 (see https://core.trac.wordpress.org/ticket/61996 PR proposal)

 The first solution seems to me to be a quick and dirty fix.

 Even though the second solution is more tedious, I think it's the best
 one. Choosing this solution would exclude this ticket from the #good-
 first-bug category as it would need a broad knowledge of WP codebase and
 its history.

 The third solution seems to me to address the problem satisfactorily but
 superficially ( as it doesn't adresse the "draft shouldn't unique
 post_name" question).

 == What could be a good next step
 Before rushing to a solution, it could be interesting to gather the
 experimented and codebase history connoisseurs in order to address this
 question : "Why shouldn't we assign a post_name to a post with a `draft`
 post_status ?". Indeed, as a WP (wannabe) beginner contributor, after
 putting time and effort digging in the code and Trac I was not able to
 give a satisfying answer to this question that seems to be the heart of
 the problem here.

 For all of these reasons, I think the subject deserve a discussion amongst
 experienced WordPress codebase contributor.

 What do you think about it ?

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