Статья полезная, буду думать, Пока на данном этапе каталог будет в пределах 300 товаров. Я думаю проблем не возникнет. Спасибо за помощь в очередной раз выручаете

По месту прописки ответчика. Я там прописан.

Спасибо. Справедливости ради скажу что вообще всю дорогу ощущал поддержку со стороны Суда. Ничего такого прямого не говорилось и не показывалось, но интуитивно я чувствовал, что они сразу понимали суть дела и были на стороне справедливости.

Поздравляю, Николай! Только на счёт Хабаровска не понял. Почему Арбитраж там состоялся?

Искренние поздравления! Очень радует, когда такие проигрывают по собственным искам. Вселяет надежду :)

Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее. Нет. С разбегу не получится. Не 5 минут… Логика должна быть такой. Перед выполнением метода prepare() запускается наша супер-функция (или метод), которая в объекте xPDOQuery делает следующее:

1. проходит по всем JOIN-таблицам и в их condition'ах корректирует ['condition']['bind']['type'], если он не соответствует модели таблицы
2. нестроковые условия по TV полям преобразовывает в их SQL-аналоги с использованием CAST'ов в зависимости от типа TV, задаваемого в modx_site_tmplvars
3. то же самое — для полей, участвующих в ORDER BY и HAVING Тогда работа с xPDO станет сказкой… А пока не горит. Нестроковые сравнения (< > <= >=) и сортировки по TV-полям и JOIN-полям оформляем в виде SQL с CAST'ами, всё остальное — оставляем как есть.

Issue — это только пожелания, обсуждения. Отправить готовый код — более предметно.

На английском не очень получается. Впрочем, писал уже: github.com/modxcms/revolution/issues/12307 ноль внимания… Хотя в версии 2.3.3 они там логику чуть изменили (так, что в описанных в этой теме условиях ошибки больше не вылезали), но «корячность» этой логики сохранилась (а может, я её не понимаю). Так или иначе в 2.3.3 эти 2 ошибки по-прежнему иногда вылезают, но гораздо реже и при других условиях (при каких — неизвестно). Что касается сабжа, то лучше я обёртку напишу. Так будет надёжнее.

Еще раз — шлите пуллреквесты, улучшайте работу MODX-а. Я вот шлю. На сегодня более 10% всех активных PR в MODX — мои. И вы можете приложить усилия, чтобы MODX стал лучше.

Всё равно некошерно. Ладно, с TV понятно — если там сравнение на неравенство используется, нужно непосредственно прописывать условие в виде SQL. Но когда то же самое приходится делать с собственными типизированными таблицами — это уже извращение.