Post slug stickiness for drafts still not quite right

[coffee2code]

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.

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

[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?

[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?

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

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

[ryan]

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

[ryan]

How's that? Issue resolved?

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

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

[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

[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!