Opened 5 years ago
Last modified 5 years ago
#48622 new defect (bug)
`editable_slug` filter does not pass the correct value
Reported by: | noisysocks | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.3 |
Component: | Posts, Post Types | Keywords: | needs-patch |
Focuses: | Cc: |
Description
Originally reported in https://github.com/WordPress/gutenberg/issues/15802.
Describe the bug
When using the block editor, the 1st param $post_name passed to the editable_slug filter hook is not the same as the classic editor, which is the expected one.
To reproduce
- Install Classic Editor to switch from block to classic
- Create a draft post with title "the post title" and slug "this-is-the-slug"
- Create a muplugin with: add_filter( 'editable_slug', function( $post_name ) { wp_die( $post_name ); } );
- Refresh your edit page
Expected behavior
With the classic editor you should have "this-is-the-slug"
but when using block editor you have "the-post-title", sounds like the post_title sanitize with sanitize_title, it should be the real post_,name like classic is doing.
Change History (4)
#1
@
5 years ago
#3
@
5 years ago
Might be related to #45478 and https://github.com/WordPress/gutenberg/issues/12907.
#4
@
5 years ago
The editable_slug filter in particular is a widely used filter, called by multiple locations in WordPress. It's not exclusively for post-slugs, in other words.
A call to apply_filters('editable_slug'...) exists in these locations:
wp-admin\edit-tag-form.php(153): $slug = isset( $tag->slug ) ? apply_filters( 'editable_slug', $tag->slug, $tag ) : ''; wp-admin\includes\class-wp-terms-list-table.php(424): $out .= '<div class="slug">' . apply_filters( 'editable_slug', $qe_data->slug, $qe_data ) . '</div>'; wp-admin\includes\class-wp-terms-list-table.php(547): return apply_filters( 'editable_slug', $tag->slug, $tag ); wp-admin\includes\meta-boxes.php(864): $editable_slug = apply_filters( 'editable_slug', $post->post_name, $post ); wp-admin\includes\post.php(1372): $uri = apply_filters( 'editable_slug', $uri, $post ); wp-admin\includes\post.php(1380): $permalink = array( $permalink, apply_filters( 'editable_slug', $post->post_name, $post ) ); wp-admin\includes\template.php(316): '<div class="post_name">' . apply_filters( 'editable_slug', $post->post_name, $post ) . '</div>
So, are you sure that the value you are getting is from the same types of calls every time? The block editor uses the REST API to make calls, so is it possible that you're seeing some other value come through an editable_slug filter which you were not expecting?
Edit: On an additional note, because this is a filter and not an action, then you shouldn't be using it to retrieve the slug. Filters are intended to, well, filter. You use them to modify data as it passes through the system. You don't typically save that data for use elsewhere. That's what actions are for, actions are called when data is being made available to be used. If you need the post slug to save or otherwise do something with it, then finding an action would be what you want here.
Confirmed that is happening in latest
trunk
running latest Gutenberg plugin.The filter is getting by this line in
wp-admin/includes/post.php
:I'm not sure why
$post->post_name
differs when using the block editor. Somebody will need to investigate further, and:editable_slug
docs.apply_filter
logic.