Search Results

I have used map_meta_cap filter to solve this. … However even though it goes through my function correctly it will not function properly, return ['do_not_allow']; is not working as intended and I don't know why, it seemingly does not do anything. …

The only way to explicitly deny a capability for a super admin is to use the map_meta_cap filter to return do_not_allow when the custom capability is checked. … Because map_meta_cap() is run before the super admin check, we can use this filter to explicitly return do_not_allow when checks for current_user_can( 'custom_capability' ) are made for a super admin that …

The map_meta_cap filter allows us change this mapping. So we'll use it to map delete_post to do_not_allow for this specific post. Then no users will be able to delete that post. … '; } return $caps; } add_filter( 'map_meta_cap', 'wpse_312694_restrict_page_deletion', 10, 4 ); …

Instead, when registering your custom post type, you need to set the create_posts value to do_not_allow (or false in Wordpress versions below 4.5) and crucially set the map_meta_cap to true. … ), 'map_meta_cap' => true, // With this set to true, users will still be able to edit & delete posts )); If map_meta_cap is left out, it defaults to false and although you've disabled the ability …

with the Roles and Capabilities system, but broadly, I think it might be fairly directly accomplished by adding a list of Roles to terms' meta-data, then comparing those roles against a user's within a map_meta_cap … filter, producing either the current post's read_post meta capability or the do_not_allow capability to enforce whether or not they can read the post. …

users or user roles, including administrators, but if Multisite is enabled, then those who are super admins would always be able to manage (e.g. edit or delete) the posts in the post type, unless if do_not_allow … is present in their capabilities (as returned by map_meta_cap()) — see WP_User::has_cap(). …

Full credit to this answer on Stack Overflow: you need to set the create_posts value to do_not_allow (or false in Wordpress versions below 4.5) and crucially set the map_meta_cap to true: register_post_type … ( 'custom_post_type_name', array( 'capability_type' => 'post', 'capabilities' => array( 'create_posts' => 'do_not_allow', // Prior to Wordpress 4.5, this was false ), 'map_meta_cap …

','disable_caps',10,2); } function turn_on_caps() { remove_filter('ngettext','disable_theme'); remove_filter('map_meta_cap','disable_caps',10,2); } function disable_caps($caps,$cap) { if … ( 'update_core' == $cap ) $caps[] = 'do_not_allow'; if( 'switch_themes' == $cap ) $caps[] = 'do_not_allow'; return $caps; } function disable_theme($text) { if('Theme …

The most performant way to do this is probably by hooking into map_meta_cap to conditionally disallow the install_plugins capability. There are no database calls involved with that. … if ( count( $plugins ) > 10 ) { $caps[] = 'do_not_allow'; } } return $caps; } I recommend you to watch this video by John Blackbourn to learn more about map_meta_cap and friends. …

I think an elegant way to accomplish this would be to hook into map_meta_cap and deny users as though they do not have the capability to edit the post. … == 'edit_post' ) return $caps; $post_id = $args[0]; if( get_post_meta( $post_id, 'global_post', true ) ) $caps[] = 'do_not_allow'; return $caps; } An introduction to roles & capabilities …

Here's another approach using the map_meta_cap filter that's applied within the map_meta_cap() function within the has_cap() method of the WP_User class (PHP 5.4+): add_filter( 'map_meta_cap', function … empty( $args[0] ) ) return $caps; // Target the payment and transaction post types if( in_array( get_post_type( $args[0] ), [ 'payment', 'transaction' ], true ) ) $caps[] = 'do_not_allow …

The problem is that WordPress has a global override in the method map_meta_cap() in wp-includes/capabilities.php, which ignores the unfiltered_html capability in a multisite install if the user is not … if ( defined( 'DISALLOW_UNFILTERED_HTML' ) && DISALLOW_UNFILTERED_HTML ) { $caps[] = 'do_not_allow'; // } elseif ( is_multisite() && ! …

You can essentially 'block' the capability install_themes using; function __block_caps( $caps, $cap ) { if ( $cap === 'install_themes' ) $caps[] = 'do_not_allow'; return $caps; } add_filter … ( 'map_meta_cap', '__block_caps', 10, 2 ); …

function ra_block_tp_edit( $caps, $cap ) { if($cap == 'edit_plugins' ) $caps[] = 'do_not_allow'; return $caps; } add_filter( 'map_meta_cap', 'ra_block_tp_edit', 10, 3 ); Best of luck. …

However, you can filter capabilities checks and change them on the fly using the map_meta_cap. … If they are, set the required capabilities to 'do_not_allow' * to prevent them editing. */ if ( ! …