Hetzerok

Отличный ответ, главное плюсов много. Не нравится что-то — не используй. А зачем тогда это все, зачем обсуждения, зачем доработки?

Ну не совсем так конечно, но composer это уже большой шаг в нужном направлении.

Круто что серьезная работа работа началась, однако те вещи, которые были названы в начале (проблемы XPDO, отсутствие файловых элементов, extJS и т.д.) это краеугольные камни MODX. Получается что если отказаться от XPDO например в следующем релизе, то это минимум MODX4, а вероятнее этого не произойдет никогда. Между тем это не то что нужно уже сейчас, а нужно было вчера.
Проблема MODX не в том что он плох, а в том что он стремительно устаревает на уровне своих принципов. Да что говорить — автозагрузка классов в современном виде фишка 2009 года, а в MODX у нас loadClass бессменный.

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

Ещё момент, поскольку вы недавно начали заниматься программированием может быть вам будет это полезно хотя вещь то банальная.
В первую очередь стоит изучить принципы на которых строится технология, тогда будет гораздо проще работать с чем то новым, но основанным на тех же принципах.
Например ООП — независимо от языка принципы полиморфизма, инкапсуляции и наследования остаются неизменными, так остается разница только в синтаксисе. Да и синтаксис современных языков практически идентичен, а уж посмотреть какие функции существуют — всегда есть документация.
Зная алгоритмы вы уже будете знать как решается задача — все что останется это подсмотреть как записать решение с помощью нужного языка.
Зная как устроены РСУБД для вас не будет принципиальной разницы в том MySQL это Postgres или MsSQL.

Глюка нет. Таково стандартное поведение MODX, не знаю уж по каким причинам — может экономия места)

Ну вот, оказывается проблема совсем другого рода. Дело в работодателе а не в неправильном развитии индустрии)

Ну зоопарк технологий плодится по многим причинам. Есть конечно и веяния моды и желание идти в ногу со временем, но по большей части что-то новое появляется тогда когда в старом не хватает функционала или находится другой путь, кажущийся создателю более логичным и удобным.
Что касается человека который будет работать уже с этими технологиями то почему бы не выбрать что-то одно и не работать с ним, так сказать увеличивать глубину а не ширину знаний. Например у вас в списке 6 cms — смысл знать их все? Sass, Less — это одно и то же под разным соусом, только PostCss не хватает. Phenom, Smarty (ещё куча есть шаблонизаторов и для PHP и для JS) — почему не работать с одним? Laravel и Symfony — какую задачу можно решить на одном фреймворке и нельзя на другом? И это вы ещё не окунулись в волшебный мир фронтенда — вот где разнообразие так разнообразие.
Смысл такой: большая часть элементов вашего списка дублирует друг друга, так что можете смело от них отказаться)

Добавьтесь в скайп hetzer_tmb — попробую помочь.

Да вроде все верно. А в лимит упираться не может?

Покажите код шаблонов.

Может подход и не верный стратегически, но я бы сделал так — взял GalleryAlbums, скопировал его код в другой сниппет, скажем GalleryAlbumsFenom и в месте рендера шаблонов использовал

$pdoFetch->parseChunk()

вместо

$modx->parseChunk()

, предварительно подключив pdoTools.

Ну на оффсайте написано

4.1.20 or newer excludes version 5.0.51

— то есть работает со всем выше 5.5 тоже.

Вообще интересная подача: «Я знаю что MODX не работает с MySQL 5.5», а потом «Я не в курсе что поддерживает MODX». docs.modx.com/revolution/2.x/getting-started/server-requirements — как бы официальный список системных требований.

По умолчанию отправляет через mail(), однако может отправлять и через SMTP — нужно проверить системные настройки почты.
В качестве хука email выступает метод email() класса fiHooks. Расположен он в файле formit/model/formit/fihooks.class.php.

Почему кинуть, разговор же идет не о прекращении поддержки 2.x, а о том что будет в 3.x. Вон Evolution до сих пор существует и пользуется заслуженной любовью у многих разработчиков.

Вот ещё скажу может быть крамольную мысль — MODX не повредил бы отказ от XPDO в его существующем виде. В него запихано все что возможно и ORM и валидация и загрузка нлассов и т.д. Чтобы соответствовать современным требованиям нужно это разделять.

Так в первую очередь нужен план действий какой-то — четкое понимание «Мы хотим видеть MODX таким-то», а уж к этому нужно прикладывать усилия разработчиков. Пока что, как я понимаю, такого плана нет — не ясно даже будет ли в следующей версии кардинальное обновление или продолжится процесс эволюции.

Да безусловно MODX нуждается в глобальной модернизации. Технологии как и тренды не стоят на месте, а основой движка остается кодовая база 2010 года.
На мой взгляд как разработчика необходимы следующие изменения:
— Поддержка PSR стандартов и все что с этим связано (неймспейсы, автозагрузка, composer)
— Полноценный шаблонизатор из коробки (не важно smarty, fenom, twig или ещё что-то)
— Отделение кодовой части от БД, что позволит нормально пользоваться системами контроля версий, а не изобретать велосипед.
— Отказ от ExtJS в админке и переход на один из современных JS фреймворков.
— Слабосвязанная архитектура, чтобы любую часть системы можно было легко заменить.
— CLI приложение для типовых задач (парсинг схемы, создание базы компонента и т.д.)

Как я понимаю нужно отталкиваться от визуального редактора — посмотрите имеет ли он возможность создавать кастомные вставки и если имеет то насколько сложно делать. А уж там дело техники.