Make WordPress Core

Opened 17 years ago

Closed 17 years ago

#1073 closed defect (bug) (fixed)

Post slug stickiness for drafts still not quite right

Reported by: coffee2code Owned by: ryan
Milestone: Priority: normal
Severity: minor Version: 1.5.1
Component: Administration Keywords:
Focuses: Cc:


Bug #531 involved post slugs being set on initial save and never updating when, while still in draft mode, a post's title changes.

The whole post slug auto-updating business was something for which I had investigated after encountering it on my own, but I ultimately concluded not to submit a bug (or patch) for this because I didn't think it would gain approval. Here's why:

The patch applied to resolve bug #531 was only half of the needed solution. The patch checked if the current $post_status was 'draft', and if so, then it updated the post slug. However, the second such check in the code, which is in the 'editpost' switch branch, needs to ALSO check $prev_status (because at the point of the check $post_status could be 'publish' for a just-published draft, so we'd need to check $prev_status to see if that was 'draft'). That fix is in the attached patch. (As it stands, the fix for bug 531 will update the post slug when going from draft -> draft, but not draft -> publish.)

There are two potential items of concern:
1.) The user can NEVER manually set the post slug. While in draft mode, WP will always sync the post slug to the post title. To resolve this, we'd probably have to store $prev_title and add a check along the lines of :

if ( (empty($post_name)
'draft' == $post_status) && (sanitize_title($prev_title, $post_ID) == $post_name) );

So basically if the user set the slug to be something other than the auto-slugified post title, then it shouldn't be overridden by WP.

2.) If a published post were to be set to 'draft', its title changed, then republished, the post slug would also be changed, breaking the permalink.

Due to those potential causes for concern I opted to write a plugin to keep the post slug in sync with the title, since for certain users the above may affect them when it doesn't me. However, if those issues aren't of much concern, then the attached patch should do it.

Attachments (3)

bug1073_blankslug_post.diff (1.3 KB) - added by coffee2code 17 years ago.
bug1073_noprivateslug.diff (782 bytes) - added by coffee2code 17 years ago.
bug1073_post.diff (587 bytes) - added by coffee2code 17 years ago.

Download all attachments as: .zip

Change History (16)

#1 @coffee2code
17 years ago

  • Patch set to No

#2 @coffee2code
17 years ago

  • Patch changed from No to Yes
  • Version set to 1.5.1

#3 @ryan
17 years ago

When a post goes from publish to draft, it disappears from the perspective of an outside reader. The permalink goes away. Considering this, should we worry about keeping the slug sticky? I guess it might be useful to have the post show up back at its old haunts once republished. This complicates the interaction a bit though since it introduces another transition rule. "The slug will update while in draft mode unless transitioning from publish."

#4 @MC_incubus
17 years ago

I think it should work like this: for drafts, slug is kept blank. This simplifies the logic. If the user manually sets it, it should stay. This way even if it is published, and changed back to draft, the slug will stay the same, because it is not blank.

So, the logic goes like this: slug is only auto-set on publish if the slug is currently blank. Slug is never auto-set for drafts. That pretty much does it, right?

#5 @coffee2code
17 years ago

I don't think we can reasonably handle publish->draft->publish scenario, at least in a way that intelligently retains the originally published post slug. We'd have to persist the "I've been published once under this post_slug" value/state. Unless we add a checkbutton: "Edit post slug" and ALWAYS have it set on. (perhaps add a "(WordPress will automatically sync post slug to the post title)" next to that when slug is in danger of being overwritten (i.e. draft->draft or draft->publish, but not publish->publish). That way under any scenario the user can still choose to manually edit the post slug or can at least tell WP not to update it.

Now that I think about it, that checkbutton might be best. Saves the sanitize_title() bit I mentioned as a solution in the first of my two noted concerns, while alleviating those two concerns. (Though the onus would fall on the user to unset the checkbutton if they put a published post back into draft status and change the title.)

Either way, the previously attached patch would still be needed to cover the draft->publish updating of the slug. However, I'll roll that change into my patch/proposal for the checkbutton.

Sound reasonable?

#6 @coffee2code
17 years ago

Ah, posted at same time as MC_incubus. I think his blank slug approach may be the best; the simplest and cleanest, and as far as I can tell, should work.

#7 @coffee2code
17 years ago

I attached a patch (bug1073_blankslug_post.diff) that does what MC_incubus suggests. Basically, post slug only ever gets set (a) when user explicitly sets it and (b) if slug is blank and post is being published.

#8 @MC_incubus
17 years ago

  • Owner changed from anonymous to rboren
  • Status changed from new to assigned

#10 @ryan
17 years ago

How's that? Issue resolved?

#11 @MC_incubus
17 years ago

Saving as "Private" appears to set the post slug, afterwhich alterations to the title (whether saving as draft or as private again) don't change the slug.

#12 @coffee2code
17 years ago

The patch I just added should also take into consideration 'private' as not being an auto-slug-able condition, just as is the case for 'draft'. Untested, though, but the change was slight.

#13 @ryan
17 years ago

Private posts are "published" to the author. Private posts need a slug since they will appear on the blog when the author is logged in.

edited on: 03-30-05 06:43

#14 @MC_incubus
17 years ago

Hey, you learn something new every day. Might be a cool way to see how the post looks "on the site."

In any case, this bug can be closed then!

#15 @ryan
17 years ago

  • fixed_in_version set to 1.5.1
  • Resolution changed from 10 to 20
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.