Нет, это для админки, у меня для фронта.

это дополнение разве не тоже самое уже реализует?

В mSearch2 можно добавить синонимы запросам.

Изобрел — пока статью писал.

Классный хак с повторным вызовом FormIT и пробросом туда параметров из задания через $_POST, очень элегантно!

Мне вот на подобие этого нужно было как-то вызывать хук для формита с API-вызовами к внешнему сервису но без отправки формы, так пришлось его код копировать и в сниппет выносить, а стоило сделать вот так как в заметке сделан сниппет send_email, чтобы не дублировать код и не поддерживать потом 2 версии…

К стати дополню список — в AjaxFormitLogin этот метод тоже будет работать

Так-то это не ошибка, а предупреждение.

На PHP версии 8 выдает ошибку
/home/s32719/www/core/components/translitor/model/translitor.class.php 188
PHP warning: Undefined array key «ru»

Шаблоны нужно ДОвёртывать, а сборку ДОнастраивать, за счет этого и экономия. Обязательно напишите отзыв как протестируете)

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

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

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

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

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

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

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

1. pdoTools
2. Collections
3. Tagger
4. SimpleSearch
5. FormIt
6. SeoSuite
7. Formalicious
8. GoogleAnalytics
9. ModxDashboardWidgetsPack
10. QRNFCGenerator

Это те, что на вскидку вспомнил, потому что работал с ними недавно. Если покопаться, найдутся еще.

Таких пакетов уже довольно много, хоть бы и новый pdoTools. Видишь, здесь грузится свой собственный autoload.php, который может содержать любые зависимости?

Теперь представь, что так может делать любое дополнение в MODX 3. Кто-то будет тестировать свой пакет на совместимость со всеми остальными в репозитории? Очень сомневаюсь.

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

Это есть и во 2й версии, просто там этот шанс гораздо ниже, но отнюдь не нулевой.

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

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

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

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

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

Автозагрузка обычно через Autoload.php происходит. Я вот тоже не разу ни встречал bootstrap.php.
А так композерных пакетов внутри MODX с наличием composer.json сколько угодно. ZoomX, modRetailCRM, HibrydAuth навскидку

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

Да и на 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, там они почти доделали уже, с переводами встряли что-то)

Сколько вы в этом году задонатили сообществу, чтобы адаптация того же MiniShop2 с 2 на 3 шла активнее? Или сколько PR отправили, чтобы помочь с адаптацией? Давайте угадаю — нисколько. И не смотря на это, работа идёт. Более того, pdoTools, FetchIt и MigX уже адаптированы, а этим набором можно очень много всякого реализовать.
А 4-ю версию ждать в ближайшее время и правда не стоит, но Modx ещё поживёт.

Да я одно понял, читая заметки, что основные знаменитые модули/сниппеты из маркета у ребят нет особого желания нормально допиливать с 2 на 3, так как не видят смысла и профита в этом. А ждать 4 версию в обозримом будущем не скоро, т.к. западные мейнтэйнеры уже старые, ленивые пердуны без особых идей и молодого запала, которым особо своё детище похоже не интересно. Да и на 2ке новые проекты делать уже такое себе занятие, конечно можно, так как уже все проверенно временем и стабильно работает. Кончился похоже modx.

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

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

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

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

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

Создайте плагин на событие OnDocFormSave. В нем получаете контент ресурса, находите таблицу, оборачиваете ее в div и соответственно задаете новое значение полю content ресурса. В БД в таблице modx_site_content будет с дивом