Stiamo utilizzando campi personalizzati avanzati nella nostra azienda e a volte abbiamo bisogno di utilizzare lo shortcode nei nostri campi personalizzati. Nel codice php utilizziamo quindi il do_shortcode funzioni per questi campi. Non cè motivo di non utilizzarlo per la maggior parte dei campi, poiché potrebbe essere necessario aggiungere shortcode a un campo in un secondo momento.
Noi ” stai anche usando PHP CodeSniffer con la regola degli standard di codifica di WordPress. Ogni volta che usiamo echo do_shortcode lavviso di escape scompare. Quindi è sicuro utilizzare solo do_shortcode o è necessario utilizzare ad es. wp_kses_post inoltre?
Esistono best practice in merito?
Grazie per eventuali consigli
Commenti
- do_shortcode non è per lescape.
- Hm okay, ma perché codesniffer non mostra alcun avviso?
- Forse non lo fa mostra un avviso perché la funzione di rendering dello shortcode dovrebbe essere responsabile della disinfezione del suo output. Ma qualsiasi stringa può essere passata alla funzione e se non contiene shortcode registrati, allora sono abbastanza sicuro che la stringa non verrà modificata. '. Non è sicuramente un metodo igienico-sanitario generico. Lo sniffer di codice può fare solo così tanto. Leggi qui su come disinfettare i dati correttamente. Ci sono molte funzioni, quelle che uso spesso sono esc_attr, sanitize_text_field, esc_url. codex.wordpress.org/…
Risposta
Gli standard di codifica di WordPress trattano do_shortcode() come una “funzione autoescaped”. Questo sembra essere stato discusso nel 2015 in questi numeri di GitHub:
https://github.com/WordPress/WordPress-Coding-Standards/issues/167 https://github.com/WordPress/WordPress-Coding-Standards/issues/428
La spiegazione utilizzata quando è stato aggiunto allelenco era:
Ne ho discusso con lassistenza VIP (# 44195). David, dopo aver parlato con un altro membro del team, ha detto che non è necessario, poiché eseguiamo lescape nel punto in cui viene emesso lHTML (nel codice dello shortcode).
Ma non sono sicuro di essere daccordo con il ragionamento. Se lhai usato in questo modo:
<?php echo do_shortcode( "[liveperson]" ); ?> Dove lo shortcode è hard-coded, ha senso, perché lunica cosa da sfuggire è loutput dello shortcode, che dovrebbe essere sottoposto a escape dalla callback dello shortcode.
Tuttavia, nella tua situazione, stai usando do_shortcode() per consentire lesecuzione di codici brevi nel testo fornito dallutente, da un campo personalizzato. Il testo non deve essere sottoposto a escape, ma do_shortcode() non esegue alcun effettivo escape.
Quindi il modo sicuro per gestire campi come questo sarebbe inserire il testo attraverso wp_kses() o wp_kses_post(), per rimuovere i tag non consentiti e quindi inseriscilo in do_shortcode() in modo che gli shortcode possano essere ex eseguito senza che venga nuovamente eseguito lescape.
$text = get_field( "field_name" ); echo do_shortcode( wp_kses_post( $text ) ); Non farà alcuna differenza su ciò che lo sniffer di codice segnala / non segnala, ma almeno il testo fornito dallutente è disinfettato.
Una limitazione è che non funzionerà se si utilizza esc_html(), perché ciò interferirà con gli attributi dello shortcode. Questa sanificazione non impedisce inoltre agli utenti di inserire tag sbilanciati che potrebbero influire sul layout, che è una cosa che normalmente aiuta. Per risolvere il problema, aggiungere force_balance_tags():
$text = get_field( "field_name" ); echo do_shortcode( force_balance_tags( wp_kses_post( $text ) ) );