Sander1

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

Нууу, очень спорное решение в данном случае. Вообще нигде не указано, что теперь нельзя использовать запятую в списках. Человек просто заметил, что поле не сохранилось. Нет никаких ошибок или сообщений при использовании запятой в поле. Основная суть проблемы в том, что: 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' => '',

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

Комментарий отправляется на модерцию. Счётчик новости не меняется. Зачем в таком случае чистить кеш? engine/modules/addcomments.php Перед строкой: clear_cache( array( 'news_', 'comm_'.$post_id, $cprefix, 'stats' ) ); Достаточно добавить код: if ($where_approve) И обратите внимание на п.2. При подтверждении комментария через AJAX обработчик не очищается кеш комментариев новости. PS. И ещё, чтобы отдельную тему не создавать. Пользователь с именем `noname` проклят невозможностью выставлять оценки в рейтинге. Все гости записываются в таблицу `dle_logs` и `dle_commen

Проблемы с очисткой кеша. 1. При добавлении коммента, который уходит на модерацию – всё равно чистится кеш. Самое плохое что чистится кеш всего контента – `news_` 2. При ajax подтверждении комментария – излишне чистится почти весь кеш всего сайта, кроме того который реально необходимо чистить – `'comm_' . $post_id`

В админке в расширенном поиске новостей добавить возможность поиска по исключению. К примеру – найти все новости где доп.поле НЕ содержат строку poster| Какой-нибудь селектор со списком выбора, к примеру: Содержит Не содержит Строго равно Начинается на Начинается НЕ на Заканчивается на Заканчивается НЕ на

Не охота создавать отдельный топик, файл engine/ajax/adminfunctions.php – небольшая опечатка: index.php??subaction PS. К слову в этом файле для метода commentspublic тоже можно добавить проверку существования коммента на всякий случай.

При массовом подтверждении комментариев если случайно обновить страницу и подтвердить повторную отправку формы, то в новостях будет повторно увеличен счётчик comm_num+1 Не выполняется проверка на существование комментария и находится ли он на модерации.

Парочка предложений по утилите управления плагинами. 1. Есть параметр `Обязательное наличие плагина`. Но он поддерживает только один плагин. А иногда когда делаешь комплексную систему – идёт связка из нескольких отдельных модулей. Идеальным вариантом было бы использование чего-то подобного конфигурационному файлу composer-а, например что-то примитивное типа: { "name": "Sandev\CurrentModName", "require": { "php": "^7.1 || 8.1", "dle": ">=14.2 && <16.0", "Sandev\RequiredModule": "*", "Sandev\AnotherRequiredModule": "*", } } А если сюда ещё добавить и autoload