WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #44805, comment 2


Ignore:
Timestamp:
08/16/2018 10:51:22 PM (20 months ago)
Author:
ajmccluskey
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #44805, comment 2

    initial v1  
    66
    77This behaviour is also seen when you update the post to published and change its slug in the same update. This might be a more likely scenario, and I would argue that a user's expectations in taking this action are very likely "publish this post with the changes that I'm making".
    8 
    9 Replying to [comment:1 JPry]:
    10 > This isn't unique to the REST API. You can observe the same behavior by using `wp_update_post()` directly with PHP.
    11 >
    12 > {{{#!php
    13 > <?php
    14 > $id = wp_insert_post( [
    15 >     'post_status' => 'publish',
    16 >     'post_name'   => 'a',
    17 >     'post_title'  => 'a',
    18 > ] );
    19 >
    20 > wp_update_post( [
    21 >     'ID'          => $id,
    22 >     'post_status' => 'trash',
    23 > ] );
    24 >
    25 > wp_update_post( [
    26 >     'ID'        => $id,
    27 >     'post_name' => 'foo',
    28 > ] );
    29 >
    30 > wp_update_post( [
    31 >     'ID'          => $id,
    32 >     'post_status' => 'publish',
    33 > ] );
    34 >
    35 > $post = get_post( $id );
    36 >
    37 > // $post->post_name will be 'a' instead of 'foo'.
    38 > }}}
    39 >
    40 >
    41 > This is caused by this block within `wp_insert_post()`:
    42 >
    43 > {{{#!php
    44 > <?php
    45 >       /*
    46 >        * If the post is being untrashed and it has a desired slug stored in post meta,
    47 >        * reassign it.
    48 >        */
    49 >       if ( 'trash' === $previous_status && 'trash' !== $post_status ) {
    50 >               $desired_post_slug = get_post_meta( $post_ID, '_wp_desired_post_slug', true );
    51 >               if ( $desired_post_slug ) {
    52 >                       delete_post_meta( $post_ID, '_wp_desired_post_slug' );
    53 >                       $post_name = $desired_post_slug;
    54 >               }
    55 >       }
    56 > }}}
    57 >
    58 > When the slug is changed for a trashed post, the `_wp_desired_post_slug` meta is never updated to match the new slug. This is a bit of an edge case, because once a post is trashed, the slug is modified, as seen just a few lines below the previous snippet:
    59 >
    60 > {{{#!php
    61 > <?php
    62 >       // When trashing an existing post, change its slug to allow non-trashed posts to use it.
    63 >       if ( 'trash' === $post_status && 'trash' !== $previous_status && 'new' !== $previous_status ) {
    64 >               $post_name = wp_add_trashed_suffix_to_post_name_for_post( $post_ID );
    65 >       }
    66 > }}}
    67 >
    68 >
    69 > In the case of this example, it will be set to `a__trashed`. The expectation is that a trashed post's slug is not canonical, and the slug is able to be used by other posts and is not blocked from reuse by a trashed post.
    70 >
    71 > With that in mind, I'm not convinced that this is actually a bug. But I think it's still worth some discussion to determine what should be the correct behavior for this edge case.
    72 >
    73 > Out of curiosity, why would you want to change the slug of a trashed post in the first place?