[wp-testers] Custom post type capabilities not fully set up on registration

Andrew Macaulay-Brook am at theburo.net
Thu Oct 21 11:44:49 UTC 2010


Thanks Andrew - depends on how literally you read Justin's post I guess.  I read "I’ve also added in a couple of extra capabilities that were not shown in my previous tutorial on post types: delete_posts and delete_others_posts." and didn't mentally add "because WordPress doesn't do it."  :-)

I'll use the overloading instead of being lazy and look out for the patch - is it looking definite for 3.1?

A.

On 21 Oct 2010, at 12:29, Andrew Nacin wrote:

> On Thu, Oct 21, 2010 at 7:08 AM, Andrew Macaulay-Brook <am at theburo.net>wrote:
> 
>> I can't work out whether this is covered by
>> http://core.trac.wordpress.org/ticket/14122 or not.
>> 
>> I'm using a custom post type called property, assigning capabilities using
>> 'capability_type' => 'property' and then giving my Editors *_property and
>> *_propertys capabilities wherever I can see they already have *_post or
>> *_posts.
>> 
>> The rationale for all this is that it lets me turn off all the capabilities
>> for blog Posts, hiding the Posts menu for Editors, as this site doesn't use
>> the blog.  I then give my client an Editor level login.
>> 
>> I'm mapping meta-capabilities using Justin Tadlock's code at
>> http://justintadlock.com/archives/2010/07/10/meta-capabilities-for-custom-post-types
>> 
>> Problem: Neither my clients, nor the Admin login can Trash custom posts.
>> 
>> It seems that using the argument 'capability_type' => 'property' only sets
>> up the following mappings in the post type object:
>> 
>> <!-- Capability mapping: stdClass Object
>> (
>>   [edit_post] => edit_property
>>   [edit_posts] => edit_propertys
>>   [edit_others_posts] => edit_others_propertys
>>   [publish_posts] => publish_propertys
>>   [read_post] => read_property
>>   [read_private_posts] => read_private_propertys
>>   [delete_post] => delete_property
>> )
>> -->
>> 
>> ... which I generated using $post_type = get_post_type_object(
>> $post->post_type ); print_r($post_type->cap);
>> 
>> It looks like the mappings for $post_type->cap->delete_posts and
>> $post_type->cap->delete_others_posts aren't being set up.
>> 
> 
> This is indeed the same ticket at issue.
> 
> If you read Justin's post again, you'll see that he deliberately sets up
> those additional capabilities by overloading what gets passed to the
> capabilities array.
> 
> I haven't yet got around to committing my meta capabilities patch for 3.1
> yet, basically because after a few attempts I don't think I've quite nailed
> it yet.
> 
> But what you'll see is when map_meta_cap is true (a new flag for
> register_post_type), then these additional capabilities will need to be set
> up, or WordPress will do it for you, based on capability_type.
> 
> Hope that makes sense.
> 
> Nacin
> _______________________________________________
> wp-testers mailing list
> wp-testers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-testers

Andrew Macaulay-Brook, BEng MBCS CITP, trading as theburo.net
mailto:am at theburo.nethttp://www.theburo.net/



More information about the wp-testers mailing list