Make WordPress Core

Opened 14 months ago

Last modified 14 months 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:


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

  1. Install Classic Editor to switch from block to classic
  2. Create a draft post with title "the post title" and slug "this-is-the-slug"
  3. Create a muplugin with: add_filter( 'editable_slug', function( $post_name ) { wp_die( $post_name ); } );
  4. 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 @noisysocks
14 months ago

Confirmed that is happening in latest trunk running latest Gutenberg plugin.

The filter is called by this line in wp-admin/includes/post.php:

$permalink         = array( $permalink, apply_filters( 'editable_slug', $post->post_name, $post ) );

I'm not sure why $post->post_name differs when using the block editor. Somebody will need to investigate further, and:

  • If this is the correct behaviour, update the editable_slug docs.
  • If this is not correct, update the apply_filter logic.
Last edited 14 months ago by noisysocks (previous) (diff)

#2 @SergeyBiryukov
14 months ago

  • Component changed from General to Posts, Post Types

#4 @Otto42
14 months 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.

Last edited 14 months ago by Otto42 (previous) (diff)
Note: See TracTickets for help on using tickets.