Can't change page permalink if slug metabox is removed

[dankod]

If the slug metabox is removed from the "Edit Page" page, it is not possible to change permalinks, using the edit permalink function at the top of the page.

Slug and other metaboxes are removed by the karma theme, in its admin/theme-functions.php (but only if 'ka_hidemetabox' in the wp_options table is 'true'):

remove_meta_box('slugdiv','page','normal');

Technically, without the slug box, the "post_name" field containing the new slug is not sent with the form data when you click the "Update" button.

I believe this is bug was introduced after version 3.1.3.

[nacin]

#19457 closed as a duplicate.

[duck_]

I can reproduce this in WordPress 3.0.

[nacin]

This would require some JS modifications. Thinking something along these lines to get us started:

if ( ! real_slug.length ) {
	$('<input type="hidden" name="post_name" />').val( full ).appendTo( '#edit-slug-box' );
}

[azaozz]

Yes, the problem is that we have two "slug boxes" on the screen, the metabox and the manual entry under the title. Ideally one of them (the metabox?) should be removed completely.

As far as I remember there was a discussion about that some time ago. The slug field under the title can be made to appear when no JS (one of the reasons to have the metabox).

[DrewAPicture]

Replying to azaozz:

Ideally one of them (the metabox?) should be removed completely.

+1 for removing the metabox.

[Lorangeo]

+1 for removing the metabox.

[nacin]

As long as we can find a non-JS solution (which would probably mean always showing the input below the title input), I'm fine with getting rid of the meta box.

[nacin]

#24041 was marked as a duplicate.

[wycks]

+1 for CPT issue in #24041

[andrewryno]

Uploaded first attempt at a patch. Rather than adding/removing the input with JS I just kept it in all the time and show/hide it based on either JS/no-JS or if they have clicked the 'Edit' link. Much simpler that way and works well.

I'm not sure about the backwards compatibility of removing the actual function that removes the slugdiv, but developers shouldn't be using that function anyway.

[andrewryno]

Added id="post_name" to the input and cleaned up a bit of the JS

[iamfriendly]

Remove the slugdiv metabox, amend js to work with hidden field and add hidden field only for with-js. Works for no-js by showing the hidden field.

[iamfriendly]

My take is a little different - I've deprecated the slugdiv function and stopped the registration of that metabox.

With js enabled we have a hidden field which is used whenever someone edits the slug in the fancy UI. For no-js we actually show the field along with the Permalink:... etc. preamble.

Seems to work fairly well for both no-js and with-js. Maintains a little bit of backwards compatibility by simply not registering the 'slug' metabox any more and deprecating the function which outputs the content.

[nacin]

I like where 18523-rt.diff​ is going.

[helen]

With 18523-rt.diff​ and JS off, I get the /%postname%/ placeholder:

[azaozz]

Looking at 18523.2.diff and 18523-rt.diff: the whole "feature" badly needs refactoring. Hasn't been touched much since 2.5. get_sample_permalink(), get_sample_permalink_html(), the JS in post.js, the AJAX handlers... All can be done much better now :)

[DrewAPicture]

Anything else left besides the /%postname%/ issue with no-js @helen commented on in comment:16?

18523-rt.diff​ still applies cleanly enough.

[helen]

And punt. Let's keep working on it, though :)

[iamfriendly]

Refreshed patch. Now fixes the %postname% issue highlighted by Helen

[iamfriendly]

Whilst I agree that there is potential in revisiting exactly how this feature is implemented, I thought I'd refresh the patch and fix the issue mentioned by Helen. At least there's now a working solution...

[tyxla]

Remotely related: #31261

[tyxla]

I was just dealing with CSS enhancements on the slug field, when @helen pointed me here (thanks for that).

I'm a little doubtful for removing the slug meta box. The Permalink section is not shown for non-public post types. So removing that meta box would prevent the user to manage the slug in non-public post types. And I've dealt with such cases in my experience - using non-public post types that are using the slug (and need a field to manage it).

Example use case from my experience: manage custom galleries (galleries are a post type), and being able to display a gallery by a shortcode by either ID or slug (as slug is more readable for the client). So both options would work in this case: [fancy_gallery id="111"] and [fancy_gallery name="test-gallery"]. But in that case, since the gallery post type is non-public, the client would still want to manage the Slug by using the Slug meta box.

Am I missing something here?

[helen]

I'm going to look at this and #18306 today, was reminded of it on #17609.

Replying to tyxla:

I'm a little doubtful for removing the slug meta box. The Permalink section is not shown for non-public post types. So removing that meta box would prevent the user to manage the slug in non-public post types. And I've dealt with such cases in my experience - using non-public post types that are using the slug (and need a field to manage it).

I had envisioned putting the slug field in the same spot in that instance, which could possibly always show as an input instead of having to click edit. Would have to see how visually noisy that is.

[helen]

The link needs to be removed when editing, but here are a couple screenshots.

Initial view

Editing

[helen]

Oh, sorry, meant that for #18306. :)

[helen]

Still thinking through this; these are the things that strike me:

• For situations now where there's no slug field in the permalink area (permalinks without the post name, non-public post types), does this really need to show all the time? Or should the UI still be controlled in some way, maybe via post_type_supports() (not sure how that would work with non-post-name permalinks) or keeping the screen option? I don't think it's a good idea for it to show all the time because fields indicate what you're supposed to be doing just as much as what you could be doing, and I don't think that any large majority of people need this field to be showing all the time.
• For cases where a permalink is shown but doesn't have the post name in it, where would this field be displayed? Beside the permalink, below, other?
• If we change what get_sample_permalink_html() returns, what side effects would this have? A quick plugin repo search brings up a few results.
• If we don't change it in that function, where do we make the alteration? Can't be in JS because the input is also a no-JS fallback.

I definitely think this metabox still needs to go because it's very heavy UI for something so small, but I'm still not sure what exactly the right replacement is. Would love some thoughts here.

[DrewAPicture]

@helen What's the status here in terms of must-haves for 4.4 vs what could be future release?

[helen]

Patch in progress for safekeeping

[helen]

Started on a rework since a lot has moved around, but it's not a priority for 4.4. Punting, there are enough changes already in this area that waiting on this might be prudent for clarity of the source of any problems, anyway.

[anonymized_5580574]

Still the same problem in 4.7.3 – any news about a bugfix?

[bugnumber9]

This bug is still there in 4.8

[dibbyo456]

It's been 8 years and the bug is still there as of 5.2.3

[anonymized_5580574]

Replying to dibbyo456:

It's been 8 years and the bug is still there as of 5.2.3

Indeed. Very annoying!

[ninetyninew]

Just come across this in 2021, running 5.6.