Очистить контент от wp_editor

Я создал собственный тип записи, в котором мы можем найти стандартную текстовую область / tinymce, сгенерированную с помощью, wp_editor()и я столкнулся с проблемой для сохраняющей части.

Если я сохраню содержимое с помощью следующего кода:

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

Все работает нормально, но нет безопасности (дезинфекция, проверка и т. Д.)

Если я сохраню содержимое с помощью следующего кода:

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

Я решаю проблему безопасности, но теряю весь стиль, медиа и т. Д. В контенте.

Что может быть хорошим способом сохранить контент со всеми примененными стилями, со вставленными носителями, но с санитарной обработкой?

Я читал немного о, wp_kses()но я не знаю, как я мог бы применить хороший фильтр. (Разрешение общих тегов, какой из них следует заблокировать? И т. Д.)

Вкратце: это зависит от вашего контекста, данных внутри вашего редактора.

wp_kses()действительно полезно, и вы можете определить свой собственный допустимый HTML. Альтернативно вы можете использовать функции по умолчанию, как wp_kses_postили wp_kses_data. Эти функции помогают гарантировать, что HTML, полученный от пользователя, содержит только элементы из белого списка. См. Https://codex.wordpress.org/Data_Validation#HTML.2FXML_Fragments

WordPress определяет гораздо больше функций для очистки ввода, см. Https://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data и https://codex.wordpress.org/Data_Validation. Эти страницы действительно полезны.

Однако в вашем контексте следует wp_kses_postправильно выбрать функцию.

Пытаться

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

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

1. htmlentities() преобразует все символы, которые имеют эквиваленты сущностей символов HTML, в их эквиваленты.
2. sanitize_text_field()Затем проверим наличие недействительных символов UTF-8 и удалим их. Теперь это можно сохранить в базе данных.
3. html_entity_decode() преобразует HTML-сущности в их эквиваленты в HTML-тегах

Вы можете сделать что-то вроде этого:

/ **
 * Большая часть HTML-кода «post» исключается и принимает <textarea>.
 * @link https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html
 * /
$ разрешено_html = wp_kses_allowed_html ('post');

// Удалить тег '<textarea>'
unset ($ разрешено_html ['textarea']);

/ **
 * wp_kses_allowed_html возвращает неправильные значения для wp_kses,
 * необходимо изменить "true" -> "array ()"
 * /
array_walk_recursive (
    $ Allowed_html,
    функция (& $ value) {
        if (is_bool ($ value)) {
            $ value = array ();
        }
    }
);
// Запускаем санацию.
$ value = wp_kses ($ value, $ enabled_html);

@fuxia: как пишет OP:
«Я немного читал о wp_kses (), но не знаю, как применить хороший фильтр. (Допускает общие теги, какой из них следует блокировать? и т. д.)»

wp_kses выполняет следующие действия:
«Эта функция гарантирует, что в $ string будут содержаться только разрешенные имена элементов HTML, имена атрибутов и значения атрибутов, а также только здравые сущности HTML. Вы должны удалить любые слэши из магических кавычек PHP перед вызовом этой функции. "
https://codex.wordpress.org/Function_Reference/wp_kses

Мой код использует wp_kses«Разрешить общие теги». Каковы общие теги? Список доступен для чтения по данной ссылке. Это длинный список, поэтому я не вставил его сюда.
https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html

Я думаю, что сама текстовая область не должна быть разрешена в текстовой области.

@bueltge
wp_kses_post делает то же самое, за исключением разрешения тега '<textarea>', которого, я думаю, быть не должно.
https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/kses.php#L1575

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

wp_slash Дополнительная информация.

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