Disinfetta il contenuto da wp_editor

Ho creato un tipo di post personalizzato in cui possiamo trovare una textarea / tinymce standard generata da wp_editor()e sto affrontando un problema per la parte di salvataggio.

Se salvo il contenuto con il seguente codice:

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

Tutto funziona bene ma non c'è sicurezza (sanificazione, validazione ecc ...)

Se salvo il contenuto con il seguente codice:

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

Risolvo il problema di sicurezza ma perdo tutto lo stile, i media ecc. Nel contenuto.

Quale potrebbe essere un buon modo per salvare il contenuto con tutto lo stile applicato, i media inseriti ma inclusa una sanificazione?

Ho letto un po ' wp_kses()ma non so come potrei applicare un buon filtro. (Consentendo tag comuni, quale dovrei bloccare? Ecc.)

In breve: dipende dal contesto, dai dati all'interno dell'editor.

wp_kses()è davvero utile e puoi definire il tuo HTML consentito personalizzato. In alternativa è possibile utilizzare le funzioni predefinite, come wp_kses_posto wp_kses_data. Queste funzioni sono utili per garantire che l'HTML ricevuto dall'utente contenga solo elementi in white list. Vedi https://codex.wordpress.org/Data_Validation#HTML.2FXML_Fragments

WordPress definisce molte più funzioni per disinfettare l'input, vedi https://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data e https://codex.wordpress.org/Data_Validation Queste pagine sono davvero utili.

Tuttavia, nel tuo contesto, la wp_kses_postfunzione dovrebbe essere la scelta giusta.

Provare

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

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

1. htmlentities() convertirà tutti i caratteri che hanno equivalenti di entità carattere HTML nei loro equivalenti.
2. sanitize_text_field()controllerà quindi la presenza di caratteri UTF-8 non validi e li eliminerà. Questo può ora essere archiviato nel database.
3. html_entity_decode() convertirà le entità HTML nei loro equivalenti tag HTML

Potresti fare qualcosa del genere:

/ **
 * La maggior parte dell'HTML "post" sono esclusi tranne <textarea> stesso.
 * @link https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html
 * /
$ allowed_html = wp_kses_allowed_html ('post');

// Rimuovi il tag '<textarea>'
unset ($ allowed_html ['textarea']);

/ **
 * wp_kses_allowed_html restituisce valori errati per wp_kses,
 * è necessario modificare "true" -> "array ()"
 * /
array_walk_recursive (
    $ Allowed_html,
    funzione (& $ valore) {
        if (is_bool ($ value)) {
            $ value = array ();
        }
    }
);
// Esegui la sanificazione.
$ value = wp_kses ($ value, $ allowed_html);

@fuxia: come OP ha scritto:
"Ho letto un po 'di wp_kses () ma non so come poter applicare un buon filtro. (Consentendo tag comuni, quale dovrei bloccare? ecc.)"

wp_kses fa quanto segue:
"Questa funzione si assicura che solo i nomi di elementi HTML consentiti, i nomi di attributo e i valori di attributo più solo entità HTML sane si verifichino in $ string. Prima di chiamare questa funzione è necessario rimuovere eventuali barre dalle virgolette magiche di PHP. "
https://codex.wordpress.org/Function_Reference/wp_kses

Il mio codice utilizza wp_ksescon "Consenti tag comuni". Quali sono i tag comuni? L'elenco disponibile da leggere nel link indicato. È un lungo elenco, quindi non l'ho incollato qui.
https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html

Penso che textarea stessa non dovrebbe essere consentita in textarea.

@bueltge
wp_kses_post fa la stessa cosa, tranne consentire il tag '<textarea>', che - penso - non dovrebbe essere.
https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/kses.php#L1575

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

wp_slash Ulteriori informazioni.

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