Василий Наумкин

Composer — это главная фишка MODX 3, которую никто не использует.

Если установлены через composer, то да, будет автозагрузка.

Судя по коду ты их просто положил в namespace MODX, так что да, так тоже работает.

Лично я терпеть не могу фасады Laravel, и это одна из основных причин, почему мы с ним не сработались.

Дело в том, что при переходе в addModifier здесь, мы попадём в фасад, а не в класс \Fenom, где этот метод и объявлен:

И это жутко бесит, когда пытаешь проследить логику работы.

Уж лучше вызывать нормально класс и подписывать его комментарием, зато никаких проблем с навигацией через IDE.

По моему, это гораздо проще и удобнее, чем городить фасады.

Но, в любом случае, спасибо за заметку. Кому-то, может, такое наоборот удобнее.

Я же выше объяснил, что происходит.

Ничего удалять не надо, просто добавляешь разрешение менять версии уже установленных пакетов ключом -W, что означает --with-all-dependencies.

Это не ошибка, там нет никаких ошибок. Он просто не может разрешить зависимость автоматически и просит тебя указать ему явно разрешение:

composer require mmx/fenom --update-no-dev --with-all-dependencies

У меня всё норм — вот, записал видосик

Тебе там пишут, что у тебя уже установлен пакет psr/container 2й версии. Проверяем, почему именно второй:

Просто потому, что можно или 1ю, или 2ю. Никаких особых требований нет, поэтому Composer выбрал версию 2.

Затем ты требуешь установить mmx/fenom — и тебе говорят, что для этого надо изменить зафиксированную версию psr/container.

illuminate/container[v8.0.0, ..., 8.x-dev] require psr/container ^1.0 -> found psr/container[1.0.0, ..., 1.x-dev] but the package is fixed to 2.0.2 (lock file version)

Как это сделать тебе говорят чуть ниже:

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Просто разреши даунгрейднуть версию ключом:

composer require mmx/fenom -W

Всё устанавливается, только что проверил на modhost.pro

Очень рад, что тебе нравится!

Примерно тоже самое, только при помощи mmxDatabase:

$id = $modx->getOption('id', $scriptProperties);
$category = $modx->getOption('category', $scriptProperties, '1', true);

$resource = \MMX\Database\Models\Resource::query()
    ->select('id', 'pagetitle')
    ->with('TvValues', static function($c) use ($category) {
        $c->select('value', 'contentid', 'tmplvarid');
        $c->whereHas('Tv', static function($c) use ($category) {
            $c->where('category', $category);
        });
        $c->with('Tv:id,name,caption,default_text');
    })
    ->find($id);

return $resource ? print_r($resource->toArray(), true) : 'Not found';

Получается 3 простых выборки, без join.

Сначала выбирается ресурс, потом значения его ТВ из нужной категории, а затем добираются основные свойства этих ТВ.

Eloquent собирает все данные вложенными массивами в итоговый результат:


Дальше можно перебирать результат на Fenom со всеми проверками на пустоту и прочее.

А это уже моя ошибка в последней версии mmxDatabase, уже исправил.

composer update
composer exec mmx-forms install

и всё должно работать.

Я так понял версии компонентов не совместимы и ничего не устанавливается)

Неправильно ты понял, тебе там пишут другое.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

То есть, у тебя уже установлен какой-то пакет с неподходящей версией. И его можно обновить, если указать ключ -W. Только и всего.

Composer не делает это сам, а предупреждает тебя, чтобы ты принял решение.

Вот как такое разгуливать в будущем не ясно.

Как и всегда — внимательно читать сообщения об ошибках.

Если же элемент не статичный, то из специальной таблички читается время его последнего обновления (которое сохряняется туда плагином, потому что MODX эти данные не хранит).

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

— эта заготовка для создания ОДНОГО дополнения?

Да

Или можно в рамках одного сайта разработать сразу 5 несвязанных друг с другом дополнений?

