Vệ sinh nội dung từ wp_editor

Tôi đã xây dựng một loại bài đăng tùy chỉnh nơi chúng tôi có thể tìm thấy một loại văn bản / tinymce tiêu chuẩn được tạo bởi wp_editor()và tôi đang đối mặt với một vấn đề cho phần lưu.

Nếu tôi lưu nội dung với đoạn mã sau:

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

Mọi thứ đều hoạt động tốt nhưng không có bảo mật (vệ sinh, xác nhận, v.v.)

Nếu tôi lưu nội dung với đoạn mã sau:

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

Tôi giải quyết vấn đề bảo mật nhưng tôi mất tất cả phong cách, phương tiện truyền thông, vv .. trong nội dung.

Điều gì có thể là một cách tốt để lưu nội dung với tất cả các kiểu được áp dụng, phương tiện được chèn nhưng bao gồm cả vệ sinh?

Tôi đã đọc một chút về wp_kses()nhưng tôi không biết làm thế nào tôi có thể áp dụng một bộ lọc tốt. (Cho phép các thẻ phổ biến, tôi nên chặn thẻ nào? V.v ..)

Nói tóm lại: nó phụ thuộc vào ngữ cảnh của bạn, dữ liệu bên trong trình soạn thảo của bạn.

wp_kses()thực sự hữu ích và bạn có thể xác định HTML được phép tùy chỉnh của mình. Thay thế bạn có thể sử dụng các chức năng mặc định, như wp_kses_posthoặc wp_kses_data. Các chức năng này rất hữu ích trong việc đảm bảo rằng HTML nhận được từ người dùng chỉ chứa các thành phần được liệt kê trắng. Xem https://codex.wordpress.org/Data_Validation#HTML.2FXML_Fragments

WordPress xác định nhiều chức năng hơn để vệ sinh đầu vào, xem https://codex.wordpress.org/Validating_Sanitizing_and_Escaping_User_Data và https://codex.wordpress.org/Data_Validation Trang này thực sự hữu ích.

Tuy nhiên trong bối cảnh của bạn nên wp_kses_postchức năng lựa chọn đúng.

Thử

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

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

1. htmlentities() sẽ chuyển đổi tất cả các ký tự có tương đương thực thể ký tự HTML thành tương đương.
2. sanitize_text_field()sau đó sẽ kiểm tra các ký tự UTF-8 không hợp lệ và loại bỏ chúng. Điều này bây giờ có thể được lưu trữ trong cơ sở dữ liệu.
3. html_entity_decode() sẽ chuyển đổi các thực thể HTML thành tương đương thẻ HTML của chúng

Bạn có thể làm điều gì đó như thế này:

/ **
 * Hầu hết các HTML 'bài đăng' đều bị loại trừ chấp nhận <textarea>.
 * @link https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html
 * /
$ allow_html = wp_kses_allowed_html ('bài');

// Xóa thẻ '<textarea>'
bỏ đặt ($ allow_html ['textarea']);

/ **
 * wp_kses_allowed_html trả về các giá trị sai cho wp_kses,
 * cần thay đổi "true" -> "mảng ()"
 * /
mảng_walk_recursive (
    $ allow_html,
    hàm (& $ value) {
        if (is_bool ($ value)) {
            $ value = mảng ();
        }
    }
);
// Chạy vệ sinh.
$ value = wp_kses ($ value, $ allow_html);

@fuxia: như OP đã viết:
"Tôi đã đọc một chút về wp_kses () nhưng tôi không biết làm thế nào tôi có thể áp dụng bộ lọc tốt. (Cho phép các thẻ phổ biến, tôi nên chặn cái nào? v.v.)"

wp_kses thực hiện như sau:
"Hàm này đảm bảo rằng chỉ các tên thành phần HTML, tên thuộc tính và giá trị thuộc tính được phép cộng với chỉ các thực thể HTML lành mạnh sẽ xảy ra trong chuỗi $. Bạn phải xóa bất kỳ dấu gạch chéo nào khỏi dấu ngoặc kép của PHP trước khi bạn gọi hàm này. "
https://codex.wordpress.org/Function_Reference/wp_kses

Mã của tôi sử dụng wp_ksesvới "Cho phép các thẻ chung". Các thẻ phổ biến là gì? Danh sách có sẵn để đọc trong liên kết nhất định. Đó là một danh sách dài, vì vậy tôi đã không dán nó ở đây.
https://codex.wordpress.org/Function_Reference/wp_kses_allowed_html

Tôi nghĩ rằng bản thân textarea không nên được cho phép trong textarea.

@bueltge
wp_kses_post cũng làm điều tương tự, ngoại trừ cho phép thẻ '<textarea>', mà - tôi nghĩ - không nên như vậy.
https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/kses.php#L1575

hàm wp_kses_post ($ data) {
    trả về wp_kses ($ data, 'post');
}

wp_slash Thêm thông tin.

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