J'ai construit un type de publication personnalisé dans lequel nous pouvons trouver une textarea/tinymce standard générée par wp_editor()
et je suis confronté à un problème pour la sauvegarde.
Si je sauvegarde le contenu avec le code suivant:
update_post_meta( $post_id, $prefix.'content', $_POST['content'] );
Tout fonctionne bien mais il n'y a pas de sécurité (désinfection, validation etc ...)
Si je sauvegarde le contenu avec le code suivant:
update_post_meta( $post_id, $prefix.'content', sanitize_text_field($_POST['content']) );
Je résous le problème de sécurité mais je perds tout le style, les médias, etc. du contenu.
Quel pourrait être un bon moyen de sauvegarder le contenu avec tout le style appliqué, le média inséré mais y compris une désinfection?
J'ai lu un peu sur wp_kses()
mais je ne sais pas comment appliquer un bon filtre. (Permettant les tags communs, lequel dois-je bloquer? Etc ..)
Essayer
//save this in the database
$content=sanitize_text_field( htmlentities($_POST['content']) );
//to display, use
html_entity_decode($content);
htmlentities()
convertira tous les caractères ayant des équivalents d'entité de caractères HTML en leurs équivalents.sanitize_text_field()
vérifiera ensuite si les caractères UTF-8 sont invalides et les supprimera. Cela peut maintenant être stocké dans la base de données.html_entity_decode()
convertira les entités HTML en leurs équivalents de balises HTMLEn bref: cela dépend du contexte, des données dans votre éditeur.
wp_kses()
est vraiment utile et vous pouvez définir votre code HTML autorisé personnalisé. Vous pouvez également utiliser les fonctions par défaut, telles que wp_kses_post
ou wp_kses_data
. Ces fonctions permettent de s’assurer que le HTML reçu de l’utilisateur ne contient que des éléments de la liste blanche. Voir https://codex.wordpress.org/Data_Validation#HTML.2FXML_Fragments
WordPress définit beaucoup plus de fonctions pour nettoyer l'entrée, voir https://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data et https://codex.wordpress.org/Data_Validation Ces pages sont vraiment utiles.
Cependant, dans votre contexte, le wp_kses_post
devrait-il fonctionner correctement.
Vous pouvez faire quelque chose comme ça:
/** * La plupart des 'post' HTML sont acceptés sauf <textarea>. * @Link https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html . */ $ allowed_html = wp_kses_allowed_html ('post'); // Supprimer la balise '<textarea>' non définie ($ allowed_html ['textarea'] ); /** * wp_kses_allowed_html renvoient les mauvaises valeurs pour wp_kses, * doit changer "true" -> "array ()" */ array_walk_recursive ( $ allowed_html, function (& $ value) { if (is_bool ($ value)) {{.____. ] $ valeur = tableau (); } } ); // Exécuter la désinfection. $ value = wp_kses ($ value, $ allowed_html);
@fuxia: comme l'OP a écrit:
"J'ai lu un peu sur wp_kses () mais je ne sais pas comment appliquer un bon filtre. (Autoriser les balises communes, lesquelles dois-je bloquer? Etc ..)"
wp_kses fait ce qui suit:
"Cette fonction vérifie que seuls les noms d'élément HTML, les noms d'attribut et les valeurs d'attribut autorisés, ainsi que les entités HTML saines apparaîtront dans $ string. cette fonction. "
https://codex.wordpress.org/Function_Reference/wp_kses
Mon code utilise wp_kses
avec "Autoriser les tags communs". Quels sont les tags communs? La liste disponible à lire dans le lien donné. La liste est longue, je ne l'ai donc pas collée ici.
https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html
Je pense que textarea lui-même ne devrait pas être autorisé dans textarea.
@bueltge
wp_kses_post fait la même chose, à l'exception de permettre la balise '<textarea>', qui - je pense - ne devrait pas l'être.
https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/kses.php#L1575
function wp_kses_post ($ data) { renvoyer wp_kses ($ data, 'post'); }
wp_slash Plus d'informations.
update_post_meta( $post_id, $prefix.'content',wp_slash($_POST['content']) );