Наверное можно, но я с трудом могу себе представить как кто-то зачем-то разрабатывает 5 несвязанных дополнений на одном сайте. Это же Docker — сделай 5 проектов и разрабыватывай независимо.

— это именно инструмент разработки ДОПОЛНЕНИЙ? Или же я могу так же удобно запустить сайт в докере, разработать нужный мне функционал, но не создавать никаких дополнений, а просто перенести весь код на сервер?

Кто ж тебе помешает?

Придумано для дополнений, но можно делать и запускать целиком сайты в Docker со своим функционалом.

Тоесть если захочется дотянутся до категорий извне вашего дополнения, то либо на уровне sql запросов или же создавать xml схему и модель, которую понимает modx и затем следить, чтобы модель eloquent и модель modx всегда были синхронизированы.

В MODX 3 есть Composer с автозагрузкой, так что модели дополения доступны отовсюду. Можно просто создать сниппет и выбрать все категории вот так:

$categories = \MMX\Super\Shop\Models\Category::query()->get()->toArray();

return print_r($categories, true);

непонятно какой шаблонизатор используется

Это решает автор дополнения, никакого «шаблонизатора по умолчанию» нет.

Давай попробуем вот так — youtu.be/BbyfFDARgZU

Всё прошло очень хорошо, парни из Sterc привезли с собой оператора, который всё заснял и зафотал. Сейчас это дело смонтируют и выпустят документалку, можно будет посмотреть.

Новостей именно про развитие системы, кроме моего доклада, вроде и не было никаких. Разве что Sterc представили новый портал для поиска работы, связанной с MODX — www.workwithwander.com.

Мой доклад прошёл очень хорошо, теперь самому интересно посмотреть, как это выглядело со стороны. Особенно народ оживился на словах о том, что можно нанимать сотрудников не из мира MODX, а с более широкого рынка современной PHP разработки.

В общем, ждём документалку.

windows — страшная тема для docker) кто смог настроить docker под window, респект

Давно использую на Windows 11, через родной Hyper-V.



Заморочки видимо с WSL, попробуй без него на досуге.

Полностью перешёл на Vesp и очень доволен.

Но, как показала практика, освоить работу с ним непросто, поэтому сейчас я возвращаюсь вместе с Vesp в MODX — для чего и придумал новые composer-only дополнения.

Теперь я могу писать современные приложения внутри MODX, что должно хорошо повлиять в целом на систему. Про это и буду рассказывать всем в Белграде.

Насколько будет сложнее делать на модных Laravell + Vue.js?

Можешь почитать курс про работу на Vesp, там будет понятно. Есть еще и продолжение про переезд магазина с miniShop2 на Vesp.

Если кому интересно — то я тоже поеду в Белград, рассказывать про новые composer дополнения.

Уже заанонсили на официальном сайте мероприятия:

И по факту будет сайт с двумя видами дополнений.

Именно так, да — переходный период.

Со временем новых mmx* дополнений должно быть больше, а старые делать и обновлять просто перестанут. Понятно, что это годы, но тем не менее.

Заодно это неплохой предлог перевести текущие актуальные компоненты на новые рельсы, выкинув всякое старьё. Мы же чисто теоретически.

Но другого в ближайшее время в MODX не будет.

С таким подходом — тем более.

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

ну явно что не rest.modx.com.

То есть ты еще и какой-то репозиторий доработаешь, и в админку MODX новые функции для работы с пакетами протолкнёшь?

Прям не терпится почитать, что тебе в MODX LLC ответят на pull-request.

в случае с закрытым репозиторием как подписывать и узнавать об обновлении?

А как из него код качать? Если есть доступ — будут и уведомления. Тем более, если за доступ еще и платить надо будет.

И автоматом загружать в репозитории.

И всё для того, чтобы пользователи не начинали развиваться.

Я эти дополнения сделал с противоположной целью, если что — заставить юзеров MODX пользоваться композером.