google-code-export / wordpress-custom-content-type-manager

Automatically exported from code.google.com/p/wordpress-custom-content-type-manager
2 stars 1 forks source link

Unable to publish new post after upgrading to 0.9.6.6 #435

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem? 
1. Updated CCTM to 0.9.6.6
2. Created new content type
3. Created a post with the new content type

What is the expected output? 
New post created successfully.

What do you see instead?
You are not allowed to edit this post. 500 Server Error.

Does the problem continue if you disable all other plugins? 
Yes.

*SYSTEM INFO* 
------------------------ 
Plugin Version: 0.9.6.6-pl
WordPress Version: 3.4.2
PHP Version: 5.3.14
MySQL Version: 5.0.51a-24+lenny5
Server OS: Linux
------------------------ 
ACTIVE PLUGINS: 
------------------------ 
CURRENT THEME: Twenty Eleven v.1.4 
http://wordpress.org/extend/themes/twentyeleven

Original issue reported on code.google.com by tra...@gmail.com on 5 Dec 2012 at 3:46

GoogleCodeExporter commented 9 years ago

Original comment by ever...@fireproofsocks.com on 5 Dec 2012 at 4:19

GoogleCodeExporter commented 9 years ago

Original comment by ever...@fireproofsocks.com on 5 Dec 2012 at 4:24

GoogleCodeExporter commented 9 years ago
I found the culprit: it's the newly added map_meta_cap property and its 
checkbox.  

For the quickie workaround:

1. edit your post-type definition
2. go to the Advanced tab
3. Check the "Map Meta Cap" checkbox
4. Save your post-type definition

That should get you able to edit pages normally.

I'll figure out why WP is choking on the new parameter.

Original comment by ever...@fireproofsocks.com on 5 Dec 2012 at 4:30

GoogleCodeExporter commented 9 years ago
Argh... this is so poorly documented.  The default should be that the 
map_meta_cap is checked, so I've updated that.  I think once that's unchecked, 
then you *must* supply a mapping in the "capabilities" field.

Original comment by ever...@fireproofsocks.com on 5 Dec 2012 at 5:13

GoogleCodeExporter commented 9 years ago
Actually no... the more I read of the official docs and the source code the 
more I am confused.  The default should be unchecked for map_meta_cap... what I 
think is happening is that if it's checked and nothing is in the 
"capabilities", then WP is reverting to a default argument for that (i.e. one 
that works).  Never mind the numerous caveats and overrides peppering the 
source code that set the value to "true" in a majority of cases. 

Part of the problem is that the WP functions are checking for *LITERAL* values 
(e.g. a literal null or a literal false), which is a train-wreck when you're 
dealing with POSTed data, because posted data is always a string.  So if the 
map_meta_cap is unchecked, I have to set it to be a literal null (boolean 
type-casting is not enough).  This is the type of immature, error-ridden and 
ignorant code that makes WP impossible to work with.  Truly awful architecture 
here.

See the following:

 * map_meta_cap() function inside of wp-includes/capabilities.php 
 * get_post_type_capabilities() inside of wp-includes/post.php

In order to use the map_meta_cap checkbox, you must supply a valid mapping in 
the "capabilities" field, e.g.

edit_post=edit_post&read_post=read_post&edit_posts=edit_posts&publish_posts=publ
ish_posts

Here's what the raw code looks like inside of post.php 
get_post_type_capabilities():

'edit_post'          => 'edit_'         . $singular_base,
'read_post'          => 'read_'         . $singular_base,
'delete_post'        => 'delete_'       . $singular_base,
'edit_posts'         => 'edit_'         . $plural_base,
'edit_others_posts'  => 'edit_others_'  . $plural_base,
'publish_posts'      => 'publish_'      . $plural_base,
'read_private_posts' => 'read_private_' . $plural_base,

Where $singular_base by default is whatever is inside the $capability_type 
field (usually "post"), and $plural_base is by default this value plus an "s".

I also added functionality so you can supply alternate plurals now in the 
"capability_type" field by using a comma, e.g. "nucleus,nuclei"

Committed revision 634284.

Original comment by ever...@fireproofsocks.com on 5 Dec 2012 at 5:52

GoogleCodeExporter commented 9 years ago
Works like a charm now. Thank you for the swift fix.

Original comment by tra...@gmail.com on 5 Dec 2012 at 1:13

GoogleCodeExporter commented 9 years ago
works for me too! Thank you for taking care of it so quickly!

Original comment by lisa.hol...@gmail.com on 5 Dec 2012 at 3:47