Doug

I’ve figured out that, after some period of time, for some reason WordPress switches the theme/template to the word “default”. Since there is no “default” directory in the templates folder, it throws errors. I don’t know where or why this happens since the default theme, should there be problems, is twentytwelve.

As a workaround for the moment, I’ve created a small plugin which checks to see if the template returned by the get_template() function is equal to “default”. If so, it switches the theme back to my custom theme.

I had previously reinstalled WordPress and seemed to experience this problem without plugins, database changes, and with the default theme. I wonder if it is a PHP issue; I see now that PHP 5.2.4 is required for WordPress 3.2, while the server is running PHP 5.2.17.

Yes, it broke again this morning. Twenty Twelve was active. When I went to the themes manager it said “The active theme is broken. Reverting to the default theme.” It switched to the default theme. When I checked again, it had reverted back to Twenty Twelve theme.

I edited it directly. To be clear, I left the TwentyEleven and TwentyTwelve themes untouched and in place; I copied to a new directory in the themes folder to create the custom theme.

A user with ability to edit their own posts but not others couldn’t edit if they weren’t listed as the first author of a post. Typically their role would be that of Author. I believe by default Authors have the publish_posts capability. I was using the user-role-editor to add customize roles. The publish_posts capability was not granted to Authors and thus a problem.

If Authors have the publish_posts capability by default this problem won’t appear. It only becomes a problem if they don’t have the publish_post capability. (The publish_post is for granting/denying permission to publish new posts/pages.) As mentioned, the system was checking the publish_posts capability to allow or deny editing of an already published post. The problem is that this is the wrong capability; the edit_published_posts capability is for allowing/denying permission to edit already published posts.

Ok. It took me a long time, but I figured out what the problem is. Line 833 of co-authors-plus.php checks for the publish_posts capability for already existing posts. The correct capability it ought to be checking is edit_published_posts. Therefore, change the two occurrences of publish_posts to edit_published_posts and it seems to work properly. The modified line will then look like: if ( 'publish' == $post->post_status && ( ! isset( $allcaps[$post_type_object->cap->edit_published_posts] ) || ! $allcaps[$post_type_object->cap->edit_published_posts] ) )

I tried what you suggested earlier in this thread without success.

I’m presently having this issue.