Почему нефильтрованный html разрешен в настраиваемых полях для ролей автора/участника?
Я создаю тему WordPress, в которой есть пользовательский метабокс textarea для вставки кодов встраивания (soundcloud, bandcamp и т. Д.). Я чувствую, что должен добавить некоторую безопасность, чтобы пользователи, не являющиеся администраторами/редакторами, не могли сохранять потенциально опасные данные, но, похоже, WordPress в качестве стандарта разрешает html в пользовательских полях для этих пользователей с более низкими возможностями.
Есть ли причина, по которой html разрешен в стандартных настраиваемых полях, но не в основной области редактирования, для пользователей без возможность нефильтрованного_html?
1 answers
Пользовательские поля - это в значительной степени то, что написано в названии: пользовательские. Большинство тем не отображают их каким-либо реальным способом, и они предназначены для плагинов и тем, чтобы делать с ними то, что необходимо.
Внутренне мы говорим только о двух реальных вещах: Посты и постметы. Очевидно, что посты являются основной частью контента постов, и все это отображают. С другой стороны, информация postmeta в основном используется для различных внутренних целей. Он нигде не отображается на обычно это передняя часть сайта. Поле "Настраиваемые поля" на экране редактирования записи позволяет (очень) элементарному способу доступа к этим данным, но большинство людей на самом деле ни для чего его не используют.
Поскольку postmeta произвольна по своей природе, фильтровать ее по умолчанию не имеет никакого смысла. Поскольку он все равно нигде не отображается на сайте, его фильтрация не добавит никакой безопасности.
Если вы пишете плагин и добавляете для него мета-поле, вам нужно выполнить фильтрацию себя. Для этого вы можете легко использовать различные функции wp_kses.