Дима Касаткин

Хм, cтранно, что поиск на github не находиn bootstrap.php

Ну теперь очевидно, что даже приведенный список пакетов означает актуальность уровня «уже» а не «скоро», как в начале показалось. И со временем будет расти…

Тогда получается, что одним best practice by Василий не обойтись, ведь родной менеджер пакетов всё ещё работает, и надо всё равно во встроенный механизм автозагрузки как-то добавлять проверку.

Беглый гуглинг показал, что не только с MODX 3 так бывает ¯\_(ツ)_/¯ например у движка Википедии похоже было подобное (ссылка ниже)

Но существуют решения (которые прямо сейчас в MODX конечно не поддерживаются):
• как встроенными средствами composer-а через специальный формат записи конфигурации ( stackoverflow )
• так и инструменты, помогающие это автоматизировать, например wikimedia/composer-merge-plugin

Наверное с эти уже пора отправляться с issue к MODX Core team, чтобы уточнить возможность прикрутить это, или нечто подобное к существующему механизму, если не для автоматизированного решения проблемы, то хотя бы для вывода предупреждений о конфликтах версий зависимостей при установке пакета… Или уже обсуждается, и я опять не осилил поиск на гитхабе?)))

В любом случае, ещё раз спасибо @Василий Наумкин и @Николай Савин за пояснения!

Так эти пакеты аффектятся описанной особенностью работы MODX 3 с композером или нет?

Если я правильно понял, самого факта того, что где-то в подпапках лежит конфиг composer.json и разработчик для обновления вендорных исходников вручную запускает composer, не достаточно, чтобы возникла возможность коллизии.

А чтобы эффект проявился, нужно чтобы пакет специально использовал в новом стиле composer:

система проходит по всем зарегистрированным namespaces и пытается подключить из них файл bootstrap.php

Такие пакеты кто-нибудь встречал? Дайте ссылку плиз, я не могу найти

Западные мейнтейнеры и правда не особо отжигают) Тут сложно спорить :) Но релиз выпустили, работы идут, и фиксы и фичи есть, то что работает — не ломают (тоже не плохо, так не везде удаётся :)))

Да и на 2ке новые проекты делать уже такое себе занятие, конечно можно, так как уже все проверенно временем и стабильно работает.

А «такое себе занятие», в смысле что мало развлечения, «слишком» проверено и стабильно? Ну такой себе недостаток :)

На самом деле есть что улучшать и в двойке, и возможно некоторые фичи, которые попали в 3й релиз, вышли бы лучше для двойки (имхо), но так или иначе релизу 3 уже больше года, смысл говорить о 4 есть только в разрезе решения каких-то глобальных проблем, а даже описанные в статье косяки с composer возможно при исправлении потянут всё-таки на релиз минорной версии, т.к. в ряд ли обратная совместимость сломается от реализации проверки версий подключаемых пакетов…

Смотри какой issue нашел по теме: github.com/modxcms/revolution/issues/16396 — есть предложение в ядро MODX внести поддержку. Если всё равно будешь копать PHPmailer для совей задачи, может за одно запилишь PR в MODX? Прославишься отважным :) !

UPD. Так оказывается уже и PR сделали: github.com/modxcms/revolution/pull/16421 ставь лайк, подписывайся (чтобы разрабы видели что важная тема), оставляй коммент (чтобы уж точно) и забирай код в свою задачу! (пока не выпустили в следующем патч-релизе MODX, там они почти доделали уже, с переводами встряли что-то)

Вы специально зарегистрировались, чтобы это написать? Попробуйте лучше MODX 3 в деле! Это быстрый и удобный движок, на котором легко запускать простые и сложные сайты. А техническое несовершенство и постоянные новые и суровые вызовы для программистов найдутся и в любом другом движке. Разного рода запахи короче говоря, есть абсолютно у них у всех)

Спасибо, перечитал несколько раз, и если на этот раз правильно понял :), то всё что я написал выше, верно, но только для пакетов, собранных «по-старинке» без автозагрузки через bootsrap.php, так?

Сейчас для MODX3 большинство дополнений как раз такие (т.к. адаптированы, но сделаны были для MODX2) поэтому проблема и не проявляется массово?

Я ещё перед тем как первый коммент написать, я проверил исходные коды популярных дополнений: FormIt, Minishop2, MIGX, pdoTools, ImageCropper, Formalicious, CKEditor Resizer и некоторых других и нигде нет bootstrap.php которые по 10 раз должны (или могли) бы загружаться, как описано в статье.

Может кто-нибудь привести примеры хотя бы 1 или лучше 2 дополнений, где есть автозагрузка через bootstrap.php, которые потенциально могут сломать друг друга? Мне тема показалась довольно серьезной, хочу проверить!

У Formit такой возможности кажется нет, но уточнить можно, вычитав его код, который отвечает за отправку. Там используется modPHPmailer, который основан на PHPmailer, который в свою учередь почти наверняка умеет подписывать письма с помощью DKIM!

