Сергей Шлоков

если не считать статических сниппетов, они в fenom ужасно работают, постоянно кэшируются и выдают неверные данные.

Можешь рассказать подробнее?

Как сделать на SQL написал выше Илья. На php через $modx->getChildIds() в цикле foreach.

А в чем проблема-то? Не понятно как это сделать базовыми методами MODX или SQL?

Зачем стучаться в закрытую дверь? Просто сделай отдельный пакет. Кому надо поставит. Не нужно лезть в исходники!!!
Я, например, когда начинал свой путь в MODX и мне надо было добавить функционал в Tickets, сделал отдельный TicketMessages, расширяющий исходный компонент, в который добавил всё, что мне надо. Я не мучал автора своими пулами.

Я вывел уже опытно-эмпирическим путем, что значение по умолчанию — оно не для выборки.

Ну для разрабов, не знающих SQL, справедливо. Для остальных сделать 2 джойна вместо includeTVs (который, кстати, делает тот же джойн) как 2 пальца…

еще раз, значение по умолчанию сделано не для выборки по нему, оно не добавляется в базу

Правда? А где же оно хранится?

Были аналогичные мысли по феному. Но чтобы сделать вдумчиво, надо погружаться в Java. Я не нашел лишнего года.
А вот с базой ты погорячился. Напрямую работать можно только при условии, что сервер MySql доступен снаружи. Часто такое бывает?

А вообще тема нужная.

WHERE  ( `TVis_present`.`value` = '1' ...

Разве не работает?

Много раз уже это обсуждалось… Дефолтное значение TV хранится в таблице modx_site_tmplvars, а сами значения в modx_tmplvar_contentvalues. Где-то у Боба Рэя инструкция валялась по работе с TV с этим учётом.

Как написал Артём, нужно делать индекс по этим полям (order_id и field_id). И лучше первичный ключ. А наследовать от xPDOObject.
В этом случае:
1. mySql будет следить, чтобы не было дублей.
2. Значительно ускорится выборка таких записей.

Я выше уже написал, что это не ошибка системы, а ошибка проектирования таблицы. В дальнейшем даже у новой модели может появится такая же проблема.

Просто первое, что бросается в глаза — это недоделанная структура таблицы. Именно поэтому возможны одинаковые записи. А так как getObject() получает только один объект, то вероятно, что он получает не тот объект, который ты проверяешь. А метод save() говорит, что объект обновлен и возвращает true. Просто это другой объект. Это самый вероятный сценарий при такой структуре таблицы.

А таблицу пересоздавал заново или просто переименовал? Т.е. данные оставались старые?

Мой вариант.

Сильно больше, чем вложено в Collections? На примере своих дополнений не вижу ничего особо сложного. У меня и данные в своих таблицах, и сниппеты с ними работают, и чанки и т.п.

И как люди во фреймворках живут? ))

Мда. Вера в MODX окончательно пошатнулась. Я был уверен, что хоть у одного разработчика родилась мысль сделать отдельную таблицу для ресурсов. И тут на тебе… Ни одного не оказалось. Ау, ребята, вот вам крутая идея!!!

Что бы там Джейсон себе не фантазировал, но как только разработчик доходит до мысли, что нужные ему данные проще хранить в своих таблицах, ему резко перестают быть нужны ТВ, шаблоны, чанки и сам MODX.

100%. Многие бывшие модиксеры из этого сообщества это подтвердят.

Ан нет, Collections — это тоже CRC.

Разве? Так делал Articles. Лично у меня в голове отложилось, что разница у них в том, что Collections хранит контент в отдельной таблице. И Джейсон где-то в обсуждениях говорил, что юзайте Collections, а не пихайте всё в дерево ресурсов, которые являются эндпойнтами.

Не надо наводить тень на плетень. Возможность расширения базового функционала никак не является руководством к использованию ресурсов как к хранилищу контента сайта. Такая возможность есть, но она не является обязательной. И для опытного разработчика нет никакой надобности добавлять свой CRC. Только если, конечно, не поставлена именно такая задача — своё контекстное меню, процессоры и т.п в дереве ресурсов.

А вообще для меня выглядит странно — принять руководство по расширения базового класса инструкцией к использованию ресурсов как хранилище контента сайта.

пока я буду расширять класс modResource под каждую свою модель я на том же ларавеле за это время половину админки напишу

А зачем? Есть уже готовые пакеты. В крайнем случае, можно по аналогии сделать свой пакет из заготовки modExtra.

И на ларавел ты не напишешь быстрее аналог дерева ресурсов. А на твоё возражение, что ты и не будешь его писать, отвечу — и в MODX не надо всё пихать в дерево ресурсов.

П.С. Это конечно моё мнение и оно может отличаться от твоего. Это не значит, что оно правильное или нет. Просто нет одного правильного решения. Каждый пилит код как умеет.