Пожалуйста забудьте о mysql_(real)_escape_string.
Для защиты от sql-inj в цивилизованном мире используют prepared statements(http://www.php.net/manual/ru/pdo.prepared-statements.php).
Для защиты от xss будет достаточно htmlentities и парсера bb-кодов.
Если всё устраивает - нет.Зачем?
Разве только если пользователи присмотрят что-то в новой версии и попросят этого.
Я не ТС, но отвечу:
Всё зависит от ваших потребностей.Конечно-же добавилось множество новых возможностей и были закрыты уязвимости.
Изменения вот:
http://dle-news.ru/release/1219-datalife-engine-v92-final-release.html
http://dle-news.ru/release/1342-datalife-engine-v93-final-release.html
http://dle-news.ru/release/1436-datalife-engine-v94-final-release.html
http://dle-news.ru/release/1464-datalife-engine-v95-final-release.html
http://dle-news.ru/release/1503-datalife-engine-v96-final-release.html
P.s: Без спеца в DLE такое обновление лучше не проводить.
Да.Можно использовать доп. поля, но без модификаций тут тоже не обойтись, т.к. движок не позволяет создавать произвольное кол-во оных.
Использование других вариантов даст брешь в безопасности, а конкретнее активную XSS.
Это будет выводить во всех новостях в категории "id"
А человеку, насколько я понял нужно вставить в отдельно взятую новость.
Это будет выводить код во всех новостях.
Добавить нужный код через phpMyAdmin прямиком в базу в строку нужной новости.
Данный код будет резаться парсером DLE, т.к. потенциально он является вредоносным и парсер воспринимает его как таковой.
А какой практический смысл несёт данный топик?
Кому нужно почитает доки, у меня уже ~ месяц распечатанные для изучения : )
Это тоже вариант, кстати не плохой : )