WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 5 weeks ago

#50284 new defect (bug)

A fix to the CPT-no-create-when-submenu-child problem.

Reported by: mort1305 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.5
Component: Administration Keywords:
Focuses: ui, administration Cc:

Description

Here's a bug and a work around solution. (It is something that coders try to implement, but back away from when they see it's broken.) Code is traced ready to be altered. Please see [StackExchange](https://wordpress.stackexchange.com/questions/367822/how-to-allow-add-new-capability-of-cpt-when-links-to-its-ui-are-placed-as-a-su) for the bloodsucking work.

Short is that users with the edit_{post-type} custom capability for a custom post type cannot create that particular post type if the UI is accessible by way of a submenu. The fix is to NOT POPULATE THE POST MENU WITH post-new.php if the user does not possess the edit_posts capability. [This line](https://core.trac.wordpress.org/browser/tags/5.4/src/wp-admin/menu.php#L170) is the problem child: it needs to go sit in the corner with a pointy hat on.

I'm new to the whole playing with other WordPressers in the sandbox kind of thing. If I knew how to make changes to the core for upgrades, I would have submitted a file change with that line 170 in wp-admin/menu.php looking like this: if( current_user_can($ptype_obj->cap->create_posts) ) { $submenu[ $ptype_file ][10] = array( $ptype_obj->labels->add_new, $ptype_obj->cap->create_posts, $post_new_file ); } ... well, formatted nicely into three lines, obviously.

Change History (2)

#1 @davidbaumwald
4 months ago

  • Focuses rest-api performance coding-standards removed
  • Keywords has-fix removed
  • Severity changed from major to normal
  • Version changed from 5.4.1 to trunk

Hi @mort1305, and thanks for the ticket. I've updated the ticket to hopefully maximize its visibility and make sure it's handled by the appropriate contributors.

#2 @khag7
5 weeks ago

I can confirm that this bug exists.

If a user does not have edit_posts capability but does have edit_{custom-type}s capability, they are prevented from accessing wp-admin/post-new.php?post_type={custom-type} if edit.php?post_type={custom-type} exists as a submenu item.

For a "real world" example you can set up:

  • Install WooCommerce. They put the shop_order custom post type as a submenu item.
  • Create a custom role. I call mine 'Order Processor' which is someone who can create/edit orders but not other aspects of the website.
  • Give this person the capabilities relating to shop_order custom post types, but do not grant them edit_posts since we don't want them writing to our blog section. I do this in production, it used to work but I haven't tested it in a long time.

My client tells me they did not have any issues with this person creating new orders until the 5.5 WordPress update, but I'm only partially confident that is true. It may have broken sooner. It may have been broken for quite a while. I'm not certain. I am certain it is broken now.

The StackOverflow link in the ticket has a "fix" in the form of an action hook which does solve the problem for me. It works by hooking to _admin_menu and unsetting an array element from the global $submenu. I haven't tested the change proposed in this ticket.

Note: See TracTickets for help on using tickets.