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

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

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

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 пользоваться композером.

из наиболее логичного это инфу должен давать репозиторий на запрос CheckUpdates

Это как? Какой репозиторий будет проверять версию пакета в packagist.org и показывать в админке кнопку «обновить»? И что будет происходить при нажатии на эту кнопку?

Еще раз говорю, что если ты хочешь завязать работу на транспортные пакеты, тебе придётся обновлять их версию в репозиториях MODX.

ну так сейчас ты не про интерфейс управления?

Нет, я про консоль в админке, где надо будет пальчиками вбивать команды composer и читать ответы. Что-то типа такого интегрировать.

И вопрос — а как юзер узнает об обновлении если поставил пакет напрямую через композер?

Я предлагаю подписываться на релизы в репозитории:

Там можно следить за любыми разработками, не только для MODX — очень удобно.

1. Ты не ответил — как юзер узнает о релизе новой версии, если ты не загрузишь новый транспортник в репозиторий MODX?

У него же в управлении пакетами не загорится обнова, сам он «переустановить» не догадается нажать, composer пользоваться не умеет. Как обновляться-то?

Но согласись не хватает интерфейса для управления в админке?

Не соглашусь, это примерно то же, что уже произошло с MODX 3 — обновили на полшишечки, чтобы юзеров не распугать, теперь разгребаем.

У Composer уже есть отличный CLI. Лучше уж сделать пакет с окошком терминала для работы с этим CLI из админки, если так страшно заходить в консоль сервера.

PS. Василий сильно не ругайся!

Не буду, но у меня два вопроса.

1. У каждого транспортника своя версия, по которой админка отслеживает обновления, и если ты опубликуешь этот транспортник в репозитории MODX или modstore, то получается, тебе же надо будет следить за моими релизами на Github, и каждый раз менять версию этого транспортника?

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

2. Судя по коду, этот пакет разворачивается в core/components/mmxforms и будет лежать рядом с оригинальным core/components/mmx-forms. То есть, рядом будет 2 похожие директории: одна для транспортника, вторая для оригинального дополнения.

В общем, всё это как-то костыльно, но пусть пользователи нас рассудят. Кто хочет — будет учиться работать с composer, кто не хочет — будет скачивать виртуальные транспортники.

Думаю, речь о том, чтобы посмотреть на исходники mmxForms и делать такие же компоненты с административной частью на Vue 3.

Тогда можно будет получить (или использовать) актуальные знания, вместо ненужного древнего ExtJS 3.4.1.1, которому уже 11 лет.

Каким образом можно будет избежать конфликтов

Composer просто не позволит установить конфликтое приложение, и ничего не сломается.

Нужно будет поискать более подходящее приложение, или попросить автора адаптировать своё. Например, указать другие возможные версии зависимостей, как уже сделал я с vesp/core, для нормальной работы в MODX 3.

Скорее, это что-то с настройкой веб-сервера, потому что на modhost.pro дружественные url включать не нужно.

Главное, чтобы любой запрос попадал на index.php, а там уже сработает плагин.

Все запросы в приложение перехватываются плагином на onHandleRequest, дальше проверяется адрес запроса и, если он начинается с /mmx-forms/, то передаётся контроллеру.

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

Я только что проверил работу на modhost — всё отлично, проблем нет.


Попробуй и ты, я дополнил заметку инструкцией для этого хостинга.

1. Что делать, если зависимостей много и установка прервётся по таймауту? Это же web-запрос
2. Как отвечать на вопросы от Composer при разруливании зависимостей?

Но я, конечно, никому не могу помешать так делать.

Это тоже изврат, не надо такое поддерживать.

Мало того, что это сам по себе костыль, так еще и непонятно как зависимости через админку разруливать, в случае чего. А дальше надо опять как-то собирать траспортный пакет через MODX, грузить в репозитории, там еще что-то может поломаться…

Народ даже придумал консольный сборщик GPM, который работает по json схеме. Никому не нравится собирать транспортные пакеты, это издевательство.

Куда лучше потихоньку писать новые дополнения и переводить старые на установку из Composer. Будут хорошие дополнения использовать этот подход — будут и юзеры.