Desplazamiento indefinido: 0 en> [...] /wp-includes/capabilities.php en la línea 1067

Hola, recibo estos mensajes de error en mi configuración localhost, pero solo con el Marco Genesis habilitado; WordPress Twenty Eleven funciona bien. Esto sucede cuando quiero crear una nueva publicación. Si actualizo la página, el error se repetirá, pero la publicación en sí se crea y todo parece ir bien.

¿Sabe alguien qué causa ésto?

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

Es un Genesis Framework sin modificar recién instalado.

— James Mitch
fuente

Respuestas:

Has encontrado un error en Génesis.

Su pila de Xdebug rastrea al culpable como la genesis_save_custom_fields()función que llama current_user_can()con una capacidad singular (edit_post y edit_page) que también requiere un argumento adicional, en este caso el ID de la publicación que falta.

current_user_can()llama a has_cap()qué llamadas map_meta_cap()que hace una declaración de cambio en el nombre de la capacidad. Ver línea 1067 de Capacidades.php . Los 2 avisos de desplazamiento indefinidos son de $ args [0], que no es una matriz porque falta el ID de publicación de la llamada current_user_can en Genesis.

La Cannot modify header information - headers already sentadvertencia es de Xdebug imprimiendo los avisos de PHP. De hecho, si no estuviera usando Xdebug, ni siquiera vería los avisos de PHP a menos que revisara sus registros porque el error está en una función adjunta a save_post y la página se actualiza, lo que evita que se muestren advertencias / avisos / errores en la página incluso con WP_DEBUG establecido en verdadero.

Reparar:

En la línea 234 de 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;

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

También para tener en cuenta, no es necesario verificar post_type porque los edit_pagey edit_postmayúsculas son intercambiables.

— Chris_O
fuente

Ah, eso explica por qué no obtuve ningún error en mi computadora portátil al probar localhost apache2 (sin xdebug) ni en un webhost lo probé. Gracias por profundizar tanto en esto, estaba un poco abrumado por todas estas cosas "complicadas";). Encontré varios errores en génesis ahora, se supone que deben probar esto con xdebug y WP_DEBUG, por supuesto. Por ejemplo, encontró un esc_html faltante en génesis. Pagaron al desarrollador principal de wp Mark Jaquirth para que lo auditara en seguridad varias veces, lo anunciaron con supuestas citas de él diciendo cuán seguro es, ahora cuestiono la calidad general del Genesis Framework

— James Mitch

Esto fue arreglado en el tronco en 1.17 por Mark Jaquith en su auditoría. He enviado un ticket para una posible versión 1.9.2.

Personalmente, creo que esto es un problema de WordPress ya que map_meta_cap () no verifica ni desinfecta $ args [0]. Como resultado, he enviado un ticket al núcleo de WordPress.

— Travis Smith
fuente

"tronco en 1.17" ¿qué? génesis 1.1.7? ¿Por qué es entonces en 1.9.1? E incluso si se trata de un problema de WordPress, lanzan un marco estable donde ni siquiera puedes publicar sin un error molesto que detiene por completo la carga de la página. WTF? @Chris_O explicó anteriormente que se puede arreglar fácilmente simple al darle el argumento. Tomé $ post_id en lugar de §post-> ID porque también es un argumento si la génesis funciona, no sé si esto es sabio, también tengo curiosidad sobre si es correcto y seguro reducir esto a solo if ( ! current_user_can( 'edit_post', $post_id ) )y omitir los demás .

— James Mitch

Me refiero a liberarlo como estable sin siquiera probar si hacer una acción simple como una publicación (con WP_DEBUG y xdebug) debería ser un procedimiento normal para los desarrolladores o no. No soy un experto en esto, pero diría que si no lo están haciendo mal. Sin mencionar que son el autoproclamado "estándar de la industria de los marcos de WordPress". No debería no ser de 2 tipos en desbordamiento de pila (yo y @Chris_O) la detección y la fijación de su código de mierda!

— James Mitch

Y lo siento, pero por favor no culpes a esto en el núcleo de WordPress. No lo es , incluso si se trata de un error de núcleo subyacente. Y no diré dónde encontré el agujero de seguridad de un esc_html perdido por 2 razones. 1. ¡No quiero arriesgar a los propietarios pobres del sitio! 2. ¡es su trabajo encontrarlo por más de $ 80! De hecho, ¡debería arreglarse hace años! Me alegro de haberlo descargado de github en lugar de pagar por esto.

— James Mitch

James, guau. Eso es mucha ira. Primero, Genesis se prueba con WP_DEBUG como procedimiento normal. Cuando noté que estaba comprometido con el núcleo como una solución, se comprometió el 17 de enero. Además, no es una falla de seguridad en Genesis o en WordPress como lo señaló Jaquith.

— Travis Smith

Entonces, dígame si lo comprobaron por qué no se detectó este error increíblemente fácil de detectar que, como dije, detiene la ejecución, no lo redirige al editor de publicaciones, lo que le permite mirar el maldito mensaje xdebug cada vez que publica cosas de publicación / página. Permítanme adivinar que lo "probaron", pero su procedimiento de prueba no implicó hacer o editar una publicación ROFLMAO. Di lo que quieras, defiéndelos como quieras (debido a que Couse es extremadamente parcial) ¡es un hecho que fallaron las pruebas de popper!

— James Mitch