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

[mort1305]

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.

[davidbaumwald]

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.

[khag7]

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.

[mort1305]

Anybody doing anything on this? I have no idea how core development works, so I'm at a loss on how to move this forward.

[lovecomm]

Ditto what @mort1305 says. Would be intereseted in the status of this as well, and also have no idea how core development works. Ran into this issue with a clients site. Running 5.9.1

[Grandy]

I can confirm this is a bug in the WordPress core.

Pretty sad to see that WordPress is pushing for new features and completely ignoring core problems like this. Not the first small fix for a core bug i see that gets ignored for years …