Folosim câmpuri personalizate avansate în compania noastră și uneori trebuie să folosim shortcode în câmpurile noastre personalizate. În codul php vom folosi apoi do_shortcode funcții pentru aceste câmpuri. Nu există niciun motiv să nu îl folosim pentru majoritatea câmpurilor, deoarece ar putea fi vrem să adăugăm coduri scurte într-un câmp mai târziu.
Noi ” folosim și PHP CodeSniffer cu regula WordPress Coding Standards. Ori de câte ori folosim echo do_shortcode avertismentul de evadare dispare. Deci, este sigur să folosim doar do_shortcode sau trebuie să folosim de ex. wp_kses_post în plus?
Există vreo bună practică în acest sens?
Vă mulțumim pentru orice sfat
Comentarii
- do_shortcode nu este pentru a scăpa.
- Hm ok, dar de ce codesniffer nu afișează niciun avertisment?
- Poate că nu afișați un avertisment deoarece funcția de redare a codului scurt ar trebui să fie responsabilă pentru igienizarea ieșirii sale. Dar orice șir poate fi trecut către funcție și dacă nu conține coduri scurte înregistrate, atunci <
sunt destul de sigur că șirul nu va fi modificat deloc. Cu siguranță nu este o metodă generică de igienizare. Snifferul de cod poate face atât de mult. Citiți aici despre cum să igienizați corect datele. Există multe funcții, cele pe care le folosesc mult sunt esc_attr, sanitize_text_field, esc_url. codex.wordpress.org/…
Răspuns
Standardele de codare WordPress sniffs tratează do_shortcode() ca o „funcție autoescaped”. Acest lucru pare să fi fost discutat în 2015 în aceste numere GitHub:
https://github.com/WordPress/WordPress-Coding-Standards/issues/167 https://github.com/WordPress/WordPress-Coding-Standards/issues/428
Explicația utilizată când a fost adăugată la listă a fost:
Am discutat acest lucru cu asistență VIP (# 44195). David, după ce a discutat cu un alt membru al echipei, a spus că „nu este necesar, deoarece facem scăparea de unde este emis codul HTML (în codul scurt„ s code ”).
Dar nu sunt sigur că sunt de acord cu raționamentul. Dacă l-ați folosit astfel:
<?php echo do_shortcode( "[liveperson]" ); ?> În cazul în care codul scurt este codat greu, are sens, deoarece singurul lucru care trebuie scăpat este ieșirea shortcode-ului, care ar trebui să fie scăpat de callback-ul shortcode.
Cu toate acestea, în situația dvs. , utilizați do_shortcode() pentru a permite executarea de coduri scurte în textul furnizat de utilizator, dintr-un câmp personalizat. Acel text nu trebuie scăpat, dar do_shortcode() nu face nicio scăpare efectivă.
Deci, modalitatea sigură de a gestiona câmpuri ca aceasta ar fi să treceți textul prin wp_kses() sau wp_kses_post(), pentru a elimina etichetele interzise și apoi introduceți-le prin do_shortcode(), astfel încât codurile scurte să poată fi ex ecuat fără a fi scăpat din nou.
$text = get_field( "field_name" ); echo do_shortcode( wp_kses_post( $text ) ); Nu va face nicio diferență în ceea ce raportează / nu raportează snifferul de cod, dar cel puțin utilizatorul a furnizat text este igienizat.
O limitare este că nu va funcționa dacă utilizați esc_html(), deoarece acest lucru va interfera cu atributele shortcode. Această igienizare, de asemenea, nu va împiedica utilizatorii să introducă etichete dezechilibrate care ar putea afecta aspectul, ceea ce este un lucru care ajută în mod normal să scapi. Pentru a rezolva această problemă, puteți adăuga force_balance_tags():
$text = get_field( "field_name" ); echo do_shortcode( force_balance_tags( wp_kses_post( $text ) ) );