Undefined offset: 0 in > […] /wp-includes/capabilities.php on line 1067

0 Views

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?

Read More
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.

Post Views: 0

Related posts

Leave a Reply

2 comments

  1. 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.

  2. 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.