Я на всякий случай уточню, что оригинальный менеджер пакетов, который был и есть в MODX2, в MODX3 никуда не делся и он работает ровно также, как и 10 лет назад. Для кого-то в этом и проблема (типа старый уже, надо менять), а кто-то видит в этом стабильность)))

Предложенное автором поста решение актуально при использовании новой, альтернативной возможности подключать внешний код в MODX-проекты. Эта возможность встроена в движок с версии MODX3, но как следует из поста, имеет проблемы, которые к нашей всеобщей полагаю радости, при прямых руках и светлой голове, решаемые :)

А получившийся метод реализации как мне кажется, имеет больший потенциал т.к. вылился в некий альтернативный способ установки дополнений, основанный на развитом и популярном менеджере пакетов composer, который ещё даже не существовал или был в зародыше (судя по wiki), когда в MODX появился в текущем виде свой пакетный менеджер с установкой дополнений через админку.

Может и должно, но не происходит)

Потому что на MODX и в том виде, как сейчас есть, довольно комфортно работается… может не всем, как всегда :)

Да и новая версия недавно вышла, сейчас есть смысл развивать и адаптировать дополнения, чем и занимается в основном местное сообщество! И здесь с ocstore можно провести аналогию в том, что для minishop (который сам является дополнением к MODX) есть и появляются новые свои дополнения. И не только он, есть и другие компоненты, которые образуют свою экосистему, работая дополняя друг друга.

Насколько я понимаю, должно произойти нечто подобное, что произошло с opencart.
Есть opencart, разрабатываемый американским разработчиком, есть отдельный (форк? не люблю я этот жаргон, скоро совсем уже нормальных слов не останется) — ocstore, который хоть и базируется на opencart но делается отдельными разработчиками, со своими модулями и дополнениями.

Тогда будет задержка в несколько секунд, во время отправки. Иногда до 5 секунд доходит.
Было интересно, возможно ли в FormIt такое привязать. Странно, что это не реализовано.

Проще настроить SMTP и тогда таких проблем не будет.

Дим, лично для тебя разрешаю Console. Сам не пользуюсь ей давно.

Спасибо большое, Николай, за решение! О нем мечтали, его ждали, про него спрашивали, потом его просили, и вот оно здесь!

P.S Столько обновлений здесь в последнее время, аж глаза разбегаются и такую ценную заметку банально не заметил… А может, потому что картинки в анонсе нет!? Но это не в укор, а просто попытка самоанализа.

P.S.2 А просто Console не подойдет? Просто он почти везде уже есть…

Я к тому, что до текущего момента, можно было комфортно на хорошем уровне делать проекты с MODX, применяя ряд инструментов: тот же PHPstorm, git GUI «fork», WinSCP и админку MODX, с приятными интерфейсами, не являясь при этом консольным гиком, которому достаточно созерцания прекрасного в мигающем курсоре на черном фоне.

Все-таки composer это совсем не про программирование, а тоже инструмент, который в рамках MODX, мог бы, условно, мало чем отличаться от текущего менеджера пакетов с функционалом зависимостей.

Вон сделали же GUI modxminify чтобы не собирать вручную в коде бандлы как в minifyx. Я вот не пользуюсь им, но много где видел, и соглашусь что это блин удобно для проектов где не обязательно весь код держать под git-ом (А такие бывают? — бывают)))

Идея контролировать git-ом через composer.jsom даже версии установленных пакетов в систем мне лично очень нравится, но полностью отказываться от удобного GUI-менеджера пакетов навсегда, все-таки больше похоже на шаг назад. MODX не конкурирует с Laravel, в котором куча консольных инструментов и даже веб-сервер вроде как есть свой вместо nginx/apache, это давно ясно и ничего плохого в этом нет. А вот проигрывать в удобстве админки ещё и Wordpress было бы вообще печально.

потому что это ж программированию учиться нужно, а они привыкли на коленке все собирать

Иван, ну не стоит преувеличивать. Конечно, программисты с личным развитием всё время хотят усложнять свои проекты, и одновременно упрощать свои инструменты. Поэтому да, конечно для тех, кто развивает платформу, в т.ч. MODX, желание привнести крутых навороченных штук, не обращая внимания на порог вхождения, естественно) Однако если посмотреть с другой стороны: для вас, крутых разработчиков, и для некоторых других (например, с очень большой натяжкой, для меня, еле догоняющего) это «проект», а для очень многих — инструмент!

Ничего плохого в том, чтобы инструмент оставался простым, до определенного, конечно, предела, вовсе нет!

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

Это будущее давно уже настоящее везде, где есть Composer. А для платных (ну или просто приватных) репозиториев есть даже такая тула — github.com/composer/satis.
Ну или можно заплатить денег пакаджисту и публиковать там packagist.com/pricing
Вопрос в том, что аудитория MODX всячески сопротивляется подобным нововведениям, потому что это ж программированию учиться нужно, а они привыкли на коленке все собирать, чтобы хоть как-то работало, особо не вдаваясь в нюансы.

Мне интересно, если они в курсе, то как объясняют сложившуюся ситуацию

Спасибо Василий! Уже можно сказать десятилетиями, привносишь в MODX полезные и прогрессивные вещи. Системный подход твоих решений — впечатляет.

Очень надеюсь что формат приживется. А ещё надеюсь, получится сделать для этого формата дополнений GUI, чтобы его использование было также дружелюбно и к тем, кто с консолью обращается не часто… И дополнения «привычно» можно было ставить из админки.

Кажется, описанное в заметке решение — будущее дополнений для MODX3. Надеюсь, как минимум MODSTORE заинтересован в поддержке такого формата!

Честно не совсем понял в чем идет улучшение/ускорение сборки. Макеты все равно надо будет верстать. А клиенту по сути подойдет прототип в виде картинки (как и дизайнеру), который так-же можно собрать в той-же Figma. Базовые компоненты можно так-же установить и пользоваться ими. Возможно тут пока не попробуешь, не поймешь, если подвернется случай, протестирую) Спасибо за ваш труд.

1. Сделать её кнопкой button
2. Добавить атрибут form со значение form
3. Добавить атрибут type со значением submit.

В моём случае эта проблема решилась переключением сайтов на nginx в настройках хостинга.

Что-то опять запутался
Форма лежит в id=“form”

…
e = ‘<li><a href=“#{0}” role = “menuitem”>{1} </a></li>…

Это ссылка которая выводит кнопку FINISHE что сделать чтобы это ссылка-кнопка работала как кнопка отправки?

Удалось решить вопрос? Тоже Оформление заказа не считает, а остальное все работает

Можно же обойтись без js, т.к. есть атрибут form

<form id="myform">
  // ...
</form>

<button type="submit" form="myform">Моя кнопка вне формы</button>

Спасибо за ответ. Как обычно напишешь пост и решение в голову приходит)