Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#34865 closed defect (bug) (fixed)

Slug reset when updating post without slug field

Reported by: jason_the_adams Owned by: ericlewis
Milestone: 4.5 Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: administration Cc:


Currently, when a post is being updated, it's assumed that the existing post slug will be supplied with the post being updated, rather than retrieving the post and using the existing slug. Other values of the post aren't imposed, so it's fair to omit them in the update data. It seems like it would be consistent to retrieve the existing slug in wp_insert_post when updating.

If this makes sense, I'm happy to put together a test for proof-of-issue and subsequent fix.

Attachments (1)

34865.patch (1.9 KB) - added by jason_the_adams 2 years ago.

Download all attachments as: .zip

Change History (13)

#1 @jason_the_adams
2 years ago

  • Summary changed from Slug reset when updating post in edit.php without slug field to Slug reset when updating post without slug field

This ticket was mentioned in Slack in #core by jasontheadams. View the logs.

2 years ago

#3 @swissspidy
2 years ago

I'm used to clearing the slug field and clicking "OK" to reset the post's slug, for example when I made a typo. I don't think I've ever cleared the slug field and hit "Update", but I guess changing this behaviour would break a couple of things.

#4 @jason_the_adams
2 years ago

@swissspidy Thanks for replying! There's a difference between the slug being offered as an empty string (what you're describing), and being omitted entirely (what I'm talking about). Since the slug is necessary, it makes perfect since that if it's an empty string, that it needs to be generated. But in the case that it's omitted AND is an update, then the existing slug shouldn't be changed -- at least that's what I'm proposing. In that case, I don't think it should break anything. Admittedly, it's a pretty niche bug.

#5 @boonebgorges
2 years ago

See also #20419 (ping @mintindeed), which has to do with differentiating between post properties passed to the function differing from those in the database.

#6 @jason_the_adams
2 years ago

@boonebgorges I don't think to two are actually related. I'm including a patch as well as a test to present the issue.

(Thanks for the help, @jgrodel!)

This ticket was mentioned in Slack in #core by jasontheadams. View the logs.

2 years ago

#8 @boonebgorges
2 years ago

  • Owner set to ericlewis
  • Status changed from new to assigned

#9 @jason_the_adams
2 years ago

I didn't want to overextend this. But I did notice as well that a similar issue happens if the post_status is omitted. In fact, there's two points in wp_insert_post that effectively forces 'draft' if the status is omitted or empty. It really feels like update should accept partial data and assume the existing data in that case.

#10 @ericlewis
2 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 35800:

Posts: Don't modify post_name if it wasn't supplied to wp_insert_post().

Previously when updating a post using wp_insert_post(), post_name was
regenerated based on post_title every time if post_name was not passed in
explicitly. This irons out the expectation that properties not passed into the
function should not be modified.

Props jason_the_adams.
Fixes #34865.

#11 @netweb
2 years ago

  • Milestone changed from Awaiting Review to 4.5

#12 @johnbillion
2 years ago

  • Version trunk deleted
Note: See TracTickets for help on using tickets.