Nous utilisons des champs personnalisés avancés dans notre entreprise et nous devons parfois utiliser un shortcode dans nos champs personnalisés. Dans le code php, nous utilisons alors le do_shortcode fonctions pour ces champs. Il ny a aucune raison de ne pas lutiliser pour la plupart des champs, car il se pourrait que nous souhaitons ajouter des codes courts à un champ plus tard.
Nous » re également en utilisant PHP CodeSniffer avec la règle WordPress Coding Standards. Chaque fois que nous utilisons echo do_shortcode, lavertissement déchappement disparaît. Est-il donc prudent dutiliser simplement do_shortcode ou devons-nous utiliser par exemple wp_kses_post en plus?
Existe-t-il des bonnes pratiques à ce sujet?
Merci pour tout conseil
Commentaires
- do_shortcode nest pas pour échapper.
- Hm daccord, mais pourquoi codesniffer naffiche-t-il alors aucun avertissement?
- Peut-être quil ne le fait pas affiche un avertissement car la fonction de rendu du code court devrait être responsable de la désinfection de sa sortie. Mais nimporte quelle chaîne peut être passée à la fonction et si elle ne contient pas de shortcodes enregistrés, alors je ' m assez sûr que la chaîne ne sera pas modifiée du tout. Ce nest certainement pas une méthode dassainissement générique. Le sniffer de code ne peut pas faire grand-chose. Lisez ici comment nettoyer correctement les données. Il existe de nombreuses fonctions, celles que jutilise beaucoup sont esc_attr, sanitize_text_field, esc_url. codex.wordpress.org/…
Réponse
Les reniflards des normes de codage WordPress traitent do_shortcode() comme une « fonction autoescaped ». Cela semble avoir été discuté en 2015 dans ces problèmes GitHub:
https://github.com/WordPress/WordPress-Coding-Standards/issues/167 https://github.com/WordPress/WordPress-Coding-Standards/issues/428
Lexplication utilisée lors de son ajout à la liste était:
Jen ai discuté avec le support VIP (# 44195). David, après sêtre entretenu avec un autre membre de léquipe, a déclaré que ce nétait pas nécessaire, car nous faisons léchappement là où le code HTML est émis (dans le code du shortcode).
Mais je ne suis pas sûr d’être d’accord avec le raisonnement. Si vous l’avez utilisé comme ceci:
<?php echo do_shortcode( "[liveperson]" ); ?> Où le code court est codé en dur, cela a du sens, car la seule chose à échapper est la sortie du shortcode, qui devrait être échappée par le rappel de shortcode.
Cependant, dans votre situation, vous utilisez do_shortcode() pour permettre lexécution de codes courts dans le texte fourni par lutilisateur, à partir dun champ personnalisé. Ce texte doit être échappé, mais do_shortcode() ne fait aucun échappement réel.
Le moyen le plus sûr de gérer des champs comme celui-ci serait de placer le texte dans wp_kses() ou wp_kses_post(), pour supprimer les balises non autorisées, et puis le faire passer par do_shortcode() afin que les shortcodes puissent être ex mis à jour sans être échappé à nouveau.
$text = get_field( "field_name" ); echo do_shortcode( wp_kses_post( $text ) ); Cela ne fera aucune différence par rapport à ce que le renifleur de code fait / ne rapporte pas, mais au moins le texte fourni par lutilisateur est nettoyé.
Une limitation est que cela ne fonctionnera pas si vous utilisez esc_html(), car cela interférera avec les attributs de shortcode. Cette désinfection nempêchera pas non plus les utilisateurs de saisir des balises déséquilibrées qui pourraient affecter la mise en page, ce qui est une chose avec laquelle échapper normalement aide. Pour résoudre ce problème, vous pouvez ajouter force_balance_tags():
$text = get_field( "field_name" ); echo do_shortcode( force_balance_tags( wp_kses_post( $text ) ) );