Ticket #1073 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

Post slug stickiness for drafts still not quite right

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

Description

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

bug1073_blankslug_post.diff (1.3 kB) - added by coffee2code on 05/21/05 06:36:25.
bug1073_noprivateslug.diff (0.8 kB) - added by coffee2code on 05/21/05 06:36:25.
bug1073_post.diff (0.6 kB) - added by coffee2code on 05/21/05 06:36:25.

Change History

03/10/05 15:12:40 changed by coffee2code

  • Patch set to No.

03/10/05 15:14:59 changed by coffee2code

  • version set to 1.5.1.
  • Patch changed from No to Yes.

03/10/05 16:51:18 changed by ryan

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."

03/10/05 17:23:37 changed by MC_incubus

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?

03/10/05 17:31:04 changed by coffee2code

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?

03/10/05 17:35:58 changed by coffee2code

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.

03/10/05 18:19:00 changed by coffee2code

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.

03/10/05 21:49:21 changed by MC_incubus

  • owner changed from anonymous to rboren.
  • status changed from new to assigned.

03/29/05 19:24:53 changed by ryan

http://trac.wordpress.org/changeset/2496

03/30/05 05:48:36 changed by ryan

How's that? Issue resolved?

03/30/05 06:07:05 changed by MC_incubus

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.

03/30/05 06:34:08 changed by coffee2code

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.

03/30/05 06:41:26 changed by ryan

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

03/30/05 06:49:01 changed by MC_incubus

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!

03/30/05 23:10:52 changed by ryan

  • status changed from assigned to closed.
  • fixed_in_version set to 1.5.1.
  • resolution changed from 10 to 20.

05/21/05 06:36:25 changed by coffee2code

  • attachment bug1073_post.diff added.