Все, прочел заметку на modx.pro Вопросов по набору параметров нет.

Доброго дня! Xlexicon не размещался в репозитарии modx.com? Не планируете?

Доброго дня! Вы пишете: затирка наборов параметров . Действительно наборы параметров перестали работать, хотя все они по прежнему есть на одном из обновленных сайтов. Уточните, у вас только не срабатывают или нарушены\удалены после обновления? Спасибо.

Всего не протестируешь. Но судя по всему приняли какие-то сторонние PR-ы, ИМХО. Человек, знающий хорошо как работает xPDO, вряд ли бы допустил такие ошибки. Сейчас попробую разобраться кто и что сломал.

Интересен момент, что разработчики Modx забыли протестировать релиз перед публикацией!

Не получается, в смысле та же самая ошибка появляется…

Николай, спасибо за ответ! А можете подсказать как сделать откат? Как при стандартном обновлении не получается (скинуть файлы установки в папку с сайтом и обновить).

И здесь как всегда проблема с индексами возникает. Если, например, в таблице ресурсов мы создаём числовое поле (sCount) и индекс idx_sCount по этому полю, то при выполнении запросов, в которых выполняется фильтрация и по полю published (или deleted), и по числовому полю (sCount) (не важно, в какой последовательности), то MySQL будет использовать индекс published, а не idx_sCount (как этого следовало бы ожидать) — это приведёт к почти полному перебору всех ресурсов (если положить, что почти все ресурсы являются опубликованными). Аналогично и с (deleted). При этом если в таблице будет индекс по обоим этим полям, то MySQL выберет именно этот индекс (как и должно быть). Решить проблему можно 3 способами: 1.Для каждого запроса указывать необходимый индекс. Сложности этого способа очевидны: — сложна реализация (xpdo индексы не поддерживает) — необходимый индекс придётся указывать для каждого запроса и при изменении имени или структуры индекса придётся все эти запросы пересматривать 2.Для собственных полей указывать составные индексы, начинающиеся со стандартных полей и заканчивающиеся собственными полями (например: idx_published_sCount, idx_classKey_deleted_published_sCount). Но в этом случае часть существующих запросов может начать тормозить, поскольку при наличии 2, 3 и более индексов, начинающихся со стандартных полей, MySQL на некоторых запросах (предположительно, с конструкцией IN + может зависеть и от версии MySql) начинает очень долго выбирать оптимальный индекс: modxclub.ru/topics/vyiborka-iz-%28modtemplatevarresource%29-sushhestvennoe-uskorenie-pri-yavnom-ukazanii-indeksa-1759.html#comment-7177 3.Для собственных полей указывать составные индексы, начинающиеся с собственных полей и заканчивающиеся стандартными (например: idx_sCount_published, idx_sCount_classKey_deleted_published). В этом случае эти индексы MySQL будет рассматривать в качестве возможных только в тех запросах, в которых используются наши собственные поля. И при этом в тех запросах, в которых присутствуют условия и по стандартным полям, и по нашим полям, будет использовать именно эти (наши) составные индексы, а не простые стандартные.

Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/ Но этот вариант не всегда реализуем. Как, например, в моём случае. В целом по проекту: сочувствую… Некоторые TV всё-таки пришлось разместить в таблице ресурсов. А именно — числовые поля. И только те числовые, по которым выполняется фильтрация (на больше/меньше) и сортировка. Т.к.: а) во всех остальных случаях фильтрация и сортировка вполне себе нормально отработает и по строковым TV (с использованием индекса) б) с числовыми TV-полями при выполнении сортировки и фильтрации (на больше/меньше) пришлось бы выполнять преобразование на лету и как следствие, полный перебор БЕЗ использования индексов в) в нашем распоряжении имеется всего 44 индекса (64 минус 20 стандартных), соответственно, все TV в таблицу ресурсов не закинешь. Закидываю только необходимый минимум (числовая сортировка/фильтрация) Но логику, описанную в статье, немного изменил (под свой проект): 1.Числовые TV не перемещаю в таблицу ресурсов, а копирую. Памяти уходит больше, но упрощается логика + повышается безопасность (если что «поломается», всегда можно восстановить значения из стандартных TV) 2.Схему (modx->map) дополняю новыми полями также на лету, но не вручную, а программно — на основе структуры таблицы в БД (использую генератор xPDOGenerator) 3.Описание индексов новых полей в (modx->map) не помещаю, т.к. индексы xpdo нужны только для генерации таблиц в БД (или нужны для чего-то ещё ?) — Таким образом, получилась гибридная система TV-параметров: 1.Для выборки TV используется поле (properties) 2.Для фильтрации и сортировки по числовым полям используются собственные поля в таблице ресурсов (числовое сравнение) 3.Для фильтрации и сортировки по строковым полям — TV-поля подключаются через join (строковое сравнение) При такой организации TV: а) и выборку большого числа TV можно будет сделать довольно быстро (без кучи JOIN'ов) б) можно быстро (с использованием индекса) выполнять фильтрацию и сортировку как по строковым полям (строковое сравнение), так и по числовым полям (числовое сравнение), исключая преобразование типов на лету в) можно не заморачиваться тем, что в таблице ресурсов остаётся всего 44 индекса для собственных полей (для числовых полей, по которым выполняется фильтрация/сортировка, их всем хватит)

На 2.4 многие пожаловались. Я вот тоже. Откатывайтесь до 2.3.6, может поможет.