WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 7 months ago

#18523 new defect (bug)

Can't change page permalink if slug metabox is removed

Reported by: dankod Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Permalinks Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (4)

18523.diff (5.2 KB) - added by andrewryno 2 years ago.
18523.2.diff (6.2 KB) - added by andrewryno 2 years ago.
Added id="post_name" to the input and cleaned up a bit of the JS
18523-rt.diff (3.1 KB) - added by iamfriendly 2 years ago.
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.
18523.3.diff (3.2 KB) - added by iamfriendly 15 months ago.
Refreshed patch. Now fixes the %postname% issue highlighted by Helen

Download all attachments as: .zip

Change History (26)

comment:1 @dankod4 years ago

  • Component changed from General to Permalinks

comment:2 @nacin4 years ago

#19457 closed as a duplicate.

comment:3 @duck_4 years ago

  • Version changed from 3.2.1 to 3.0

I can reproduce this in WordPress 3.0.

comment:4 @nacin4 years ago

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' );
}

comment:5 follow-up: @azaozz4 years ago

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

comment:6 in reply to: ↑ 5 @DrewAPicture4 years ago

Replying to azaozz:

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

+1 for removing the metabox.

comment:7 @Lorangeo3 years ago

+1 for removing the metabox.

comment:8 @nacin3 years ago

  • Keywords needs-patch added

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.

comment:9 @nacin2 years ago

#24041 was marked as a duplicate.

comment:10 @wycks2 years ago

  • Cc bob.ellison@… added

+1 for CPT issue in #24041

@andrewryno2 years ago

comment:11 @andrewryno2 years ago

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.

comment:12 @juliobox2 years ago

  • Cc juliobosk@… added

@andrewryno2 years ago

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

@iamfriendly2 years ago

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.

comment:13 @iamfriendly2 years ago

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.

comment:14 @iamfriendly2 years ago

  • Cc richard@… added

comment:15 @nacin2 years ago

  • Milestone changed from Awaiting Review to 3.7

I like where 18523-rt.diff is going.

comment:16 @helen2 years ago

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

http://s.hyhs.me/RFPU/image.png

comment:17 @azaozz2 years ago

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 :)

Last edited 2 years ago by azaozz (previous) (diff)

comment:18 @DrewAPicture2 years ago

  • Keywords has-patch added; needs-patch removed

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

18523-rt.diff still applies cleanly enough.

comment:19 @helen2 years ago

  • Milestone changed from 3.7 to Future Release

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

@iamfriendly15 months ago

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

comment:20 @iamfriendly15 months ago

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

comment:21 @tyxla7 months ago

Remotely related: #31261

Last edited 7 months ago by tyxla (previous) (diff)

comment:22 @tyxla7 months ago

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?

Note: See TracTickets for help on using tickets.