Advanced Option: Post Slug should be removed

It isn't meaningful if you aren't using pretty permalinks

Good point. Perhaps we should hide it if pretty permalinks aren't enabled.

and if you are using pretty permalinks once you save a post, there is a much cleaner experiening above the post for adjusting the permalink.

Adjusting the title post-publishing does not update the post slug, and I wouldn't recommend changing that. Yes, we do have code to redirect to the new post slug, but there is still an SEO hit. Also, some people like to craft custom post slugs that are more elegant than our one-size-fits-all-generated-from-the-title solution.

We can, however, make the post slug interface better. One of the things I really liked from Bryan Veloso's wp-admin mockups was that the post slug editing interface was in the context of the future URL of the post.

http://example.com/2008/02/06/[] /

That is really clever, because it tells people exactly what a post slug is.

http://example.com/2008/02/06/[________________]/, rather.

Replying to markjaquith:

Adjusting the title post-publishing does not update the post slug, and I wouldn't recommend changing that.

Sorry, I don't completely understand your response. Since #5679 the interface on trunk is as you suggest it should be. You save a post, and the post slug editing interface is in the context of the future URL of the post.

Doh! I hadn't seen that. Although it appears to be broken in Trunk right now.

I see your point now. Though I do think that people need the ability to set their own slug before publishing. Maybe we could rig up that "editable URL" thing to work on your first draft. Then the Advanced Option post slug would be completely redundant.

Here's my vision:

As you type in the title, the slug is populated (right there, below the title, in the context of the URL). Regular rules apply: if you save with the default slug, it isn't locked in. But at any point if you manually edit the post slug, it gets locked down.

Anyone care to implement that? I'd like to get rid of the slug box at the bottom, but I think we need to address setting the slug for new posts.

edit slug for new post page, on autosave

I've added a patch that puts the slug preview thing in place on autosave for a new post.

It doesn't change the existing "save" functionality: clicking "save" still does not actually save the slug to the db. To do that we would need to duplicate the slug-fixing algorithm in wp_insert_post. My idea is to move that to a separate function that is used by both wp_insert_post and admin-ajax.

Each time I click Edit, the "Permalink:" and "Edit text are duplicated. After two clicks I have this:

Permalink: Permalink: Permalink: http://localhost/trunk/2008/02/20/test-slug/ Edit Edit Edit

Also, pages need this too.

My bad, I didn't flush cache. I'll bump the version in script-loader to bust the cache.

(In [6954]) Show permalink editor on new posts after autosave. Props filosofo. see #5749

I added a patch that sets up the slug editor for pages, hides the advanced options slug field for those with JS enabled, shortens the autosave time to 60 seconds, triggers the first autosave early in typing (after 15 characters in the #content textarea), and saves a user-changed slug in autosave.

I had to add a leavename argument to a couple of page permalink functions, to make it parallel to post permalinks and allow page slug editing.

(In [6955]) Slug edit for pages. Hide advanced slug field if JS enabled. Trigger first autosave after 15 chars. Set autosave interval to 60s. Props filosofo. see #5749

The fast first autosave isn't triggered if using TinyMCE, because it is inside iframe and it doesn't get the keypress events.

IMHO, the complexity to implement it isn't worth it.

Another thing: the event handler should be removed after the first autosave.

TinyMCE has several methods that can be used here: isDirty() checks for unsaved changes, triggerSave() moves the content from the iframe to the textarea, isHidden() checks which tab is currently selected (Visual or HTML), etc. It can also handle auto-saving nicely when activated, however if HTML mode is used from the beginning, TinyMCE is loaded but not activated. Perhaps we can use TinyMCE's methods when activated or jQuery otherwise.

Marking as needs-patch.

This needs a little bit of work to complete from reading the audit trail above.

Kick autosave when title goes out of focus and has content

Ryan's patch, but with Tab autosave support in Safari 3.1

(In [7394]) Autosave when title has content and loses focus. props ryan. see #5749