Неопределенное смещение: 0 в> […] /wp-includes/capabilities.php в строке 1067


8

Привет, я получаю эти сообщения об ошибках при настройке localhost, но только с включенной Genesis Framework; WordPress Twenty Eleven работает отлично. Это происходит, когда я хочу создать новый пост. Если я обновлю страницу, ошибка повторится, но сам пост создается, и кажется, что все идет хорошо.

Кто-нибудь знает, что вызывает это?

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

Это недавно установленная, неизмененная платформа Genesis.

Ответы:


12

Вы нашли ошибку в Бытие.

Ваш стек Xdebug отслеживает виновника как genesis_save_custom_fields()функцию, которая вызывает current_user_can()с единственной возможностью (edit_post и edit_page), которая также требует дополнительного аргумента, в данном случае идентификатор сообщения, который отсутствует.

current_user_can()звонки, has_cap()которые звонки, map_meta_cap()которые делают оператор switch для имени возможности. Смотрите строку 1067 ofabilities.php . 2 неопределенных уведомления о смещениях взяты из $ args [0], который не является массивом, потому что идентификатор поста отсутствует в вызове current_user_can в Genesis.

Cannot modify header information - headers already sentПредупреждения являются из Xdebug распечатывания PHP уведомлений. Фактически, если бы вы не использовали Xdebug, вы бы даже не увидели уведомления PHP, если бы вы не проверили ваши журналы, потому что ошибка в функции, прикрепленной к save_post, и страница обновляется, что предотвращает отображение предупреждений / уведомлений / ошибок на странице. даже если для WP_DEBUG установлено значение true.

Fix:

В строке 234 файла lib / functions / options.php измените:

/** 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;

Для того, чтобы:

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

Также отметим, что нет необходимости проверять post_type, потому что edit_pageи edit_postcaps являются взаимозаменяемыми.


Ах, это объясняет, почему я не получил никаких ошибок на своем ноутбуке во время тестирования localhost apache2 (без xdebug) ни на веб-хосте, который я тестировал. Спасибо за то, что закопались так глубоко, я был немного ошеломлен всеми этими "сложными" вещами;). Теперь я обнаружил различные ошибки в генезисе, они, конечно, должны проверить это с помощью xdebug и WP_DEBUG. Например нашел недостающий esc_html в генезисе. Они платили разработчику ядра wp Марку Джаквту за проверку его безопасности несколько раз, рекламируя его предполагаемыми цитатами о том, насколько он безопасен, и теперь я подвергаю сомнению общее качество Genesis Framework
Джеймс Митч

0

Это было исправлено в транке 1.17 Марком Джакитом в его ревизии. Я отправил заявку на возможный релиз 1.9.2.

Лично я считаю, что это проблема WordPress, так как map_meta_cap () не проверяет и не очищает $ args [0]. Поэтому я отправил тикет в ядро ​​WordPress.


"багажник на 1.17" что? Бытие 1.1.7? Почему тогда в 1.9.1? И даже если это проблема WordPress, они выпускают фреймворк как стабильный, где вы даже не можете публиковать без раздражающей ошибки, которая полностью останавливает загрузку страниц. WTF? @Chris_O объяснил выше, что это легко исправить, просто указав аргумент. Я взял $ post_id вместо §post-> ID, потому что это также аргумент, если функция genesis, я не знаю, если это разумно, а также мне интересно, если это правильно и безопасно, чтобы уменьшить это просто if ( ! current_user_can( 'edit_post', $post_id ) )и пропустить другие ,
Джеймс Митч

Я имею в виду выпуск его как стабильного без даже тестирования, если выполнение простых действий, таких как публикация (с WP_DEBUG и xdebug) должно быть нормальной процедурой для разработчиков или нет? Я не эксперт в этом, но я бы сказал, если они не делают это неправильно. Не говоря уже о том, что они являются самопровозглашенным «отраслевым стандартом фреймворков WordPress». Там должно не быть 2 парней на переполнение стека (меня и @Chris_O) обнаружения и фиксации их дерьмовый код!
Джеймс Митч

И извините, но, пожалуйста, не вините это за ядро ​​WordPress! Это не так , даже если это основная ошибка, лежащая под этим. И я не скажу, где я нашел дыру в безопасности отсутствующего esc_html по 2 причинам. 1. Не хочу рисковать бедными владельцами сайтов! 2. это их работа, чтобы найти его за $ 80 +! На самом деле это должно быть исправлено несколько лет назад! Рад, что я скачал его с GitHub вместо того, чтобы платить за это.
Джеймс Митч

Джеймс, вау. Это много гнева. Во-первых, Genesis протестирован с WP_DEBUG как обычная процедура. Когда я заметил, что это было исправлено для ядра, это было совершено 17 января. Кроме того, это не является недостатком безопасности в Genesis или WordPress, как отметил Jaquith.
Трэвис Смит

Так скажите мне, если они все-таки проверили, почему не удалось обнаружить эту невероятно легкую для обнаружения ошибку, которая, как я сказал, останавливает выполнение, а не перенаправляет вас в редактор сообщений, позволяющий вам смотреть чертово сообщение xdebug каждый раз, когда вы делаете материал пост / страница? Позвольте мне предположить, что они "проверили" это, но их предварительная процедура тестирования не включала создание или редактирование сообщения ROFLMAO! Скажи, что хочешь, защищай их как хочешь (из-за предвзятого предубеждения) это факт, что они не прошли тестирование Поппера!
Джеймс Митч
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.