Độ lệch không xác định: 0 in> [Nhận] /wp-includes/capabilities.php trên dòng 1067


8

Xin chào, tôi nhận được thông báo lỗi này trên thiết lập localhost của mình, nhưng chỉ khi bật Genesis Framework; WordPress Twenty Eleven hoạt động tốt. Điều này xảy ra khi tôi muốn tạo một bài viết mới. Nếu tôi làm mới trang, lỗi sẽ lặp lại, nhưng bài đăng sẽ được tạo và mọi thứ dường như ổn.

Có ai biết nguyên nhân của điều này?

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

Đó là một Genesis Framework mới được cài đặt, chưa sửa đổi.

Câu trả lời:


12

Bạn đã tìm thấy một lỗi trong Genesis.

Ngăn xếp Xdebug của bạn theo dõi ngón tay thủ phạm là genesis_save_custom_fields()hàm gọi current_user_can()với khả năng số ít (edit_post và edit_page) cũng yêu cầu một đối số bổ sung, trong trường hợp này là ID bài đăng bị thiếu.

current_user_can()gọi has_cap()mà gọi map_meta_cap()một câu lệnh chuyển đổi trên tên khả năng. Xem dòng 1067 của ability.php . 2 thông báo bù không xác định là từ $ args [0] không phải là một mảng vì id bài viết bị thiếu trong lệnh gọi current_user_can trong Genesis.

Các Cannot modify header information - headers already sentcảnh báo được từ Xdebug in ra thông báo PHP. Trong thực tế nếu bạn không sử dụng Xdebug, bạn thậm chí sẽ không thấy các thông báo PHP trừ khi bạn kiểm tra nhật ký của mình vì lỗi nằm ở chức năng được lưu vào save_post và trang được làm mới để ngăn Cảnh báo / Thông báo / Lỗi hiển thị trên trang ngay cả với WP_DEBUG được đặt thành đúng.

Sửa chữa:

Trên dòng 234 của lib / tests / Options.php thay đổi:

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

Đến:

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

Cũng cần lưu ý, không cần kiểm tra post_type vì edit_pageedit_postmũ có thể hoán đổi cho nhau.


Ah điều đó giải thích tại sao tôi không gặp bất kỳ lỗi nào trên máy tính xách tay của mình trong khi kiểm tra localhost apache2 (không có xdebug) cũng không phải trên webhost tôi đã kiểm tra nó. Cảm ơn vì đã đào sâu vào vấn đề này, tôi đã bị choáng ngợp bởi tất cả những thứ "phức tạp" này;). Tôi đã tìm thấy nhiều lỗi khác nhau trong genesis bây giờ, họ có nghĩa vụ phải kiểm tra điều này với xdebug và WP_DEBUG tất nhiên. Ví dụ, tìm thấy một esc_html bị thiếu trong genesis. Họ đã trả tiền cho nhà phát triển cốt lõi wp Mark Jaquirth để kiểm toán bảo mật nhiều lần, quảng cáo với những trích dẫn được cho là của anh ta nói rằng nó an toàn đến mức nào, bây giờ tôi đặt câu hỏi về chất lượng chung của Genesis Framework
James Mitch

0

Điều này đã được cố định trong thân cây vào ngày 1.17 bởi Mark Jaquith trong cuộc kiểm toán của mình. Tôi đã gửi một vé cho bản phát hành 1.9.2 có thể.

Cá nhân, tôi tin rằng đây là sự cố của WordPress vì map_meta_cap () không kiểm tra hoặc vệ sinh $ args [0]. Vì vậy, tôi đã gửi một đến cốt lõi WordPress.


"Thân trên 1.17" là gì? gen 1.1.7? Tại sao lại là 1.9.1? Và ngay cả khi đó là sự cố wordpress, họ sẽ phát hành một khung ổn định khi bạn thậm chí không thể đăng mà không gặp lỗi gây khó chịu hoàn toàn khi tải trang. WTF? @Chris_O đã giải thích ở trên rằng nó có thể dễ dàng sửa lỗi đơn giản bằng cách đưa ra đối số. Tôi đã lấy $ post_id thay vì §post-> ID vì đó cũng là một đối số nếu chức năng genesis, tôi không biết điều này có khôn ngoan không, tôi cũng tò mò về việc liệu nó có đúng và an toàn để giảm điều này chỉ if ( ! current_user_can( 'edit_post', $post_id ) )và bỏ qua những cái khác không .
James Mitch

Tôi có nghĩa là phát hành nó ổn định mà không cần kiểm tra nếu thực hiện một hành động đơn giản như bài đăng (với WP_DEBUG và xdebug) có phải là một quy trình bình thường cho nhà phát triển hay không? Tôi không phải là một chuyên gia về điều này nhưng tôi sẽ nói nếu họ không làm sai. Chưa kể rằng họ là người tự xưng là "tiêu chuẩn công nghiệp của khung wordpress". Có nên không có 2 chàng trai trên stack overflow (tôi và @Chris_O) phát hiện và sửa chữa mã crappy của họ!
James Mitch

Và xin lỗi nhưng xin đừng đổ lỗi cho điều này trên lõi wordpress! Không , ngay cả khi đó là một lỗi cốt lõi nằm bên dưới này. Và tôi sẽ không nói nơi tôi tìm thấy lỗ hổng bảo mật của esc_html bị thiếu vì 2 lý do. 1. không muốn mạo hiểm chủ sở hữu trang web nghèo! 2. công việc của họ là tìm nó với giá $ 80 +! Trong thực tế nó nên được cố định từ nhiều năm trước! Vui mừng tôi đã tải nó từ github thay vì trả tiền cho việc này.
James Mitch

James, wow. Đó là rất nhiều sự tức giận. Đầu tiên, Genesis được thử nghiệm với WP_DEBUG như một quy trình thông thường. Khi tôi lưu ý rằng nó đã được cam kết cốt lõi như là một sửa chữa, nó đã được cam kết vào ngày 17 tháng 1. Hơn nữa, nó không phải là một lỗ hổng bảo mật trong Genesis hoặc trong WordPress như Jaquith đã lưu ý.
Travis Smith

Vì vậy, hãy cho tôi biết nếu họ đã kiểm tra xem tại sao không phát hiện ra lỗi cực kỳ dễ phát hiện này như tôi đã nói dừng thực thi, không chuyển hướng bạn đến trình chỉnh sửa bài đăng cho phép bạn nhìn chằm chằm vào tin nhắn xdebug kỳ dị mỗi khi bạn đăng bài / trang? Hãy để tôi đoán họ đã "thử nghiệm" nó nhưng tiền lệ thử nghiệm của họ không liên quan đến việc thực hiện hoặc chỉnh sửa bài ROFLMAO! Nói những gì bạn muốn, bảo vệ họ như bạn muốn (vì couse rất thiên vị) đó là một thực tế rằng họ đã thất bại trong thử nghiệm popper!
James Mitch
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.