Offset yang tidak ditentukan: 0 di> [...] /wp-includes/capabilities.php on line 1067

Hei, saya mendapatkan pesan kesalahan ini di pengaturan localhost saya, tetapi hanya dengan Genesis Framework diaktifkan; WordPress Twenty Eleven berfungsi dengan baik. Ini terjadi ketika saya ingin membuat posting baru. Jika saya me-refresh halaman kesalahan akan terulang, tetapi posting itu sendiri dibuat dan semuanya tampak baik-baik saja.

Apakah ada yang tahu penyababnya?

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

Ini adalah Genesis Framework yang baru saja diinstal dan belum dimodifikasi.

— James Mitch
sumber

Jawaban:

Anda telah menemukan bug di Genesis.

Tumpukan Xdebug Anda melacak jari pelakunya sebagai genesis_save_custom_fields()fungsi yang memanggil current_user_can()dengan kemampuan tunggal (edit_post dan edit_page) yang juga memerlukan argumen tambahan, dalam hal ini ID pos yang hilang.

current_user_can()panggilan panggilan has_cap()mana map_meta_cap()yang melakukan pernyataan beralih pada nama kemampuan. Lihat baris 1067 kapabilitas.php . 2 pemberitahuan offset yang tidak ditentukan berasal dari $ args [0] yang bukan array karena id posting tidak ada dari panggilan current_user_can dalam Genesis.

The Cannot modify header information - headers already sentperingatan yang dari Xdebug mencetak pemberitahuan PHP. Bahkan jika Anda tidak menggunakan Xdebug Anda bahkan tidak akan melihat pemberitahuan PHP kecuali Anda memeriksa log Anda karena kesalahan ada dalam fungsi terlampir ke save_post dan halaman menjadi segar yang mencegah Peringatan / Pemberitahuan / Kesalahan ditampilkan pada halaman bahkan dengan WP_DEBUG disetel ke true.

Memperbaiki:

Pada baris 234 perubahan 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;

Untuk:

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

Juga untuk dicatat, tidak perlu memeriksa post_type karena edit_pagedan edit_postcap dapat dipertukarkan.

— Chris_O
sumber

Ah itu menjelaskan mengapa saya tidak mendapatkan kesalahan pada laptop saya saat menguji apache2 localhost (tanpa xdebug) baik pada webhost saya mengujinya. Terima kasih telah menggali begitu dalam ke dalam ini saya sedikit kewalahan oleh semua hal yang "rumit" ini;). Saya menemukan berbagai bug dalam genesis sekarang, mereka seharusnya menguji ini dengan xdebug dan WP_DEBUG tentu saja. Misalnya menemukan esc_html yang hilang dalam genesis. Mereka membayar pengembang inti Mark Jaquirth untuk mengauditnya berkali-kali, beriklan dengan dugaan kutipan dia mengatakan seberapa aman itu, saya sekarang mempertanyakan kualitas keseluruhan dari Genesis Framework

— James Mitch

Ini diperbaiki di bagasi pada 1,17 oleh Mark Jaquith dalam auditnya. Saya telah mengirimkan tiket untuk kemungkinan rilis 1.9.2.

Secara pribadi, saya percaya ini menjadi masalah WordPress karena map_meta_cap () tidak memeriksa atau membersihkan $ args [0]. Jadi saya telah mengirimkan tiket ke inti WordPress sebagai hasilnya.

— Travis Smith
sumber

"trunk on 1.17" apa? asal 1.1.7? Mengapa kemudian di 1.9.1? Dan bahkan jika itu masalah wordpress, mereka merilis kerangka kerja sebagai stabil di mana Anda bahkan tidak dapat memposting tanpa kesalahan yang mengganggu yang benar-benar menghentikan pageload. WTF? @ Chris_O menjelaskan di atas bahwa itu dapat dengan mudah diperbaiki dengan memberikan argumen. Saya mengambil $ post_id daripada §post-> ID karena itu juga argumen jika fungsi genesis, saya tidak tahu apakah ini bijaksana, juga saya ingin tahu apakah itu benar dan aman untuk mengurangi ini untuk hanya if ( ! current_user_can( 'edit_post', $post_id ) )dan melewati yang lain .

— James Mitch

Maksud saya melepaskannya sebagai stabil bahkan tanpa pengujian jika melakukan tindakan sederhana seperti posting (dengan WP_DEBUG dan xdebug) harus menjadi prosedur normal untuk pengembang atau tidak? Saya bukan ahli dalam hal ini tetapi saya akan mengatakan jika mereka tidak melakukannya dengan salah. Belum lagi mereka memproklamirkan diri sebagai "standar industri kerangka kerja wordpress". Seharusnya tidak ada 2 orang di stack overflow (saya dan @Chris_O) yang mendeteksi dan memperbaiki kode jelek mereka!

— James Mitch

Dan maaf tapi tolong jangan salahkan ini pada inti wordpress! Tidak , bahkan jika itu adalah bug inti yang ada di bawahnya. Dan saya tidak akan tahu di mana saya menemukan lubang keamanan esc_html yang hilang karena 2 alasan. 1. tidak ingin mengambil risiko pemilik situs yang buruk! 2. tugas mereka untuk menemukannya sebesar $ 80 +! Sebenarnya itu harus diperbaiki bertahun-tahun yang lalu! Senang saya mengunduhnya dari github alih-alih membayar untuk ini.

— James Mitch

James, wow. Itu sangat marah. Pertama, Genesis diuji dengan WP_DEBUG sebagai prosedur normal. Ketika saya perhatikan bahwa itu dilakukan untuk core sebagai perbaikan, itu dilakukan pada 17 Januari. Selain itu, ini bukan kelemahan keamanan dalam Genesis atau di WordPress seperti dicatat oleh Jaquith.

— Travis Smith

Jadi, beri tahu saya jika mereka memeriksa mengapa gagal mendeteksi kesalahan yang sangat mudah dideteksi ini, seperti yang saya katakan menghentikan eksekusi, tidak mengarahkan Anda ke editor pos, membiarkan Anda menatap pesan xdebug yang aneh setiap kali Anda melakukan posting / halaman? Biar saya tebak mereka "menguji" itu tetapi pengujian sebelumnya tidak melibatkan melakukan atau mengedit posting ROFLMAO! Katakan apa yang Anda inginkan, pertahankan mereka seperti yang Anda inginkan (karena couse sangat bias) itu adalah fakta bahwa mereka gagal pengujian popper!

— James Mitch