Вольный и дополненный перевод https://drupal.stackexchange.com/questions/2509/what-are-the-downsides-o...
На форуме некоторые товарищи, иногда рекомендуют для решения задачи использовать встроенный в ядро PHP фильтр, или Views PHP. Никогда так не делайте! И вот почему:
- Данный код пишется в базу, поэтому его нельзя будет отследить через систему контроля версий, например git. (если вы не используете систему контроля версий в разработке - это тоже плохо).
- Поля с php-фильтром не кэшируются.
- Код в php-фильтре выполняется через eval(). Код через eval работает медленнее, не кэшируется opcache-м, а на некоторых хостингах eval может быть отключен из соображений безопасности.
- Не информативные сообщения об ошибках. Что-то типа error in eval() on line 4. Где этот кусок кода, что с ним делать?
- Проблемы с обновлением модулей. Обновление модуля - и у вас куча ошибок, которые сложно найти и исправить.
- Сложно писать и поддерживать такой код. В обычном textfield - нет форматирования как в IDE, да и шрифт не моноширинный. Копировать туда-обратно тоже заколебаться можно.
- Человеческий фактор. Всегда существует возможность ошибки в конфигурации, которая позволит не доверенным пользователям заюзать php-фильтр. ОЙ!
- Безопасность в целом. Любой сайт могут взломать, но присутствие на сайте php-фильтра может сделать последствия взлома гораздо тяжелее. XSS, SQL-инъекция - и вот вас уже shell прямо в базе.
- Сложности деплоя. Нельзя просто обновить файлы на сервере. Надо лезть в админку, и копипастить код в нужные места. Хотя обычно в PHP-фильтр пишут прямо на продакте. Не стоит работать на продакте.
- Повышается цена ошибки. Одна небольшая опечатка в сквозном блоке - и всё пропало, шеф.
- Многие разработчики высказываются против использования php-фильтра. Например: пользователь Semantics в своей записи в блоге высказывался против PHP-фильтра ещё в 2013-м (!) году.
Хорошо, PHP-фильтр использовать не стоит. А что же тогда делать?
- Через template_preprocess хуки.
- Можно создать свой токен и вставлять его с помощью token_filter
- Можно создавать вычисляемые поля с помощью computed_field. Этот модуль даже сам подскажет вам, какое название функции использовать.
- Если используется Display Suite - можно написать своё Display Suite поле
- Ещё варианты, тысячи их! В зависимости от задачи.
Комментарии
Вставлять этот кусок html в поле/контент и выводить его.
Сделать модуль для импорта этих данных.
Ну и теории у вас. На практике ни один мало-мальски вменяемый программист не предложил бы ни одно, ни второе.
Тут есть два наиболее подходящих варианта: либо делать пакетное обновление нод через батч или очередь (это если ноды обновляются все вместе, но не очень часто), либо в hook_node_view притягивать нужные данные - это если ноды обновляются часто и без какой-либо закономерности.
Так и делается. Только 22 тыщи "кусков html" тупо сливаются в файловую систему, а затем тупо подсасываются связанными с ними нодами через include. Связка устанавливается раз и навсегда между синонимом ноды и UID куска. В чем опасность, если нет админского доступа к полю ни у кого, кроме админа?
Импортирую импортером для другой задачи, когда надо "клонировать" ноды для различных приватных групп. Тогда впереди синонима дописывается nid группы, при этом куски html те же. Один кусок при этом подсасывается не в одну, а в несколько (десятков и т.п.) нод. Reusing, однако.
Не будем о вменяемости программистов, поскольку вместо них теперь все больше кодировщики
Ноды создаются и обновляются через импортер по мере необходимости.
hook_node_view и include - в чем разница в плане безопасности?
Тут не include надо делать, потому, что никакой код не исполняется. А, например file_get_content() + echo тогда уж.
Ещё лучше с https://api.drupal.org/api/drupal/includes%21common.inc/function/filter_... хотя бы. Если делать примитивно. Но это всё же не правильный подход изначально. Правильнее было бы данные эти хранить так, как остальные данные в базе в виде поля.
А то, если будет какая-то уязвимость, то легко очень вставить код в файл, он проинклюдится и выполнится.
Т.е. это не прямая дыра в безопасности, это просто очень удобный вектор эксплуатации возможности записи в этот html.
По переиспользованию, лучше бы ноды переиспользовать целиком тогда уж.
Тут дело не в безопасности, а в самоуважении и уважении тех, кому в последствии может быть придётся это дорабатывать.
Уважаемый, если нечего ответить по существу, то и не надо.
Вы не понимаете просто, что это очень по существу замечание.
Есть общие принципы, по которым работает Drupal, или какая-то другая CMS. Они придуманы не случайно, они проработаны, они протестированы, они проверяются, если надо они исправляются.
Построение всяких таких костылей и создание велосипедов, может влиять как на безопасность, так и на поддерживаемость, и это весьма важно.
Чуть не прослезился... Вы бы еще Йодана помянули. Слыхали хоть о таком?
На будущее: если "костыль" прекрасно работает более 10 лет и никто ни разу не споткнулся, то плевать на любые общие принципы любых CMS с высокой колокольни.
На этом "война окончена, всем спасибо!"
а как узнать на какой странице включен php фильтр? надо базу данных смотреть? у меня много страниц. я не помню где.
Да, через базу быстрее всего