Capabilities with misplaced dependencies in edit_theme_options

[Clorith]

When setting capabilities for other groups, the user is unable to add to theme options with just edit_theme_options if they do not also have edit_posts capabilities. The user will be able to delete things like menu elements, but may not add them without this flag.

How to reproduce;

Edit capabilities of group removing all POSTS to hide the Posts Dashboard pages (works by just removing edit_posts as well).
Give group edit_theme_options capabilities to edit their own menus.
Users may now access the Theme Options, and may delete objects.
User can add menu items to the preview, but once they Save these, the changes are not committed without the edit_posts permission.

[Obfuscated]

Found a workaround to this by changing the capabilities for the nav_menu taxonomy

global $wp_taxonomies;
$wp_taxonomies['nav_menu']->cap->assign_terms = 'edit_theme_options';

[nacin]

Interesting! Sorry I never saw this ticket. Looks like nav menus should indeed gain edit_theme_options for its capabilities. This is an interesting side effect of having cap checks inside wp_insert_post().

[blepoxp]

First diff in a couple years. Let me know if its not formatted correctly. Wasn't sure if the 'no new line' would be an issue. I think VIM caused that.

[nacin]

I think this was fixed by #27113 ([27556]). I'd still like to fix this but I'd like to make sure we get it right. For example, do any other caps need to change?

[nacin]

In 27717:

Ensure the $path is trailing-slashed in domain_exists().

props ejdanderson, ericmann.
fixes #18209.

[nacin]

Oops, [27717] was meant for #20589.

[desrosj]

I think it's safe to say @nacin cannot access the back office to look into this one.

It's been 8+ years, so some investigation should be done to confirm this is still a problem today, and if any context has changed. @Clorith are you able to check into this one?

[Clorith]

Oh wow, it's been 11 years for me 😅

I had a quick check, as I do sort of recall the problem at the time, and my findings are... better!

It should be added that the introduction of FSE adds another layer to this, since the original issue revolves around menu management, including within the Customizer, whereas neither are options with a FSE theme enabled.

In testing, I've created a new role (testrole- labeled "Test Role"), and given it only three capabilities;

• edit_theme_options
• manage_links
• read

This should be fairly similar to the expectations of the original ticket.

As the user with this role, I have a very limited admin interface, but I have the Customizer and Menu management items.

If I use the normal menu manager, I am now able to both remove, modify (change ordering, set child/parent relationships), or add to the menu, and I can save and see these changes as expected. The original problem when this was reported indicates that it was not possible to add new menu items without having the edit_posts capability as well, so this does not appear to be a problem any more.

Now, for the newly introduced issues, the Navigation block in FSE does not play nice with this, and although the Editor it self is available with just the edit_theme_options capability, if you open it with a vanilla WP setup, and the TwentyTwenty-Two theme active, you'll get an error trying to load the navigation items in the backend at first (this is because it is a "Page List" block, and apparently the lack of capabilities means the user isn't allowed to list pages, this is likely a Gutenberg-ticket style issue though).

---

For completeness sake, here are my exact testing steps:

• Brand new setup of WordPress 6.0.1, no settings changed.
• Installed the ​User Switching plugin to quickly change between users and roles
• Installed the ​User Role Editor plugin to easily visualize and set up a new role (also the plugin used when the original ticket was made, which I thought was handy!)
• Switched to the Twenty Twenty theme

Once this is done, I vent to Users > User Role Editor, and added a new role with the following details:

• Role name (ID): testrole
• Display Role Name: Test Role

I then used the Quick filter to add the following capabilities:

• edit_theme_options (the capability we want to test)
• manage_links (A capability that I know was around back then, and I would not have removed due to it's management-style concept)
• read (The capability to read content on the site)

Once this is done, I added a new user, and gave them the Test Role role on the site, and used the "Switch To" option in the user list to change to this user and test the admin interface, and adding new menu items.

I visited the Appearance > Menus page, and started adding/removing/moving menu items, saving them, and viewing it in a new tab from the front-end to see that changes were being applied.

I did the same from within the Customizer, and the Menu manager there.

---

That's not to say the problem might not still be evident somehow, but I was not able to reproduce it with the details I recall, and what was in the original ticket report. (I really wish I was better at writing tickets back then, to ensure I got the details right here, as I suspect I was creating a management role that had access to other things besides just Posts)