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

На всякий случай вкину ссылку на репо с miniShop3 который я переделал под Composer как-то раз на досуге — github.com/bezumkin/MiniShop3/

Это чисто proof of concept, для реальной работы не предназначено, просто доказательство возможности такой работы.

Никого ни к чему не призываю, просто для информации.

А планируется что-то типа ZoomX на modx 3?

Нет, я ничего такого не планирую.

Но в некоторых mmx-приложениях используется vesp/core для работы API, а у него внутри slim/slim — так что за фреймворками далеко ходить не надо, всё уже под рукой.

В Eloquent же всё интуитивно понятно)

Согласен!

После работы с ним к xPDO возвращаться нет никакого желания. Да и смысла нет.

Всё, чему ты научишься в xPDO за пределами MODX никому не надо. Eloquent для разработчика гораздо полезнее.

Это несложно, если процесс разработки хорошо отлажен и тебе ничего не мешает.

modx.pro/components/24619

Так ты сделай нормальное composer дополнение для MODX — и пусть его себе ставит кто хочет, вместе с остальными mmx-дополнениями. Древний транспортный пакет тут совсем ни к чему.

Есть же заготовка — просто используй.

Незнаю, может это не стоит считать проблемой, и вы и не планировали, что файлы в директории modx нуждаются в редактировании, но все же…

Именно так, да. Тем более, что настроить это сразу универсально никак не получится. Если есть хороший пример конфига — делись!

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

А я использую в production образы и хост одной и той же системы — Ubuntu (Debian), поэтому всё работает от одного юзера www-data. А на локальной MacOS проблемы с правами и вовсе нет.

Ну а кстати, зачем я вообще полез править файлы в modx. Админка тупо выдает белый экран. Главная страница сайта открывается, а никакие танцы с бубнами вокруг админки пока не помогли.

Скорее всего, MODX просто не может создать директорию с кэшем из-за прав, да.

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

Спасибо на добром слове, планирую продолжать!

Да, там был полный бардак с датами — сейчас привёл в порядок и написал тесты для проверки.

Обновляйся на версию 1.2.1

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);

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

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