Offset indefinito: 0 in> […] /wp-includes/capabilities.php sulla linea 1067

Ehi, ricevo questi messaggi di errore sulla mia configurazione di localhost, ma solo con Genesis Framework abilitato; WordPress Twenty Eleven funziona benissimo. Questo succede quando voglio creare un nuovo post. Se aggiorno la pagina l'errore si ripeterà, ma il post stesso viene creato e tutto sembra andare bene.

Qualcuno sa che cosa provoca questo?

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

È un Genesis Framework appena installato e non modificato.

— James Mitch
fonte

Risposte:

Hai trovato un bug in Genesis.

Il tuo stack Xdebug traccia il colpevole come genesis_save_custom_fields()funzione che chiama current_user_can()con una capacità singolare (edit_post e edit_page) che richiede anche un argomento aggiuntivo, in questo caso l'ID post mancante.

current_user_can()chiama has_cap()che chiama map_meta_cap()che fa un'istruzione switch sul nome della capacità. Vedi la riga 1067 di skills.php . Le 2 notifiche di offset indefinite provengono da $ args [0] che non è un array perché l'id post manca nella chiamata current_user_can in Genesis.

Gli Cannot modify header information - headers already sentavvisi provengono da Xdebug che stampa gli avvisi di PHP. Infatti se non stavi usando Xdebug non vedresti nemmeno gli avvisi PHP a meno che tu non abbia controllato i tuoi registri perché l'errore è in una funzione allegata a save_post e la pagina viene aggiornata che impedisce che avvisi / avvisi / errori vengano visualizzati sulla pagina anche con WP_DEBUG impostato su true.

fix:

Nella riga 234 di lib / funzioni / options.php cambia:

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

Per:

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

Inoltre, non è necessario controllare post_type perché i tappi edit_pagee edit_postsono intercambiabili.

— Chris_O
fonte

Ah, questo spiega perché non ho riscontrato alcun errore sul mio laptop durante il test di localhost apache2 (senza xdebug) né su un webhost che ho provato. Grazie per scavare così a fondo in questo sono stato un po 'sopraffatto da tutte queste cose "complicate";). Ho trovato vari bug nella genesi ora, dovrebbero testarlo con xdebug e WP_DEBUG ovviamente. Ad esempio, ho trovato un esc_html mancante nella genesi. Hanno pagato lo sviluppatore core di wp Mark Jaquirth per verificarlo più volte, pubblicizzare con supposte citazioni su di lui dicendo quanto sia sicuro, ora metto in dubbio la qualità generale del Genesis Framework

— James Mitch

Ciò è stato risolto nel bagagliaio il 1.17 da Mark Jaquith nel suo audit. Ho inviato un ticket per una possibile versione 1.9.2.

Personalmente, ritengo che si tratti di un problema di WordPress poiché map_meta_cap () non controlla o sanifica $ args [0]. Quindi ho inviato un ticket al core di WordPress come risultato.

— Travis Smith
fonte

"trunk on 1.17" cosa? genesi 1.1.7? Perché è quindi in 1.9.1? E anche se si tratta di un problema di wordpress, rilasciano un framework come stabile in cui non puoi nemmeno pubblicare senza un fastidioso errore che arresta completamente il pageload. WTF? @Chris_O ha spiegato sopra che può essere facilmente risolto semplicemente dando l'argomento. Ho preso $ post_id invece di §post-> ID perché è anche un argomento se la genesi funziona, non so se questo è saggio, inoltre sono curioso di sapere se è giusto e sicuro ridurre questo a giusto if ( ! current_user_can( 'edit_post', $post_id ) )e saltare gli altri .

— James Mitch,

Voglio dire rilasciandolo come stabile senza nemmeno testare se fare una semplice azione come un post (con WP_DEBUG e xdebug) dovrebbe essere una normale procedura per gli sviluppatori o no? Non sono un esperto in questo, ma direi che se non lo fanno lo stanno facendo male. Per non parlare del fatto che sono gli autoproclamati "standard del settore dei framework wordpress". Ci dovrebbe non essere di 2 ragazzi su stack overflow (io e @Chris_O) la rilevazione e fissare il loro codice di merda!

— James Mitch,

E scusa ma per favore non dare la colpa a questo core di wordpress! Non lo è , anche se si tratta di un bug di base sottostante. E non dirò dove ho trovato la falla di sicurezza di un esc_html mancante per 2 motivi. 1. non voglio rischiare i proprietari di siti poveri! 2. è il loro lavoro trovarlo per $ 80+! In effetti dovrebbe essere riparato anni fa! Sono contento di averlo scaricato da Github invece di pagare per questo.

— James Mitch,

James, wow. È molta rabbia. Innanzitutto, Genesis viene testato con WP_DEBUG come normale procedura. Quando ho notato che era stato impegnato con core come soluzione, è stato commesso il 17 gennaio. Inoltre, non è un difetto di sicurezza in Genesis o WordPress, come notato da Jaquith.

— Travis Smith,

Quindi dimmi se l'hanno verificato perché non sono riusciti a rilevare questo errore incredibilmente facile da rilevare che, come ho detto, interrompe l'esecuzione, non ti reindirizza all'editor dei post lasciandoti fissare un messaggio xdebug spaventoso ogni volta che pubblichi cose / pagine? Fammi indovinare che l'hanno "testato", ma il loro test ha preceduto la realizzazione o la modifica di un post ROFLMAO! Dì quello che vuoi, difendili come vuoi (perché i couse sono estremamente distorti) è un dato di fatto che hanno fallito i test di popper!

— James Mitch,