Read-only custom taxonomies for non-admin users

This is not really a Pods issue and is more easily addressed as a WordPress issue. WordPress has a filter that will let you prevent new terms from being saved. For more information, see this SO answer, which is how I deal with it:

https://wordpress.stackexchange.com/a/112721/25300

And yes, that strategy is bad UX, like most WordPress post editor errors. So I’d combine it with unhooking which ever action adds the metabox to the post editor, or some JS to prevent changes to the form. Also unhook the settings menu if you need to.

Thanks for your answer.

I’m not sure this will solve everything though: I want the users to be able to select the existing terms, but they shouldn’t be able to modify or delete them.

OK, I see, still not really a Pods issue. I’m not saying that to get rid of you, I’m still going to help, but if we think of this as a WordPress issue, it’s easier to find solutions and makes more sense since taxonomy UI is not from Pods.

Similar answer, which is based on the same SO answer:

https://wordpress.stackexchange.com/a/112721/25300

In fact, if you read this tutorial you can see how I solved the same issue, based on that SO answer, to prevent new terms being used for classifying tutorials on Pods.io.

The UI/UX on error handling is bad, but it works. If I was more concerned about that on Pods.io than I am–since its basically only me creating content there–I’d combine that with some JavaScript to prevent adding new terms at all to the form. Still need the server-side check, as anything in the browser can be defeated easily.

OK, thanks, I’ll have a look.

I’ve searched the Codex and just found out this regarding custom taxonomies capabilities.
If I understand it well, it seems to provide exactly what I need, but the capabilities have to be set when the taxonomy is registered.
Any way this can be implemented in Pods?

Yes, as Scott points out, that is supported. Its in the advanced options tab of the Pods editor for a custom taxonomy.

Unfortunately, I don’t know who Scott is. What he has written and where?

In the advanced options tab, I see the following:

• Public
• Hierarchical
• Rewrite
• Custom Rewrite Slug
• Allow Front Prepend
• Hierarchical Permalinks
• Query Var
• Remember order saved on Post Types
• Function to call when updating counts
• Associated Post Types

and none of these options seem to be related to capabilities.

What am I missing?

tosca30, it looks to me that setting capabilities with custom taxonomies is not yet in the Pods UI. Maybe this exchange on pods.io will help.

Oh, and by the way, Scott (Kingsley Clark) is the lead developer of Pods.

Okay, tosca30, I just realized that you can edit user role capabilities within Pods. First, go to Pods Admin ? Components, and enable Roles and Capabilities. Once you’ve done that, a new submenu item will display under Components. From there, you can create and manage the user roles and capabilities. I’ve never used it myself, but hopefully that will get you moving in the right direction.

Alternatively, you can remove the taxonomy menu item from the menu for all users who aren’t Administrator, like so:

#1 – If Top-Level Menu Item

add_action( 'admin_menu', 'YOURPREFIX_conditionally_remove_admin_menu_items', 999 );
function YOURPREFIX_conditionally_remove_admin_menu_items() {
    /* Check whether user has admin privileges */
    if ( ! current_user_can( 'manage_options' ) ) {
        /* If not... */
        remove_menu_page( 'edit-tags.php?taxonomy=TAXONOMY' );
    }
}

#2 – If Submenu Item Under Associated Post Type (see important note below before copying/pasting this one)

add_action( 'admin_menu', 'YOURPREFIX_conditionally_remove_admin_menu_items', 999 );
function YOURPREFIX_conditionally_remove_admin_menu_items() {
    /* Check whether user has admin privileges */
    if ( ! current_user_can( 'manage_options' ) ) {
        /* If not... */
        remove_submenu_page( 'edit.php?post_type=POSTTYPE', 'edit-tags.php?taxonomy=TAXONOMY&post_type=POSTTYPE' );
    }
}

IMPORTANT: On Example #2 above, the key is using &amp; instead of & in the second argument of the second parameter. The comment system here converted my &amp; to &, so you’ll have to change it after copy/paste. (cf. https://gist.github.com/michael-cannon/6701832)

#3 – If Submenu Item Under Settings

add_action( 'admin_menu', 'YOURPREFIX_conditionally_remove_admin_menu_items', 999 );
function YOURPREFIX_conditionally_remove_admin_menu_items() {
    /* Check whether user has admin privileges */
    if ( ! current_user_can( 'manage_options' ) ) {
        /* If not... */
        remove_submenu_page( 'options-general.php', 'edit-tags.php?taxonomy=TAXONOMY' );
    }
}

Hope that helps you, tosca30.

Reference: WordPress Codex | Remove Submenu Page

@joeathomas

Thank you very much for your suggestions.
I tried the first one (using pods_wp_taxonomies filter as explained here) but it doesn’t seem to work. I’ve put an echo statement in the function for debugging, but nothing shows on the screen.
The filter doesn’t seem to be used, either when creating a new custom taxonomy, or when editing an existing one.
I think this should be the right solution, provided I can make it work.

About the Roles and Components, I don’t see how it can be a solution. It allows to create new capabilities, but there is no way to link them to custom taxonomies.

And removing the menu is not a solution either, as nothing will prevent new terms being added in the post edit views. Only the right capability can guarantee that the taxonomy won’t be modified from anywhere.

I will appreciate any idea to make the pods_wp_taxonomies work properly.
Thanks for helping.

You’ll want to clear Pods Cache from Pods Admin > Settings > Clear Pods Cache

Hi Scott. Thank you very much for your input. The cache clearing did the trick and I’ve been able to check that the capabilities have been actually added to my custom taxonomy.

A var_dump for the taxonomy object shows the following:

["cap"]=>
  object(stdClass)#2021 (4) {
    ["manage_terms"]=>
    string(14) "manage_options"
    ["edit_terms"]=>
    string(14) "manage_options"
    ["delete_terms"]=>
    string(14) "manage_options"
    ["assign_terms"]=>
    string(10) "edit_posts"
  }

But these capabilities don’t seem to work when the taxonomy is been used in the admin interface. Only the administrator role has the capability to manage options, so any user with another role should only be able to assign terms, and nothing more.

I guess the problem is probably on the WordPress side (or my understanding of it…), but if somebody has any idea about this issue, I’d be very glad to hear about it.

Thanks again for helping.

The capability you need to uncheck is manage_categories, not manage_options, if you don’t want the user to be able to add new categories or tags to ANY post type’s taxonomies. This will also hide the Custom Taxonomy menu as well.