Post types with show_ui set to false should not be accessible via the admin area

[johnbillion]

This might be a contentious issue. It's certainly not expected behaviour, but I suspect there are sites which rely on its behaviour.

If a custom post type is registered with show_ui set to false, it's still possible to see the post type listing screen for the post type by manually navigating to the correct URL (eg. example.com/wp-admin/edit.php?post_type=my_hidden_post_type). From there you can access the post editing screen for the posts and update them.

If I register a post type without a UI, I do not expect to be able to access a UI for the post type simply by hacking the URL.

The post type listing UI and post editing UI for such a post type should be disabled. In order to disable this UI currently, you need to set the post type's capabilities to a capability which your users don't have, which has the side effect of preventing posts from being created/edited via other means, such as XML-RPC.

[johnbillion]

Related: #22214

[swissspidy]

The attached patch mimics the behaviour of post-new.php and returns an error when show_ui is set to false.

I agree that people do weird things with post types and misusing show_ui may be one of them. Perhaps someone can scan the plugin directory for usages of 'show_ui' => false?

[wonderboymusic]

I like the approach, but move the check to a new check after that one and make the error message more specific to the particular check

[swissspidy]

33763.2.diff​ separates the check from the ! $typenow check and also fixes this in wp-admin/post.php like originally suggested.

The error message was changed to You are not allowed to edit posts in this post type., a string that's already used in core and doesn't need a new translation.

[ocean90]

#22214 was marked as a duplicate.

[nofearinc]

33763.2.diff​ works for me, the post type is not visible in the admin, neither accessible through edit.php or post.php.

[johnbillion]

I'm going to go ahead and commit this so we have plenty of time to hear from the authors of any plugins which rely on this unexpected and unintended behaviour.

If your plugin or site does rely on this behaviour, the arguments that are passed to register_post_type() should be altered so that show_ui is true, and arguments such as show_in_menu, show_in_nav_menus, and show_in_admin_bar are false.

[johnbillion]

In 34177:

Remove the ability to view the post listing screen and post editing screen for post types with show_ui set to false. It is unexpected and unintended behaviour that this is allowed.

If your plugin or site does rely on this behaviour, the arguments that are passed to register_post_type() should be altered so that show_ui is true, and arguments such as show_in_menu, show_in_nav_menus, and show_in_admin_bar are false.

Fixes #33763
Props swissspidy, johnbillion

[DrewAPicture]

@johnbillion: I think we should probably update the docs for the show_ui argument in register_post_type() as well as add a changelog entry for the change in behavior.

[dd32]

[34177] has broken the ability to get a link to Revisions.

get_edit_post_link( $revision_id ) => $post_type = 'revision' => the Revision post type is not a show_ui => true post type.

[johnbillion]

In 34353:

Add @since docs for the show_ui argument in register_post_type().

See #33763

[johnbillion]

In 34357:

Revisions are an exception when it comes to the editing UI. The revision post type cannot have its show_ui argument set to true because this allows access to the post type listing, creation, and editing UI, but get_edit_post_link() needs to return a URL for the editing UI for revisions as that's how the revisions UI works.

Fixes #33763

[nerrad]

I have another issue that likely wasn't forseen.

In our case we want show_ui set to false so it restricts access to the native post_editor for our custom post type. However, we were using the get_edit_post_link filter to filter the edit links to point to our custom ui for editing our post type.

The problem is that with the change introduced here, if show_ui is set to false, not only does it restrict access to the native editor (huge plus by the way) but it also prevents the custom filtered edit links from being shown. Currently the only way to rectify that is to set show_ui to true.

I see that this is because of this bit of code:

$allowed = array_merge( array(
		'revision',
	), get_post_types( array(
		'show_ui' => true,
	) ) );

Would it be possible to make that allowed array filterable, then plugins can still show the edit link when they have a custom ui. It *might* even be a place where we could add another argument on the register_post_type array for this explicit scenario?

[johnbillion]

I think we can fix this without the need to introduce a new filter. Patch incoming.

[johnbillion]

@nerrad Can you try out 33763.3.diff​ please? It should fix your issue. The edit post link is always passed through the get_edit_post_link filter, even if it's empty.

[nerrad]

yeah I'll get this tested (won't be until tomorrow tho), however on first glance, will this cause a regression on the revision link fix?

[builtbynorthby]

I tested the patch and it fixes the issue that @nerrad reported, the edit links appear on the custom post type posts. Thank you.

[nerrad]

@johnbillion @builtbynorthby is a workmate and the one who originally discovered the issue, so looks like your patch is all clear for fixing the issue reported.

[johnbillion]

In 35704:

Move the show_ui logic into the get_edit_post_link() and get_edit_term_link() functions to facilitate post types and terms which specify show_ui as false but provide a custom editing UI via the get_edit_post_link and get_edit_term_link filters.

Fixes #33763
Fixes #33938