Create (not just declare) new custom capabilities when creating a new content type with a custom capability_type

[GoogleCodeExporter]

This is a follow-up to the bug report I made recently regarding custom 
capabilities: 
http://code.google.com/p/wordpress-summarize-posts/issues/detail?id=39

When creating a new custom content type that has a different capability_type 
than "post", say you name it "answer", then this will declare a new set of 
custom capabilities named edit_answers, read_answers, etc (instead of using the 
existing edit_posts, read_posts etc). This is useful as you can then assign 
these to user roles.

The problem is that your plugin doesn't also create and save the custom 
capabilities as well. I had to create and save them manually one by one, I used 
a plugin called "User Role Editor".

It would be really useful (also expected) that when creating a new content type 
with a custom capability_type, the custom capabilities to also be created.

Some more info on this topic:

http://justintadlock.com/archives/2010/07/10/meta-capabilities-for-custom-post-t
ypes
http://codex.wordpress.org/Function_Reference/register_post_type

(see the capability_type and capabilities sections)

Original issue reported on code.google.com by bogdan.a...@gmail.com on 18 Feb 2013 at 3:00

[GoogleCodeExporter]

Original comment by ever...@fireproofsocks.com on 18 Feb 2013 at 3:41

• Changed state: InReview

[GoogleCodeExporter]

I don't think it makes sense for the CCTM to create new capabilities... I just 
can't see any good way to do that cleanly.  If you need thorough permissions 
management with a GUI behind every component, you could use MODX -- WordPress 
is a poor choice when it comes to customizations like this.  Can you 
demonstrate a way to do this in a clean way?  There are just so many possible 
customizations here, I just can't imagine a way to do this, and the WP core is 
so inconsistent with this stuff that building a GUI for it seems premature...

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 12:56

[GoogleCodeExporter]

I disagree. This should exist in CCTM. 

You provide the option of using a custom capability_type when creating a new 
content type. I take it that you and your users aren't using that feature too 
much and stick to "post" as the capability type (I inferred this from the docs 
which say that this feature is untested in CCTM).

This is what happened to me. Created a custom content type with a cap type 
called "answer" rather than the default "post", which becomes the base of a 
series of custom caps (edit_answers, read_answers, etc ... see Codex above). 

However, because CCTM does not actually create these caps, no roles in WP 
actually have it, including the admin. This meant that I couldn't add any 
content of that type. I had to first create all those individual caps manually 
before I could do anything with the newly created content type. I used a plugin 
called "User Role Editor" to create the individual custom caps.

Your plugin, since it defines custom content types with the option of custom 
caps, should also create those caps and assign them to the admin role, which by 
default should have all capabilities.