Если этот путь никуда не приведет, придется тебе отказаться от стандартного способа отправки и написать свой небольшой хук (это не сложно, просто сниппет создаешь в котором уже будут заполненны в переменных данные из твоей формы вот документация с примерами), для отправки почты. Тогда, возможно, тебе пригодится знать, что существует modSwiftMailer и возможность отправлять письма с помощью modHelpers. Ну или в своём хуке подключи библиотеку, отправляющую код из PHP с поддержкой DKIM.

Пожалуйста, @Валерий если сможешь подписать письмо без внешнего SMTP, поделись решением! А то недавно Яндекс.Почта, которую последние лет 10 многие использовали как внешний SMTP для отправки писем, отключила бесплатный тариф, и вопрос с почтой стал очень актуальным :))

Если будут вопросы по ходу — задавай!

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

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

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

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

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

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

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

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, желание привнести крутых навороченных штук, не обращая внимания на порог вхождения, естественно) Однако если посмотреть с другой стороны: для вас, крутых разработчиков, и для некоторых других (например, с очень большой натяжкой, для меня, еле догоняющего) это «проект», а для очень многих — инструмент!

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

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

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

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

Вот это да! Ещё не пробовал, но уже очень захотелось! Как и у автора статьи, и у многих думаю здесь читателей, у меня тоже есть пакет базовых настроек сайта.

Буду пробовать собрать на основе moxi мой любымый стэк!

Спасибищще!

Очень крутое обновление! Не смотря на то, что он теперь он не на MODX, а вообще статический (т.е. набор html-файлов и скриптов без классического движка), считаю для документации это отличное решение, к тому же она стала ещё future-proof, как теперь принято говорить, их-за возможности держать локально полнофункциональную копию, что особенно важно в нынешние времена, когда даже stackoverflow иногда перестаёт открываться…

А дополнительные возможности разметки и подсветка синтаксиса MODX + Fenom это просто здорово! Уверен что авторы документации оценят и через какое-то время мы начнем встречать всё больше этих фишек со спец. разметкой даже в привычных разделах!

Старый сайт документации тоже был не плох, но заметно уже устарел. Хотя отмечу, что некоторые моменты на новом заметно отличаются (например навигация по breadcrumbs) и по началу это может быть не привычно. Но в целом стало намного лучше. Большая и впечатляющая работа! Спасибо за неё, и за то, что находите возможным рассматривать обратную связь ;)

Ещё очень здорово, что даже редиректы со старой версии сделали, проверял руками множество ссылок из чата сообщества, битых не нашлось — репект!

есть ли где-то в сети популярное объяснение того, как это работает на примерах.

В анонсах новых версий pdoTools скорее всего найдешь подробности!

А вообще, можешь сам провести тесты, используя параметр &return со значением sql и поймешь как это работает (нужно базовое понимание SQL-запросов, само собой, но для чтения уже написанного это довольно простой язык)

Привет! Google уже пишет в наших аккаунтах, что через ~30 дней отключит сбор данных в счетчиках (потоках данных) которые имеют версии до GA4. Предлагает конвертацию там какую-то и т.п. Короче будущее наступило!

Класс! И без того давно «не по-детски» функциональный минишоп благодаря таким апдейтам добирает ещё более «взрослой» серьезности.

Казалось бы просто сообщения об ошибках, че там… но на рабочих магазинах где заказы и менеджеры «шуршат» ежедневно, банальные сообщения об ошибках способны сохранять комфортно-прохладную температуру там, где раньше подгорали чьи-то кресла в случаях когда «что-то пошло не так, а я ничего не нажимала» :)

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

Спасибо за релиз!

Дамп и сразу архивация, через php shell_exec вот так:

mysqldump -ERv -u[user] -p[password] --databases [db_name] | gzip > dump_name.sql.gz

Но @Илья все равно спасибо что поделился решением!

Насчет лицензии TinyMCE ничего не могу сказать (имхо он намного хуже, не красивый и не удобный), а вот CKEditor есть OpenSource-версия и она под GPL:
ckeditor.com/wysiwyg-editor-open-source/
ckeditor.com/legal/ckeditor-oss-license/

В пакете интеграции для MODX используется 4 версия. Существует ещё 5, но это не старая и новая, а они разные:
А если нужны которые свеже-поддерживаемые то:
• ckeditor4 (https://github.com/ckeditor/ckeditor4) — классический с iframe (пользуюсь 10+ лет, сейчас не стал хуже
и постоянно официально обновляется)
• ckeditor5 (https://github.com/ckeditor/ckeditor5) — новомодный с инлайн HTML5-разметкой без фреймов. Он не так хорошо подходит для интеграции в админку из-за отсутствия изоляции CSS и JS, которую даёт iframe, поэтому 4 версию планирую в пакете так и оставлять

P.S. А удивляться, что популярный OpenSource — продукт на оф. сайте пытаются продать в какой-то премиум упаковке не стоит, им же надо что-то кушать! Короче, этот редактор легально можно использовать бесплатно!