Вывести во view.php html

[surrealistic_pillow]

Во view.php вывожу атрибут так

Код: Выделить всё

[
'label' => 'Выбранные модули',
'attribute' => 'user_id',
'value' => html_entity_decode($model->moduleListToString())
],

И на странице просмотра выводится вот что:

Код: Выделить всё

<ul><li>[65] - Модуль 1</li><li>[66] - Модуль 2</li></ul>

Как мне вывести именно сгенерированный мной html, не текстом

[Alexum]

Код: Выделить всё

'format' => 'raw',

[surrealistic_pillow]

Alexum, спасибо!

[Alexum]

И ещё такой момент. Это конечно дело каждого, но лучше следить за вводом содержимого, которое потом может так потребоваться вывести. А то вдруг вместо названия модуля вам какой-нибудь нехороший человек запишет javascript код, который выполнится при открытии странички (Межсайтовый скриптинг, XSS-атака).

Чтобы этого избежать, можно в rules модели добавить правило:

Код: Выделить всё

[['module_name'],'filter','filter'=>'\yii\helpers\HtmlPurifier::process']

или непосредственно в месте использования:

Код: Выделить всё

<?= \yii\helpers\HtmlPurifier::process($module_name) ?>

[ElisDN]

И ещё такой момент. Это конечно дело каждого, но лучше следить за вводом содержимого, которое потом может так потребоваться вывести.

Следить нужно не за вводом, а за выводом через Html::encode(...).

[Alexum]

И ещё такой момент. Это конечно дело каждого, но лучше следить за вводом содержимого, которое потом может так потребоваться вывести.

Следить нужно не за вводом, а за выводом через Html::encode(...).

Следить за выводом конечно нужно, но никто не запрещает заодно и за вводом последить (например, если нет желания хранить в БД потенциально опасные данные). В общем по желанию.

[samdark]

Нельзя заранее сказать, опасные данные или нет. Наличие опасности зависит от того, как мы их выводим.

[rugabarbo]

Следить нужно не за вводом, а за выводом через Html::encode(...).

Это не всегда справедливо. Если выводить данные планируется через Purifier (например, использовать в GridView 'format' => 'html'), то чистить лучше на входе, иначе будут тормоза на выходе. Так что всё зависит от тормознутости "очищалки".

[rak]

хм, ну вот допустим такая задача:
- пользователь может писать посты с ограниченным кол-вом html тегов(допустим, b и i)
- администратор может писать посты(и редактировать посты пользователя) с неограниченным кол-вом тегов

Не логичнее ли тут через сценарии прогонять текст через HtmlPurifier с 2мя разрешенными тегами при сохранении для пользователя и оставлять в нетронутом виде для админа?

[rugabarbo]

хм, ну вот допустим такая задача:
- пользователь может писать посты с ограниченным кол-вом html тегов(допустим, b и i)
- администратор может писать посты(и редактировать посты пользователя) с неограниченным кол-вом тегов

Не логичнее ли тут через сценарии прогонять текст через HtmlPurifier с 2мя разрешенными тегами при сохранении для пользователя и оставлять в нетронутом виде для админа?

Это и есть тот кейс, о котором я писал выше. Для админа эти данные придётся выводить с применением 'format' => 'html' (прогонять через Purifier). Соответственно, при табличном выводе Purifier сработает десятки раз подряд, страничка будет прогружаться медленно. А т.к. в админке нужны самые свежие и актуальные состояния вещей, то кэширование там неприменимо. Вот тут-то и помогает фильтрация на входе: как вы и сказали - сохраняем в одну колонку raw_html, а в другую - purified_html. На выходе юзаем purified_html в формате 'raw'.

[ElisDN]

Это не всегда справедливо. Если выводить данные планируется через Purifier, то чистить лучше на входе, иначе будут тормоза на выходе. Так что всё зависит от тормознутости "очищалки".

В случае текста для Markdown или Purifier проблема тормознутости решается либо внешним кешем, либо кешированием в отдельное поле filtered_text в БД. Иначе это боль потерянных кусков текста при редактировании. Но к простому стрингу module_name с Html::encode это не относится.

[rak]

Иначе это боль потерянных кусков текста при редактировании.

а можно подробнее?

[rugabarbo]

Это не всегда справедливо. Если выводить данные планируется через Purifier, то чистить лучше на входе, иначе будут тормоза на выходе. Так что всё зависит от тормознутости "очищалки".

В случае текста для Markdown или Purifier проблема тормознутости решается либо внешним кешем, либо кешированием в отдельное поле filtered_text в БД. Иначе это боль потерянных кусков текста при редактировании. Но к простому стрингу module_name с Html::encode это не относится.

Да, я это и имел в виду. Кэширование в отдельное поле БД удобнее, потому что очищенное и неочищенное лежит рядом, в одной таблице.

[ElisDN]

а можно подробнее?

Если бы при такой фильтрации человек захотел мне на сайте написать комментарий:

Код: Выделить всё

Правильно ли я оформил подвал:

<footer class="footer">
    <div class="container">
        <p class="pull-left">&copy; My Company <?= date('Y') ?></p>
        <p class="pull-right"><?= Yii::powered() ?></p>
    </div>
</footer>

Ответьте, плиз!

то мне бы в базу после Purifier в поле text прилетело:

Код: Выделить всё

<p>Правильно ли я оформил подвал:</p>

<p>&amp;copy; My Company &lt;?= date('Y') ?&gt;</p>
<p>&lt;?= Yii::powered() ?&gt</p>

<p>Ответьте, плиз!</p>

Всего-лишь комментатор забыл обернуть код в <pre>...</pre> и весь листинг "парсер съел". Обидно.

Поэтому лучше либо в базе хранить оригинальный text и отфильтрованный text_purified, либо настроить валидацию формы, чтобы она ещё при написании говорила "Обнаружены запрещённые теги и атибуты. Вы забыли обернуть код в <pre>?"