WordPress.org

Make WordPress Core

Opened 5 years ago

Last modified 9 months ago

#18523 assigned defect (bug)

Can't change page permalink if slug metabox is removed

Reported by: dankod Owned by: helen
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Permalinks Keywords: needs-patch
Focuses: administration 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 (5)

18523.diff (5.2 KB) - added by andrewryno 3 years ago.
18523.2.diff (6.2 KB) - added by andrewryno 3 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 3 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 2 years ago.
Refreshed patch. Now fixes the %postname% issue highlighted by Helen
18523.4.diff (3.2 KB) - added by helen 9 months ago.
Patch in progress for safekeeping

Download all attachments as: .zip

Change History (35)

#1 @dankod
5 years ago

  • Component changed from General to Permalinks

#2 @nacin
5 years ago

#19457 closed as a duplicate.

#3 @duck_
5 years ago

  • Version changed from 3.2.1 to 3.0

I can reproduce this in WordPress 3.0.

#4 @nacin
5 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' );
}

#5 follow-up: @azaozz
5 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).

#6 in reply to: ↑ 5 @DrewAPicture
5 years ago

Replying to azaozz:

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

+1 for removing the metabox.

#7 @Lorangeo
4 years ago

+1 for removing the metabox.

#8 @nacin
4 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.

#9 @nacin
3 years ago

#24041 was marked as a duplicate.

#10 @wycks
3 years ago

  • Cc bob.ellison@… added

+1 for CPT issue in #24041

@andrewryno
3 years ago

#11 @andrewryno
3 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.

#12 @juliobox
3 years ago

  • Cc juliobosk@… added

@andrewryno
3 years ago

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

@iamfriendly
3 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.

#13 @iamfriendly
3 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.

#14 @iamfriendly
3 years ago

  • Cc richard@… added

#15 @nacin
3 years ago

  • Milestone changed from Awaiting Review to 3.7

I like where 18523-rt.diff is going.

#16 @helen
3 years ago

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

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

#17 @azaozz
3 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 3 years ago by azaozz (previous) (diff)

#18 @DrewAPicture
3 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.

#19 @helen
3 years ago

  • Milestone changed from 3.7 to Future Release

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

@iamfriendly
2 years ago

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

#20 @iamfriendly
2 years 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...

#21 @tyxla
18 months ago

Remotely related: #31261

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

#22 follow-up: @tyxla
18 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?

#23 in reply to: ↑ 22 @helen
11 months ago

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.

#24 @helen
11 months ago

  • Milestone changed from Future Release to 4.4

#25 @wonderboymusic
10 months ago

  • Owner set to helen
  • Status changed from new to assigned

#26 @helen
10 months ago

  • Focuses ui administration added
  • Keywords has-screenshots added

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

Initial view
http://s.hyhs.me/dMnI/image.png

Editing
http://s.hyhs.me/dN0B/image.png

#27 @helen
10 months ago

  • Focuses ui removed
  • Keywords has-screenshots removed

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

#28 @helen
10 months ago

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.

#29 @DrewAPicture
9 months ago

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

@helen
9 months ago

Patch in progress for safekeeping

#30 @helen
9 months ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 4.4 to Future Release

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.

Note: See TracTickets for help on using tickets.