[wp-trac] [WordPress Trac] #20419: get_sample_permalink() passes the wrong post_status to wp_unique_post_slug()

[WordPress Trac]

#20419: get_sample_permalink() passes the wrong post_status to
wp_unique_post_slug()
--------------------------+-----------------------------
 Reporter:  mintindeed    |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Permalinks    |     Version:  3.3
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------------

Comment (by mintindeed):

 Thanks. There was one test that wasn't passing and was driving me nuts,
 finally sussed it and now I think this is good to go.

 @wonderboymusic's patch changed the method signature for
 `wp_unique_post_slug()` so that it only contained a WP_Post object. After
 reviewing this ticket with @boonebgorges, Boone suggested leaving the
 first param (`$slug`), converting the second (`$post_ID`) to be either a
 WP_Post object or post ID, and deprecating the remaining params. The
 rationale is that there may be plugins or themes out there which use the
 `wp_unique_post_slug()` function on its own, maybe even as a utility
 function. This patch retains that utility, and it also means the changes
 to `wp_unique_post_slug()` are reduced (another good thing).

 So in the end, here are the changes made by the latest patch
 (20419.3.diff):

 * `get_sample_permalink()` sets `WP_Post->filter = 'sample'`, and the
 method signature for `wp_unique_post_slug()` is modified to allow passing
 a WP_Post object. This is great because the WP_Post object contains all
 the meta information we need to generate a unique slug, and also lets use
 pass along that this is a sample object and therefore we can safely bypass
 some of the prior post status hacks (#22902, #30910).
 * This gets rid of the need for the hack for #22902 (r24206) and the
 similar hack in `get_sample_permalink()` which appears to date back to its
 inception. I tested for regression and it appeared fine, I could not
 reproduce using the steps in the ticket.
 * Added new unit tests for this bug.
 * Added this ticket number to existing unit tests for #30910, for
 regression testing.
 * Added this ticket number to existing unit tests for #18306, for
 regression testing. #18306 isn't really a related issue, but when testing
 my patch I found some scenarios where I accidentally regressed these
 changes.
 * #22902 doesn't have unit tests; I didn't add any because I'm pretty sure
 the existing+new tests for `get_sample_permalink()` and
 `wp_unique_post_slug()` cover everything.
 * I updated existing unit tests which called `wp_unique_post_slug()` to
 use the new function signature, with the exception of a new test which
 verifies backwards compatibility of the params. This seemed like the right
 way to do it, rather than adding `@expectedDeprecated wp_unique_post_slug`
 to all the existing tests. I still added `@expectedDeprecated
 wp_unique_post_slug` to a few existing tests for other tickets, just
 because changing it to the new params would change the nature of the test
 in a somewhat significant way.

 Unit Tests

 phpunit --group 30910
 Passed

 phpunit --group 20419
 Passed

 phpunit --group post
 Passed

 phpunit --group admin
 Passed

 phpunit --group ajax
 Passed

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