Assainir le contenu de wp_editor

J'ai construit un type de message personnalisé où nous pouvons trouver une zone de texte / tinymce standard générée par wp_editor()et je suis confronté à un problème pour la partie d'enregistrement.

Si j'enregistre 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 j'enregistre 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. dans le contenu.

Quel pourrait être un bon moyen de sauvegarder le contenu avec tout le style appliqué, le support inséré mais y compris une désinfection?

J'ai lu un peu wp_kses()mais je ne sais pas comment appliquer un bon filtre. (Autoriser les balises courantes, laquelle dois-je bloquer? Etc.)

En bref: c'est en fonction de votre contexte, des données à l'intérieur de votre éditeur.

wp_kses()est vraiment utile et vous pouvez définir votre code HTML autorisé personnalisé. Alternativement, vous pouvez utiliser les fonctions par défaut, comme wp_kses_postou wp_kses_data. Ces fonctions sont utiles pour garantir que le code HTML reçu de l'utilisateur ne contient que des éléments en liste blanche. Voir https://codex.wordpress.org/Data_Validation#HTML.2FXML_Fragments

WordPress définit beaucoup plus de fonctions pour assainir 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, la wp_kses_postfonction devrait être le bon choix.

Essayer

//save this in the database
$content=sanitize_text_field( htmlentities($_POST['content']) );

//to display, use
html_entity_decode($content);

1. htmlentities() convertira tous les caractères qui ont des équivalents d'entité de caractère HTML en leurs équivalents.
2. sanitize_text_field()vérifiera alors les caractères UTF-8 invalides et les supprimera. Cela peut maintenant être stocké dans la base de données.
3. html_entity_decode() convertira les entités HTML en leurs équivalents de balises HTML

Vous pouvez faire quelque chose comme ça:

/ **
 * La plupart du code HTML «post» sont acceptés sauf <textarea> lui-même.
 * @link https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html
 * /
$ allowed_html = wp_kses_allowed_html ('post');

// Supprimer la balise '<textarea>'
unset ($ allowed_html ['textarea']);

/ **
 * wp_kses_allowed_html renvoie les mauvaises valeurs pour wp_kses,
 * besoin de changer "true" -> "array ()"
 * /
array_walk_recursive (
    $ allowed_html,
    fonction (& $ valeur) {
        if (is_bool ($ value)) {
            $ value = array ();
        }
    }
);
// Exécuter la désinfection.
$ value = wp_kses ($ value, $ allowed_html);

@fuxia: comme OP l'a écrit:
"J'ai lu un peu sur wp_kses () mais je ne sais pas comment appliquer un bon filtre. (Autoriser les balises courantes, laquelle dois-je bloquer? etc ..)"

wp_kses effectue les opérations suivantes:
"Cette fonction garantit 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 sensées, apparaîtront dans $ string. Vous devez supprimer toutes les barres obliques des citations magiques de PHP avant d'appeler cette fonction. "
https://codex.wordpress.org/Function_Reference/wp_kses

Mon code utilise wp_ksesavec "Autoriser les balises communes". Quelles sont les balises courantes? La liste disponible à lire dans le lien donné. C'est une longue liste, donc je ne l'ai 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, sauf autoriser la balise '<textarea>', ce qui - je pense - ne devrait pas l'être.
https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/kses.php#L1575

fonction wp_kses_post ($ data) {
    return wp_kses ($ data, 'post');
}

wp_slash Plus d'informations.

update_post_meta( $post_id, $prefix.'content',wp_slash($_POST['content']) );