8

Hey I get this error messages on my localhost setup, but only with the Genesis Framework enabled; WordPress Twenty Eleven works fine. This happens when I want to create a new post. If I refresh the page the error will repeat, but the post itself gets created and everything seems to go fine.

Does anyone know what causes this?

Notice: Undefined offset: 0 in /var/www/secret/htdocs/wp-includes/capabilities.php on line 1067
Notice: Undefined offset: 0 in /var/www/secret/htdocs/wp-includes/capabilities.php on line 1067
Warning: Cannot modify header information - headers already sent by (output started at /var/www/secret/htdocs/wp-includes/capabilities.php:1067) in /var/www/secret/htdocs/wp-includes/pluggable.php on line 876

It's a newly installed, unmodified Genesis Framework.

Improve this question

2 Answers 2

Reset to default
12

You have found a bug in Genesis.

Your Xdebug stack trace fingers the culprit as the genesis_save_custom_fields() function which calls current_user_can() with a singular capability (edit_post and edit_page) which also requires an additional argument, in this case the post ID which is missing.

current_user_can() calls has_cap() which calls map_meta_cap() which does a switch statement on the capability name. See line 1067 of capabilities.php. The 2 undefined offset notices are from $args[0] which is not an array because the post id is missing from the current_user_can call in Genesis.

The Cannot modify header information - headers already sent warning are from Xdebug printing out the PHP notices. In fact if you were not using Xdebug you wouldn't even see the PHP notices unless you checked your logs because the error is in a function attached to save_post and the page gets refreshed which prevents Warnings / Notices / Errors from being displayed on the page even with WP_DEBUG set to true.

Fix:

On line 234 of lib/functions/options.php change:

/** Check the user allowed to edit the post or page */
if ( ( 'page' == $post->post_type && ! current_user_can( 'edit_page' ) ) || ! current_user_can( 'edit_post' ) )
    return;

To:

/** Check the user allowed to edit the post or page */
if ( ! current_user_can( 'edit_post', $post->ID ) )
    return;

Also to note, there is no need to check the post_type because the edit_page and edit_post caps are interchangeable.

Improve this answer
1
  • Ah that explains why i did not get any errors on my laptop while testing localhost apache2 (without xdebug) neither on a webhost i tested it. Thanks for digging so deep into this i was a little overwhelmed by all this "complicated" stuff ;). I found various bugs in genesis now, they are supposed to test this with xdebug and WP_DEBUG of course. For instance found a missing esc_html in genesis. They payed wp core developer Mark Jaquirth to security audit it multiple times, advertise with supposed quotes of him saying how secure it is, i now question the overall quality of the Genesis Framework
    – James Mitch
    Feb 2, 2013 at 13:42
0

This was fixed in trunk on 1.17 by Mark Jaquith in his audit. I have submitted a ticket for a possible 1.9.2 release.

Personally, I believe this to be a WordPress issue since map_meta_cap() does not check or sanitize $args[0]. So I've submitted a ticket to WordPress core as a result.

Improve this answer
5
  • "trunk on 1.17" what? genesis 1.1.7? Why is it then in 1.9.1? And even if its a wordpress issue, they release a framework as stable where you can't even post without a annoying error that completely stops pageload. WTF? @Chris_O explained above that its can easy fixed simple by giving it the argument. I took $post_id instead of §post->ID because its also a argument if the genesis function, i don't know if this is wise, also i am curious about if its right and secure to reduce this to just if ( ! current_user_can( 'edit_post', $post_id ) ) and skip the others.
    – James Mitch
    Feb 4, 2013 at 19:19
  • I mean releasing it as stable without even testing if doing a simple action like a post (with WP_DEBUG and xdebug) should be a normal procedure for developers or not? I am not a expert on this but i would say if they don't the are doing it wrong. Not to mention that they are the self proclaimed "industry standard of wordpress frameworks". There should not be 2 guys on stack overflow (me and @Chris_O) detecting and fixing their crappy code!
    – James Mitch
    Feb 4, 2013 at 19:37
  • And sorry but please don't blame this on wordpress core! It's not, even if it is a core bug laying underneath this. And i won't tell where i found the security hole of a missing esc_html for 2 reasons. 1. not want to risk poor site owners! 2. its their job to find it for $80+! In fact it should be fixed years ago! Glad i downloaded it from github instead of paying for this.
    – James Mitch
    Feb 4, 2013 at 19:39
  • James, wow. That's a lot of anger. First, Genesis is tested with WP_DEBUG as normal procedure. When I noted that it was committed to core as a fix, it was committed on Jan 17th. Furthermore, it is not a security flaw in Genesis or in WordPress as noted by Jaquith.
    – Travis Smith
    Feb 19, 2013 at 14:17
  • So tell me if they did check it why the failed to detect this incredibly easy to detect error that like i said stops execution, not redirecting you to the post editor letting you stare a the freaking xdebug message every time you do post/page stuff? Let me guess they "tested" it but their testing precedure not involved doing or editing a post ROFLMAO! Say what you want, defend them as you want (because of couse are extremely biased) it's a fact that they failed popper testing!
    – James Mitch
    Feb 26, 2013 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.