Sander1

Кеш создаётся относительно значения 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' => '',

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

Комментарий отправляется на модерцию. Счётчик новости не меняется. Зачем в таком случае чистить кеш? 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 Не выполняется проверка на существование комментария и находится ли он на модерации.