You can achieve this by doing the following (note that I haven't tested it).

$capability_type = 'answer'; // get this from the form submitted by the user

$capabilities = array(
    'edit_post'              => "edit_{$capability_type}",
    'read_post'              => "read_{$capability_type}",
    'delete_post'            => "delete_{$capability_type}",
    'edit_posts'             => "edit_{$capability_type}s",
    'edit_others_posts'      => "edit_others_{$capability_type}s",
    'publish_posts'          => "publish_{$capability_type}s",
    'read_private_posts'     => "read_private_{$capability_type}s",
    'delete_posts'           => "delete_{$capability_type}s",
    'delete_private_posts'   => "delete_private_{$capability_type}s",
    'delete_published_posts' => "delete_published_{$capability_type}s",
    'delete_others_posts'    => "delete_others_{$capability_type}s",
    'edit_private_posts'     => "edit_private_{$capability_type}s",
    'edit_published_posts'   => "edit_published_{$capability_type}s",
);

// the above is an exhaustive list, see from 
http://codex.wordpress.org/Function_Reference/register_post_type
// you generally don't need all of them

$role = get_role('administrator');

foreach ($capabilities as $cap)
{
    $role->add_cap($cap);
}

The above should best be put as a callback added to the 'admin_init' action. 
Again, I haven't tested this code, but I hope you can see where I'm getting at.

Original comment by bogdan.a...@gmail.com on 19 Feb 2013 at 2:30

[GoogleCodeExporter]

You are correct: I'm not using this feature much because WordPress simply does 
not handle permissions very well.  You can already add the capabilities you 
need via the "Capabilities" field.  You just have to add the array in a URL 
format, e.g. 

edit_post=edit_answer&read_post=read_answer

I'm sorry if that's not very streamlined, but it works.  So your initial 
request is already implemented.  The goal of the CCTM's definition page is to 
offer a GUI to all the arguments for register_post_type, and it does do that.  

Maybe the best thing to do here would be to add the above array if the 
Capabilities field is left blank.  If a user wants to customize the array, then 
they can enter in their own custom capabilities.  That's more or less how the 
labels work: you can override them, but if you leave them blank, the CCTM 
enters in the default values for you.

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 2:44

[GoogleCodeExporter]

But your plugin only has a field called "Capability Type", which is different 
than the Capabilities array. The former should generate the latter and also 
register them to the administrator role, like in my example above.

Typing that ugly and long query string really defeats the purpose of having a 
GUI ... honestly.

It is after all your plugin, but I don't see why not add my code above to it to 
complete the process. Currently, it at least unexpected. I would say actually 
incomplete with regards to custom capabilities, which you do allow.

It's a fantastic plugin though! The relation field is really cool and already 
saved me time (I've only installed your plugin it yesterday)

Original comment by bogdan.a...@gmail.com on 19 Feb 2013 at 2:53

[GoogleCodeExporter]

Just to make sure we're on the same page, here's the "Capabilities" field: 
http://www.screencast.com/t/z1h4rvCOZI

I cannot take it on my own shoulders to write a GUI for all the millions of 
parts of WP that were never done correctly in the first place -- honestly, the 
register_post_type() function is a god-awful mess of inputs and data types with 
clearly no input from anyone with experience developing apps -- most of the WP 
core is just terrible, so developing stuff for WP *completely* burns me out.  
WP is so poorly architected, it's a lost cause for most of this stuff, and the 
mentality of the WP users is usually "this should all be free", so it rarely 
leads to paying work for me, so it's a lose-lose scenario: I have to waste 
hours of time developing in an awful framework, and I rarely get any pay for 
it.  I don't really care if it looks pretty when I know that under the hood, 
it's a nightmare.  WordPress simply is not suitable for that kind of time 
commitment.

The GUI here is not a high priority here because this is something that a 
developer would type ONCE.  If it takes you 3 minutes to type a string ONCE, 
then it's probably not worth the time to spend weeks developing and testing GUI 
for it.  

I think I proposed a sensible solution: I can add your code and add those 
capabilities if that field is left blank.  You get all the standard 
capabilities.  But if you want to customize them, then you can spend the few 
minutes typing them in.  That's really as much as I can do without a paying 
project.

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 3:09

[GoogleCodeExporter]

That's not what I see in 0.9.6-pl (was the latest yesterday): 
https://www.dropbox.com/s/s0y29qkpgiffr1e/SNAG_Program-0076.png

I'm not saying you should take on any extra responsibility. I was saying that 
given you have chosen to offer a functionality, it would be nice for it to be 
complete. Currently I think it's at the best unexpected. Using your plugin to 
create a custom content type with a custom cap type resulted in me not being 
able to actually use it. This can quite easily be fixed using a piece of code 
like the one I suggested above.

I don't want a GUI to customize each capability but I think CCTM should take 
the cap type (just the core name) and generate all the caps automatically that 
are based on it.

Otherwise, I completely agree with you that WP is probably one of the worst 
written code that I have ever come across ... even in the PHP world (which is 
already pretty horrible).

I took the time to signal some bugs and suggestion for your plugin and offered 
solutions for all of them. It really is your call to implement it or not.

Cheers and keep up this great work!

p.s. If you actually choose not to create and assign the custom caps to the 
admin role, you should at least put a really big bold red warning in the form 
next to the custom cap name to warn the user that he needs to manually create 
those caps (either by writing code or using a plugin, and you should give a few 
links to solutions). 

Original comment by bogdan.a...@gmail.com on 19 Feb 2013 at 3:22

[GoogleCodeExporter]

You're not running the latest version -- please update and then review your 
request.  0.9.7 was released today (providing the WP repo didn't crap out).

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 3:39

[GoogleCodeExporter]

Yes, I realized it. Now I have to see which of the bugs I submitted (and fixed) 
since yesterday you have implemented in 0.9.7. At the moment I'm most 
interested in the 'private' and the custom cap check (rather than the 
hard-coded edit_posts that you had before).

WP repo shows 0.9.7-dev ... I presume that's not final. I took it off svn just 
now.

Original comment by bogdan.a...@gmail.com on 19 Feb 2013 at 3:53

[GoogleCodeExporter]

Ugh... no 0.9.7-dev is current.  Should be "pl"... damn WP repo is such a piece 
of poorly designed crap I could punch my face through the wall.  Anyhow, review 
the current build and let me know what applies here.  You can see why I ask for 
users to paste the system info stuff when a bug or feature request is submitted.

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 3:59

[GoogleCodeExporter]

Ok, I see the new GUI. Can you explain what do you mean by:

 Map Meta Cap
Whether to use the internal default meta capability handling. If checked, you 
must supply a valid mapping in the "Capabilities" field.

If I supply that ugly query string, will CCTM create the custom caps and assign 
them to the admin role? Just asking. I don't get what it does.

I still think that it makes more sense to create and assign the caps 
automatically from the capability_type if the Capabilities field is left blank. 
Hope you'll add that in a future version.

Original comment by bogdan.a...@gmail.com on 19 Feb 2013 at 4:22

[GoogleCodeExporter]

I don't get all this stuff either: the WP docs are absolute crap and the core 
developers should probably be slapped, and that's about as civil as I can be.  
I did some testing on this and I updated some of the WP codex, but if their 
insane architecture and function arguments make sense to you, you're a better 
man than I.  I really hate WP's lack of professionalism... it's such a wasted 
effort most of the time.

From what I remember of my snooping of the source code, that array is ignored 
unless the map_meta_cap option is set to true.  So basically in your case: 
you'd add the URL-encoded array to the Capabilities field and then check the 
"Map Meta Cap" checkbox and you should have what you need.

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 4:28

[GoogleCodeExporter]

> I still think that it makes more sense to create and assign the caps 
automatically from the capability_type if the Capabilities field is left blank. 
Hope you'll add that in a future version.

YES, this is exactly what I'm suggesting that this request turns into.  This 
wasted a lot of time because you weren't using the most recent version of the 
plugin and you did not paste your system info in the request.  I'm just 
extremely slammed right now and extremely stressed, so I don't have much time 
to spare.  This could have been fixed by now.

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 4:30

[GoogleCodeExporter]

In the other bug report I said I'm using 0.9.6-pl. When I posted this request, 
0.9.6 was the latest I could download from the WP repo. 

I also think I explained from pretty early on what I'd like to see CCTM do wrt 
to custom caps, i.e. use the capability_type field to automatically generate 
all the individual caps (and assign them to the admin role). I never requested 
a GUI to enter manually each cap.

I provided a pretty clear piece of code as (part of) a solution.

I never said the WP architecture and function arguments makes sense to me.

The new 0.9.7 version doesn't address this request. This request still stands.

I don't quite get your directed anger but to each his own. My time is also full 
and valuable.

Kind regards.

Original comment by bogdan.a...@gmail.com on 19 Feb 2013 at 4:47

[GoogleCodeExporter]

I'm just stressed beyond belief and I am not a patient person, and WP drives me 
insane.  

I think we're mis-communicating: if I implement your code when the value of the 
Capabilities field is empty and override it when  it has a value, then I think 
this would meet your needs.  Yes?

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 5:00

[GoogleCodeExporter]

Yes, that was the idea, i.e. have CCTM automatically create the caps if a 
custom cap type was specified.

I don't care about specifying individual caps. Makes the whole thing more prone 
to errors and inconsistency if you ask me.

Original comment by bogdan.a...@gmail.com on 19 Feb 2013 at 5:10

[GoogleCodeExporter]

See also 
http://code.google.com/p/wordpress-custom-content-type-manager/issues/detail?id=
409

Here's the current code from CCTM.php line 399:

if (empty($def['capabilities'])) {
    unset($def['capabilities']);
}
elseif(is_scalar($def['capabilities'])) {
    $capabilities = array();
    parse_str($def['capabilities'], $z);
    $def['capabilities'] = $capabilities;
}

So instead of unsetting the capabilities argument, I'll add in your code in 
there so it will kick in... my concern is that the register_post_type function 
may not handle extra information gracefully.

Committed revision 670448.  This will go out on 0.9.7.1 -- you can test the 
version on the head and report back if there are problems.  

Original comment by ever...@fireproofsocks.com on 19 Feb 2013 at 6:36

• Changed state: Fixed

[GoogleCodeExporter]

I'm restating the fact that I haven't tested my code. I'm sure I don't need to 
say this as you appear to be an experienced dev, but it would be wise to give 
it a test before releasing it.

Original comment by bogdan.a...@gmail.com on 22 Feb 2013 at 2:49

[GoogleCodeExporter]

Thanks.  I didn't update unit tests for it... this is harder to test because it 
relies on manager pages loading instead of just API methods.  If you're able to 
download the SVN head and verify that the fix works in your use case, that 
would be useful feedback.

Original comment by ever...@fireproofsocks.com on 22 Feb 2013 at 5:01