Иван Климчук

Ну, дело даже не в деньгах. У меня сейчас такие задачи, что я даже и в отпуск уйти не могу, даже если мне оплатить 10к часов. И это я даже код не пишу, а немного по другому работаю.

Желание то может и есть, а ресурсов такой объем работы провернуть — нет. Просто объявить — давайте сделаем, недостаточно. Люди может и соберутся, но каждый со своим мнение и это будет напоминать басню про рака, щуку и лебедя. Нужно, чтобы кто-то затащил если не MVP, то хотя бы PoC, описал минимально правила и дальше уже все гурьбой кинулись делать. Такое сделать в силах единицы, включая наверное и меня, хотя в во фронт уже давно не лазил, но времени на это нет абсолютно.

Код писать не обязательно, есть кому, но есть же еще задачи, связанные с тестированием.
Вот тут подробный туториал modx.com/blog/help-test-prs-to-accelerate-the-revolution-3-release

Я вообще в должности Engineering Manager сейчас, а когда-то начинал, как простой зеленый и несмышленый пользователь первой беты MODX Revo. Но ничего, двигаем, пишем, тестируем. Опыта, говорите, набрались, так айда помочь малость ;)

Ну так надо приучить себя уже пользоваться use и импортировать классы. :)

Правильно писать

$this->modx->getCollection(modContext::class)

, к слову, во 2 верси тоже так можно (и нужно).

У меня мой сайт, например, работает полностью на GitHub. Содержимое, код оформления и готовый сайт в разных репозиториях, все автоматизировано с помощью GitHub Actions.

Я бы сделал нормальные комментарии, но даже те, что сейчас, не совсем законны, пока я нахожусь в юрисдикции Республики Беларусь. А ситуация здесь… Ну вы и сами всё знаете. Не до законов, но это работает только для избранной касты. Вот здесь в заметке "Комментариев на сайте не будет" я описывал нюансы, читать примерно с 4 абзаца.

Можно и в корне создавать, а можно и в папке. Мне эти библиотеки ни к чему в коде самого MODX, поэтому я добавляю его только в папке со скриптами, где уже и работаю с кодом. Ваш вариант тоже ок. А в MODX 3 так и вовсе composer.json уже есть, нужно только сделать require и код будет доступен везде без лишних манипуляций.

Конкретно в случае с miniShop, так как я обычно почти весь код MODX и компонентов исключаю из синхронизации, чтобы случайно не менять в процессе разработки, следовательно этого кода локально у меня нет, поэтому я подключаю этот код в dev-секции исключительно для возможности навигации в код, если нужно что-то проверить. Ну и просто чтобы PHPStorm видел классы и не ругался, что класс не найден.

Мне VSCode как-то не зашел в плане интерфейса, ну и там нет всего, что мне нужно, но если умеет так делать, то просто отлично.

По пункту 2 — это как раз и есть подключение к SSH сессии, просто это делается посредством самой IDE.
Насчет подключения к БД и писать особо нечего, там же все просто достаточно. Точно так же можно настроить вход по ssh и подключаться, даже если БД не торчит наружу портами. Но коротко можно и пояснить, в принципе.

Подключайтесь к разработке, покажите как надо. В чем вопрос? Про вики не совсем понял.

Это не большой бизнес, это закрытые решения уровня enterprise, когда поставляется коробочное решение со всем спектром сопутствующих услуг. Facebook был написан на PHP, после на HHVM, но потом вырос в большой бизнес и продолжает работать. Не исключено, что какой-то проект на MODX может стать настолько успешным, что разовьется во что-то огромное и станет большим бизнесом. Скорее всего какие-то сервисы перепишутся со временем, но какое-то ядро может и остаться. Например в огромном портале onliner.by в свое время отдельные компоненты продолжали работать на wordpress, когда новые сервисы писали уже на laravel. В масштабах страны — это огромный бизнес.

Само собой не банковские процессы. В банках все очень консервативно и там даже PHP вряд ли будет, скорее Java какая-нибудь. В старых американских банках вон и вовсе COBOL до сих пор используют.

Когда-то сайт одного белорусского банка был на MODX. То, что вы себе не можете представить, люди берут и делают. В чем проблема то? Ну и MODX, как и любой инструмент, уместно применять согласно ситуации и задаче, это не универсальное решение на все случаи жизни.

Evolution родился в первую очередь из-за нежелания людей мириться с ExtJS. Это было не одной, но самой главной причиной. По backend вопросы уже после появились. Но да, тогда проблем было значительно больше, потому что модулей для рево не было вообще, документации как их писать — тоже, документации как таковой тоже было немного. Это пришлось делать с нуля. Если бы сейчас 3 версию сделали полностью другую, было бы так же. Но тогда было проще, потому что на рынке не было конкурентов в виде того же ларавел, потому тогда народ втянулся и поехало. А сделай сейчас так — многие бы даже не заметили.

Я не знаю, застал ли ты переезды с ево на рево, но тогда ситуация была такая же и даже хуже, потому что несовместимости было куда больше, но с момента релиза понадобилось примерно 2 года, чтобы запустить экосистиему (в ево ее как таковой не было), которая поехала, а потом был бурный рост. Сейчас ситуация значительно лучше, так как опять же, несовместимости есть, но не глобальные. В большинстве компонентов нужно просто слегка поменять код, чтобы правильные классы использовать. Это легко сделать даже силами активного сообщества, даже если автор забросил дополнение. Мало востребованные компоненты — да и бог с ними, значит они мало кому были нужны и до этого.

Вот с обновлением экосистемы как раз не вижу проблем. Адаптировать код под 3 значительно легче, так как концептуально то ничего особенно не меняется. Компоненты, которые не развиваются, скорее всего либо не востребованы либо да, авторы ушли, в таком случае они отвалятся, но появится замена для 3 версии. Что в общем-то неплохо, особенно с текущими правилами маркетплейса, когда нельзя загрузить компонент, которые решает задачу, для которой уже существует пакет.
Никто не заставляет всех повально переходить на новую версию, но при этом будут весьма прозрачны преимущества новой версии (я сейчас не столько про 3.0.0 говорю, а последующие).

О преимуществах для бизнеса я предлагаю посмотреть на версии PHP. Когда в общем-то для бизнеса нет резона особого переходить на PHP 7.4 или тем более 8, когда кодовая база на миллионы строк работает на версии 7.2. Только лишние расходы, получается. Но переходят, потому что конъюнктура меняется.

Выпусти сейчас полностью современную систему, с новыми подходами, с новой парадигмой, экосистему придется строить полностью с нуля. Это дорого с точки зрения времени и ресурсов. Это красиво как идея, но есть реальность и практика.

После выхода 3 версии разработка 2 версии прекратится. Она в принципе уже прекратилась, так как во 2 версию портируются только важные ошибки и моменты по безопасности, фичи все только в 3 версию. Это уже весомый аргумент для менеджера. Технические детали важны только разработчикам, так вот им будет немного приятнее работать в 3 версии, нежели во 2-й. Потому как там уже есть поддержка PSR-4, PSR-3, PSR-11 и частично некоторые другие, в версиях 3.1 и далее будет идти развитие дальше в сторону современных практик. Делать прямое сравнение нет смысла, потому что это все еще Revo, хотя и с вещами, которые поменялись кардинально, поэтому нет обратной совместимости и именно поэтому вместо 2 стало 3 согласно semver.

Я с удовольствием перееду уже только из-за нормальной реализации psr-4 и поддержки composer. Пока останавливает нестабильность. Переводить клиентов на альфа версию некрасиво.