Sander1

Ладно, я понял, что в этом вопросе у нас в корне разный подход к обработке пользовательских данных... Я придерживаюсь общепринятой практики, что данные необходимо хранить в чистом виде не изменяя их и не уничтожая. Если я написал заголовок Пример <script>alert('test')</script> & \" &copy; – то именно в таком виде он должен сохранится в БД без преобразований и замен. И именно это должен видеть пользователь на странице сайта. Задача программиста обеспечить лишь безопасность: 1. Сохранение этих данных в БД 2. Отображение данных на сайте (админка, пользователю,

С этим я согласен. И вот именно в это суть данной темы. Парсер DLE распознает в тексте заголовка html сущности и заменяет их на соответствующие символы: &quot; → " &amp; → & и т.д. Т.е. если я написал заголовок: Пример &amp; / & / <b> / &quot; / &#039; / &copy; То в таком и именно в таком виде заголовок должен хранится в БД. В DLE же он меняется и сохраняется у же порезанным и преобразованным В БД: Пример &amp; / &amp; / / \" / \' / © Что видит пользователь на странице: Пример & / & / / " / ' / © На сайте в исходном код

Суть не в том что там обсуждается. Вы задали вопрос – зачем нужна возможность отображения &amp; в заголовке, я привел пример страницы где как раз в заголовке используется &amp; как текст, а не как html сущность. Правильно ли заменять HTML сущности на соответствующий символ внутри текста – это отдельная тема и тут нет однозначно правильного мнения. К примеру на этом форуме если я пишу &lt; в тексте, то он и выведет &lt; и не заменит на < Повторю основную суть. В DLE невозможно создать, к примеру, такой заголовок: Почему в адресе необходимо использовать &am

2. Откройте страницу по ссылке. Скопируйте тот заголовок и вставьте его в DLE. Вот в этом проблема, что НЕВОЗМОЖНО получить на выходе такой же заголовок как там. Будет так: Why should I use & instead of &? Вместо правильного: Why should I use &amp; instead of &? Да даже на этом движке форума, я уверен, если в заголовке прописать &amp; то на странице он так же и будет показан, а не заменён на &.

1. В обычный заголовок пишу `Пример \ слеша`, в теле страницы вижу заголовок: <title>Пример \ слеша</title> Если же в метатег заголовка прописать `Пример \ слеша`, то в теле страницы будет: <title>Пример слеша</title> Получается в одном случае это опасно, в другом – нет? 2. Зачем... Например чтобы можно было сделать такой заголовок: https://stackoverflow.com/questions/35367945/why-should-i-use-amp-instead-of

1. В метатеге заголовка невозможно использовать обратный слеш: \ Его получится использовать, если экранировать его вручную прописав \\\\, но после повторного сохранения слеш всё равно пропадёт. Т.е. stripslashes есть, а addslashes нету. 2. Невозможно нормально использовать HTML сущности в основном и мета заголовке. К примеру мне нужно, чтобы был именно такой заголовок в таком же виде: Пример &quot;замены" &copy; на © После сохранения новости в БД записывается "исправленный" заголовок (причём ещё зачем-то дополнительно экранируется двойная кавычка): Пример \

Кеш создаётся относительно значения SQL запроса в переменной $this->query if ( $allow_cache ) $rows = dle_cache ( "comm_".$allow_cache, $this->query ); В show.full.php этот запрос формируется со значением $where_approve = " AND " . PREFIX . "_comments.approve=1"; В engine/ajax/comments.php добавлены одинарные кавычки $where_approve = " AND " . PREFIX . "_comments.approve='1'";

Я-то думаю, чего это все модули посыпались и стали требовать обязательной передачи пустого параметра ShowLoading('') if (typeof positiony == 'undefined') { var positiony = 'center'; } if (typeof message == 'undefined') { var positiony = ''; } Два раза positiony вместо message

Пример: {custom idexclude="{news-id}" category="1,2,3" limit="10" order="reads"} Если открыть не существующую (удалённую) новость, то тег {news-id} не будет обрабатываться из-за проверки defined('NEWS_ID') : if( defined( 'NEWS_ID' ) AND !$this->is_custom) $content = str_ireplace( "{news-id}", NEWS_ID, $content ); В результате в шаблоне будет обработан custom на основании строки: {custom idexclude="{news-id} А оставшаяся часть строки: " category="1,2,3" limit="10" order="reads"} будет отображаться как текст.

Я понимаю причину такого решения. Полагаю в текущей реализации работы с доп.полями это действительно единственный наименее болезненный выход. Основная суть посыла в том, что необходимо как-то уведомлять пользователя о запрете использовать запятые, а так же "новое не должно ломать старое". Да это просто выдуманный нежизнеспособный пример. Речь не бизнес-логике воображаемого приложения, а о неочевидном для пользователей изменении поведения поля при наличии запятой в списках. Будут проблемы при смене символа. Если сейчас `,`, а потом в шаблоне надо будет `/`, то пр

Нууу, очень спорное решение в данном случае. Вообще нигде не указано, что теперь нельзя использовать запятую в списках. Человек просто заметил, что поле не сохранилось. Нет никаких ошибок или сообщений при использовании запятой в поле. Основная суть проблемы в том, что: 1. Поменялась логика поведения прежнего функционала даже при выключенной опции мультивыбора. 2. Нигде не написано, что теперь нельзя использовать запятую в значении поля списка. Оно просто молча перестало работать как было раньше. Почему я считаю это критической ошибкой. Допустим это интернет магазин,

Проблема связана с добавлением функционала Разрешить выбор нескольких значений Значение в списке имеет вид: Да, можно В /engine/inc/xfields.php теперь все значения списка по умолчанию обрабатываются словно включен мультивыбор и разбиваются по запятой: $fieldvalue = explode(',', $fieldvalue); → line: 1178 Т.е. в БД строка имеет вид: field|Да, можно||other|value где `Да, можно` – это одно цельное значение. А скрипт обрабатывает его словно это перечень значений. В результате чего при каждом редактировании новости слетает выбранное прежде значение. В коде идёт сравнен

Если при редактировании/создании RSS информера оставить поле выбора категории пустым, то будет Fatal Error. PHP 8 для функции count() теперь выбрасывает ошибку если ей передан не поддерживаемый тип, в данном случае NULL. engine/inc/rssinformer.php if( !count( $category ) ) {

Не-а. Не указано. Да и в целом неплохо бы добавить "защиту от дурака". К тому же проблема только в файле categories.php. Во всех других файлах этой проблемы нет.

Fatal error: Uncaught TypeError: Unsupported operand types: string * int in /engine/inc/categories.php:127 $max_file_size = (int)($config['max_up_size'] * 1024); Нужно так: $max_file_size = (int)$config['max_up_size'] * 1024; В конфиге: 'max_up_size' => '',

Комментарий удаляется из БД прямым запросом игнорируя параметр древовидных комментариев. Получается что если у комментария были ответы, то из поста пропадает вся ветка, хотя комментарии-ответы по факту существуют.