Desinfecte el contenido de wp_editor

Creé un tipo de publicación personalizada donde podemos encontrar un área de texto estándar / tinymce generado por wp_editor()y estoy enfrentando un problema para la parte de guardado.

Si guardo el contenido con el siguiente código:

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

Todo funciona bien pero no hay seguridad (desinfección, validación, etc.)

Si guardo el contenido con el siguiente código:

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

Resuelvo el problema de seguridad pero pierdo todo el estilo, los medios, etc. en el contenido.

¿Cuál podría ser una buena manera de guardar el contenido con todo el estilo aplicado, los medios insertados pero incluyendo una desinfección?

Leí un poco sobre wp_kses()pero no sé cómo podría aplicar un buen filtro. (Permitiendo etiquetas comunes, ¿cuál debería bloquear? Etc.)

En resumen: depende de su contexto, los datos dentro de su editor.

wp_kses()es realmente útil y puede definir su HTML permitido personalizado. Alternativa, puede utilizar las funciones predeterminadas, como wp_kses_posto wp_kses_data. Estas funciones son útiles para garantizar que el HTML recibido del usuario solo contenga elementos de la lista blanca. Ver https://codex.wordpress.org/Data_Validation#HTML.2FXML_Fragments

WordPress define muchas más funciones para desinfectar la entrada, consulte https://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data y https://codex.wordpress.org/Data_Validation. Estas páginas son realmente útiles.

Sin embargo, en su contexto, la wp_kses_postfunción debería ser la opción correcta.

Tratar

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

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

1. htmlentities() convertirá todos los caracteres que tengan equivalentes de entidad de caracteres HTML a sus equivalentes.
2. sanitize_text_field()luego buscará caracteres UTF-8 no válidos y los eliminará. Esto ahora se puede almacenar en la base de datos.
3. html_entity_decode() convertirá entidades HTML a sus equivalentes de etiquetas HTML

Podrías hacer algo como esto:

/ **
 * La mayoría de los HTML 'post' están exceptuados y aceptan <textarea> en sí.
 * @link https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html
 * /
$ allowed_html = wp_kses_allowed_html ('publicación');

// Eliminar la etiqueta '<textarea>'
unset ($ allowed_html ['textarea']);

/ **
 * wp_kses_allowed_html devuelve los valores incorrectos para wp_kses,
 * necesita cambiar "true" -> "array ()"
 * /
array_walk_recursive (
    $ allowed_html,
    función (& $ valor) {
        if (is_bool ($ value)) {
            $ valor = matriz ();
        }
    }
);
// Ejecuta la desinfección.
$ value = wp_kses ($ value, $ allowed_html);

@fuxia: como OP escribió:
"Leí un poco sobre wp_kses () pero no sé cómo podría aplicar un buen filtro. (Permitiendo etiquetas comunes, ¿cuál debería bloquear? etc.)"

wp_kses hace lo siguiente:
"Esta función se asegura de que solo los nombres de elementos HTML permitidos, los nombres de atributos y los valores de atributos, además de las entidades HTML correctas, aparezcan en $ string. Debe eliminar las barras de las comillas mágicas de PHP antes de llamar a esta función. "
https://codex.wordpress.org/Function_Reference/wp_kses

Mi código se usa wp_ksescon "Permitir etiquetas comunes". ¿Cuáles son las etiquetas comunes? La lista disponible para leer en el enlace dado. Es una lista larga, así que no la pegué aquí.
https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html

Creo que textarea en sí no debería permitirse en textarea.

@bueltge
wp_kses_post hace lo mismo, excepto permitir la etiqueta '<textarea>', que, creo, no debería ser así.
https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/kses.php#L1575

función wp_kses_post ($ datos) {
    return wp_kses ($ datos, 'publicación');
}

wp_slash Más información.

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