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

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

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

А вообще тема нужная.
Много раз уже это обсуждалось… Дефолтное значение TV хранится в таблице modx_site_tmplvars, а сами значения в modx_tmplvar_contentvalues. Где-то у Боба Рэя инструкция валялась по работе с TV с этим учётом.
Как написал Артём, нужно делать индекс по этим полям (order_id и field_id). И лучше первичный ключ. А наследовать от xPDOObject.
В этом случае:
1. mySql будет следить, чтобы не было дублей.
2. Значительно ускорится выборка таких записей.
Просто первое, что бросается в глаза — это недоделанная структура таблицы. Именно поэтому возможны одинаковые записи. А так как getObject() получает только один объект, то вероятно, что он получает не тот объект, который ты проверяешь. А метод save() говорит, что объект обновлен и возвращает true. Просто это другой объект. Это самый вероятный сценарий при такой структуре таблицы.
Мда. Вера в MODX окончательно пошатнулась. Я был уверен, что хоть у одного разработчика родилась мысль сделать отдельную таблицу для ресурсов. И тут на тебе… Ни одного не оказалось. Ау, ребята, вот вам крутая идея!!!

Что бы там Джейсон себе не фантазировал, но как только разработчик доходит до мысли, что нужные ему данные проще хранить в своих таблицах, ему резко перестают быть нужны ТВ, шаблоны, чанки и сам MODX.
100%. Многие бывшие модиксеры из этого сообщества это подтвердят.
Разве? Так делал Articles. Лично у меня в голове отложилось, что разница у них в том, что Collections хранит контент в отдельной таблице. И Джейсон где-то в обсуждениях говорил, что юзайте Collections, а не пихайте всё в дерево ресурсов, которые являются эндпойнтами.
Не надо наводить тень на плетень. Возможность расширения базового функционала никак не является руководством к использованию ресурсов как к хранилищу контента сайта. Такая возможность есть, но она не является обязательной. И для опытного разработчика нет никакой надобности добавлять свой CRC. Только если, конечно, не поставлена именно такая задача — своё контекстное меню, процессоры и т.п в дереве ресурсов.

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

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

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

П.С. Это конечно моё мнение и оно может отличаться от твоего. Это не значит, что оно правильное или нет. Просто нет одного правильного решения. Каждый пилит код как умеет.
Ничего подобного. Устанавливается каркас для работы с сайтом. Для визитки этого вполне хватит. А для сайтов типа блога умный разработчик ставит Collections или аналогичный пакет. И где-то в дебрях руководств Джейсон это объяснял.
Еще более дегенеративная особенность — MODX учит вас хранить все в ресурсах
И где он такому учит? Просто никому не хочется заморачиться с созданием отдельного интерфейса. Есть дерево ресурсов и нормально. Но есть уже дополнение Collections. Пользуйся на здоровье.
Плохо, что MODX не учит, что ресурс — это эндпойнт.
Походу надо отправлять на проверку к тебе перед публикацией статьи)))
Мне самому до совершенства далеко. Просто я сначала пишу черновик, потом вычитываю и правлю не только ошибки, но и смысловые обороты. И только через день, два публикую. И даже это не гарантирует от наличия ошибок. ))

П.С. Это я про большие серьезные статьи.