Ну теперь очевидно, что даже приведенный список пакетов означает актуальность уровня «уже» а не «скоро», как в начале показалось. И со временем будет расти…
Тогда получается, что одним best practice by Василий не обойтись, ведь родной менеджер пакетов всё ещё работает, и надо всё равно во встроенный механизм автозагрузки как-то добавлять проверку.
Беглый гуглинг показал, что не только с MODX 3 так бывает ¯\_(ツ)_/¯ например у движка Википедии похоже было подобное (ссылка ниже)
Но существуют решения (которые прямо сейчас в MODX конечно не поддерживаются):
• как встроенными средствами composer-а через специальный формат записи конфигурации ( stackoverflow )
• так и инструменты, помогающие это автоматизировать, например wikimedia/composer-merge-plugin
Наверное с эти уже пора отправляться с issue к MODX Core team, чтобы уточнить возможность прикрутить это, или нечто подобное к существующему механизму, если не для автоматизированного решения проблемы, то хотя бы для вывода предупреждений о конфликтах версий зависимостей при установке пакета… Или уже обсуждается, и я опять не осилил поиск на гитхабе?)))
UPD. Так оказывается уже и PR сделали: github.com/modxcms/revolution/pull/16421 ставь лайк, подписывайся (чтобы разрабы видели что важная тема), оставляй коммент (чтобы уж точно) и забирай код в свою задачу! (пока не выпустили в следующем патч-релизе MODX, там они почти доделали уже, с переводами встряли что-то)
Может кто-нибудь привести примеры хотя бы 1 или лучше 2 дополнений, где есть автозагрузка через bootstrap.php, которые потенциально могут сломать друг друга? Мне тема показалась довольно серьезной, хочу проверить!
Если этот путь никуда не приведет, придется тебе отказаться от стандартного способа отправки и написать свой небольшой хук (это не сложно, просто сниппет создаешь в котором уже будут заполненны в переменных данные из твоей формы вот документация с примерами), для отправки почты. Тогда, возможно, тебе пригодится знать, что существует modSwiftMailer и возможность отправлять письма с помощью modHelpers. Ну или в своём хуке подключи библиотеку, отправляющую код из PHP с поддержкой DKIM.
Пожалуйста, @Валерий если сможешь подписать письмо без внешнего SMTP, поделись решением! А то недавно Яндекс.Почта, которую последние лет 10 многие использовали как внешний SMTP для отправки писем, отключила бесплатный тариф, и вопрос с почтой стал очень актуальным :))
Вон сделали же GUI modxminify чтобы не собирать вручную в коде бандлы как в minifyx. Я вот не пользуюсь им, но много где видел, и соглашусь что это блин удобно для проектов где не обязательно весь код держать под git-ом (А такие бывают? — бывают)))
Идея контролировать git-ом через composer.jsom даже версии установленных пакетов в систем мне лично очень нравится, но полностью отказываться от удобного GUI-менеджера пакетов навсегда, все-таки больше похоже на шаг назад. MODX не конкурирует с Laravel, в котором куча консольных инструментов и даже веб-сервер вроде как есть свой вместо nginx/apache, это давно ясно и ничего плохого в этом нет. А вот проигрывать в удобстве админки ещё и Wordpress было бы вообще печально.
Мне вот на подобие этого нужно было как-то вызывать хук для формита с API-вызовами к внешнему сервису но без отправки формы, так пришлось его код копировать и в сниппет выносить, а стоило сделать вот так как в заметке сделан сниппет send_email, чтобы не дублировать код и не поддерживать потом 2 версии…
К стати дополню список — в AjaxFormitLogin этот метод тоже будет работать
Ну теперь очевидно, что даже приведенный список пакетов означает актуальность уровня «уже» а не «скоро», как в начале показалось. И со временем будет расти…
Тогда получается, что одним best practice by Василий не обойтись, ведь родной менеджер пакетов всё ещё работает, и надо всё равно во встроенный механизм автозагрузки как-то добавлять проверку.
Беглый гуглинг показал, что не только с MODX 3 так бывает ¯\_(ツ)_/¯ например у движка Википедии похоже было подобное (ссылка ниже)
Но существуют решения (которые прямо сейчас в MODX конечно не поддерживаются):
• как встроенными средствами composer-а через специальный формат записи конфигурации ( stackoverflow )
• так и инструменты, помогающие это автоматизировать, например wikimedia/composer-merge-plugin
Наверное с эти уже пора отправляться с issue к MODX Core team, чтобы уточнить возможность прикрутить это, или нечто подобное к существующему механизму, если не для автоматизированного решения проблемы, то хотя бы для вывода предупреждений о конфликтах версий зависимостей при установке пакета… Или уже обсуждается, и я опять не осилил поиск на гитхабе?)))
В любом случае, ещё раз спасибо @Василий Наумкин и @Николай Савин за пояснения!
Если я правильно понял, самого факта того, что где-то в подпапках лежит конфиг composer.json и разработчик для обновления вендорных исходников вручную запускает composer, не достаточно, чтобы возникла возможность коллизии.
А чтобы эффект проявился, нужно чтобы пакет специально использовал в новом стиле composer:
Такие пакеты кто-нибудь встречал? Дайте ссылку плиз, я не могу найти
А «такое себе занятие», в смысле что мало развлечения, «слишком» проверено и стабильно? Ну такой себе недостаток :)
На самом деле есть что улучшать и в двойке, и возможно некоторые фичи, которые попали в 3й релиз, вышли бы лучше для двойки (имхо), но так или иначе релизу 3 уже больше года, смысл говорить о 4 есть только в разрезе решения каких-то глобальных проблем, а даже описанные в статье косяки с composer возможно при исправлении потянут всё-таки на релиз минорной версии, т.к. в ряд ли обратная совместимость сломается от реализации проверки версий подключаемых пакетов…
Если всё равно будешь копать PHPmailer для совей задачи, может за одно запилишь PR в MODX? Прославишься отважным :) !UPD. Так оказывается уже и PR сделали: github.com/modxcms/revolution/pull/16421 ставь лайк, подписывайся (чтобы разрабы видели что важная тема), оставляй коммент (чтобы уж точно) и забирай код в свою задачу! (пока не выпустили в следующем патч-релизе MODX, там они почти доделали уже, с переводами встряли что-то)
Сейчас для MODX3 большинство дополнений как раз такие (т.к. адаптированы, но сделаны были для MODX2) поэтому проблема и не проявляется массово?
Я ещё перед тем как первый коммент написать, я проверил исходные коды популярных дополнений: FormIt, Minishop2, MIGX, pdoTools, ImageCropper, Formalicious, CKEditor Resizer и некоторых других и нигде нет bootstrap.php которые по 10 раз должны (или могли) бы загружаться, как описано в статье.
Может кто-нибудь привести примеры хотя бы 1 или лучше 2 дополнений, где есть автозагрузка через bootstrap.php, которые потенциально могут сломать друг друга? Мне тема показалась довольно серьезной, хочу проверить!
Если этот путь никуда не приведет, придется тебе отказаться от стандартного способа отправки и написать свой небольшой хук (это не сложно, просто сниппет создаешь в котором уже будут заполненны в переменных данные из твоей формы вот документация с примерами), для отправки почты. Тогда, возможно, тебе пригодится знать, что существует modSwiftMailer и возможность отправлять письма с помощью modHelpers. Ну или в своём хуке подключи библиотеку, отправляющую код из PHP с поддержкой DKIM.
Пожалуйста, @Валерий если сможешь подписать письмо без внешнего SMTP, поделись решением! А то недавно Яндекс.Почта, которую последние лет 10 многие использовали как внешний SMTP для отправки писем, отключила бесплатный тариф, и вопрос с почтой стал очень актуальным :))
Если будут вопросы по ходу — задавай!
Предложенное автором поста решение актуально при использовании новой, альтернативной возможности подключать внешний код в MODX-проекты. Эта возможность встроена в движок с версии MODX3, но как следует из поста, имеет проблемы, которые к нашей всеобщей полагаю радости, при прямых руках и светлой голове, решаемые :)
А получившийся метод реализации как мне кажется, имеет больший потенциал т.к. вылился в некий альтернативный способ установки дополнений, основанный на развитом и популярном менеджере пакетов composer, который ещё даже не существовал или был в зародыше (судя по wiki), когда в MODX появился в текущем виде свой пакетный менеджер с установкой дополнений через админку.
Потому что на MODX и в том виде, как сейчас есть, довольно комфортно работается… может не всем, как всегда :)
Да и новая версия недавно вышла, сейчас есть смысл развивать и адаптировать дополнения, чем и занимается в основном местное сообщество! И здесь с ocstore можно провести аналогию в том, что для minishop (который сам является дополнением к MODX) есть и появляются новые свои дополнения. И не только он, есть и другие компоненты, которые образуют свою экосистему, работая дополняя друг друга.
P.S Столько обновлений здесь в последнее время, аж глаза разбегаются и такую ценную заметку банально не заметил… А может, потому что картинки в анонсе нет!? Но это не в укор, а просто попытка самоанализа.
P.S.2 А просто Console не подойдет? Просто он почти везде уже есть…
Все-таки composer это совсем не про программирование, а тоже инструмент, который в рамках MODX, мог бы, условно, мало чем отличаться от текущего менеджера пакетов с функционалом зависимостей.
Вон сделали же GUI modxminify чтобы не собирать вручную в коде бандлы как в minifyx. Я вот не пользуюсь им, но много где видел, и соглашусь что это блин удобно для проектов где не обязательно весь код держать под git-ом (А такие бывают? — бывают)))
Идея контролировать git-ом через composer.jsom даже версии установленных пакетов в систем мне лично очень нравится, но полностью отказываться от удобного GUI-менеджера пакетов навсегда, все-таки больше похоже на шаг назад. MODX не конкурирует с Laravel, в котором куча консольных инструментов и даже веб-сервер вроде как есть свой вместо nginx/apache, это давно ясно и ничего плохого в этом нет. А вот проигрывать в удобстве админки ещё и Wordpress было бы вообще печально.
Ничего плохого в том, чтобы инструмент оставался простым, до определенного, конечно, предела, вовсе нет!
Очень надеюсь что формат приживется. А ещё надеюсь, получится сделать для этого формата дополнений GUI, чтобы его использование было также дружелюбно и к тем, кто с консолью обращается не часто… И дополнения «привычно» можно было ставить из админки.
Кажется, описанное в заметке решение — будущее дополнений для MODX3. Надеюсь, как минимум MODSTORE заинтересован в поддержке такого формата!
Буду пробовать собрать на основе moxi мой любымый стэк!
Спасибищще!
А дополнительные возможности разметки и подсветка синтаксиса MODX + Fenom это просто здорово! Уверен что авторы документации оценят и через какое-то время мы начнем встречать всё больше этих фишек со спец. разметкой даже в привычных разделах!
Старый сайт документации тоже был не плох, но заметно уже устарел. Хотя отмечу, что некоторые моменты на новом заметно отличаются (например навигация по breadcrumbs) и по началу это может быть не привычно. Но в целом стало намного лучше. Большая и впечатляющая работа! Спасибо за неё, и за то, что находите возможным рассматривать обратную связь ;)
Ещё очень здорово, что даже редиректы со старой версии сделали, проверял руками множество ссылок из чата сообщества, битых не нашлось — репект!
А вообще, можешь сам провести тесты, используя параметр &return со значением sql и поймешь как это работает (нужно базовое понимание SQL-запросов, само собой, но для чтения уже написанного это довольно простой язык)
Казалось бы просто сообщения об ошибках, че там… но на рабочих магазинах где заказы и менеджеры «шуршат» ежедневно, банальные сообщения об ошибках способны сохранять комфортно-прохладную температуру там, где раньше подгорали чьи-то кресла в случаях когда «что-то пошло не так, а я ничего не нажимала» :)
Как не страшно это говорить, но похоже ради этих новых фишек стоит начинать задумываться об обновлении магазинов со «старых» версий MiniShop2 2.x и даже 1.х
Спасибо за релиз!
Но @Илья все равно спасибо что поделился решением!