Can't manually set slugs if pretty permalinks are disabled

[RanYanivHartstein]

With the new interface for manually setting slugs, there is no option to set an item's slug if pretty permalinks are disabled.

The interface for managing the slug is only displayed if pretty permalinks are enabled, and only after the first draft of the post is saved. This makes it cumbersome for users that have to manually edit slugs for every post they write - for e.g., when writing titles in a non-latin script (like Hebrew) that becomes gibberish when used as a slug.

While this does minimize noise in the post edit page and makes things elegant and simple, it makes it impossible, for e.g., to manually edit slugs for all posts before enabling pretty permalinks, or to manually edit slugs for new posts as a way to future-proof them in case pretty permalinks ever were enabled (or if a server issue prevents using them but will eventually be resolved).

I would suggest keeping the new interface for blogs that have pretty permalinks activated, but adding an interface for manually setting slugs for blogs that do not have them activated - this could be hidden by default like all other advanced options are hidden now.

[ryan]

The old slug edits fields are still on the form but JS is used to hide them. We can show them if permalinks are disabled.

[Viper007Bond]

The problem with this is it may confuse users. "Hey, I set a stub, why isn't it showing up?"

[RanYanivHartstein]

A simple note stating what slugs are for and when they are used could solve this confusion

[ryan]

There have been some more reports of this, so it's probably a good idea to show the old slug fields when permalinks aren't enabled.

In post.js and page.js the slugdiv is hidden with some JS.

jQuery('#slugdiv').hide();

We'd need to override this and show the box when permalinks are not enabled.

[matt]

People who don't show clean URLs but want to edit them is fairly edge, I think this can wait until 2.5.1.

[hervada]

Please do not let this as it is for the 2.5 release. I was very upset yesterday, because after a new installation the post slug was not shown any more. I am sure other people will have this trouble, too. One expects the permalink is at that place, and suddenly it is not there any more. (To your information: I use the post slugs in my cross-references-plugin as an alternative post ID when setting cross-references from one post to another. This has nothing to do whith permalinks, but uses the post slug, too.)

I propose this: An new option "Show pretty permalinks on post edit page". This can only be enabled if the blog uses pretty permalinks. If it is enabled, one sees the javascript-permalink under the title, if it is disabled, then the slgudiv is not hidden.

[lloydbudd]

I don't think this issue should be "fixed". It isn't the best experience for most people to show a field that will confuse them.

Replying to RanYanivHartstein:

when writing titles in a non-latin script (like Hebrew)
that becomes gibberish when used as a slug.

Sounds like a bug that needs being fixed. In the mean time a Hebrew WordPress package could be customized or a plugin to enable set slug created (is infrastucture needed?)

Replying to hervada:

(To your information: I use the post slugs in my cross-references-plugin as an alternative post ID when setting cross-references from one post to another. This has nothing to do whith permalinks, but uses the post slug, too.)

Sounds like your plugin should provide its own cust field if it truly has nothing to do with permalinks.

[markjaquith]

Replying to hervada:

(To your information: I use the post slugs in my cross-references-plugin as an alternative post ID when setting cross-references from one post to another. This has nothing to do whith permalinks, but uses the post slug, too.)

I propose this: An new option "Show pretty permalinks on post edit page". This can only be enabled if the blog uses pretty permalinks. If it is enabled, one sees the javascript-permalink under the title, if it is disabled, then the slgudiv is not hidden.

This is most definitely a non-typical usage. Our method of dealing with edge requests like this is to ensure that there are adequate plugin hooks so that someone could change the functionality that way. You should have all the hooks that are needed, but please let us know if that's not the case.

[hervada]

Replying to markjaquith:

This is most definitely a non-typical usage. Our method of dealing with edge requests like this is to ensure that there are adequate plugin hooks so that someone could change the functionality that way. You should have all the hooks that are needed, but please let us know if that's not the case.

Thank you markjaquith and lloydbudd for your comments. I realise now that with WP 2.5 a shift in the use of post slugs has occured, which makes my approach invalid. I've interpreted the post slug as an alfabetical ID for posts, until WP 2.3.3 each post got a slug whatever the permalink structure is. Now the post slug is just used for the purpose of permalinks and new posts get no slug, if pretty permalinks is not set. I still think this is not a good design decision, but anyway, it is your choice, I will add a custom field "post alias" and use this at my plugin. I've tested it and think there are already all hooks that I need. Thanks again.