Сергей Шлоков

Как по мне, чересчур громоздко. Логика с date и start/end не очевидна. Да и в коде слишком много лишней логики. Я бы предложил вариант с датой и длительностью (просто в целях разминки полушарий)

$date = $modx->getOption('date', $scriptProperties, '');
$duration = $modx->getOption('duration', $scriptProperties, '1');
$chunk = $modx->getOption('tpl', $scriptProperties, '');

if (empty($date) || empty($chunk)) {
  return '';
}

[$day, $month, $year] = sscanf($date, "%d.%d.%d");
$year ??= date('Y');
$date = "$day.$month.$year";

$currentTimestamp = time();
$startTimestamp = strtotime($date);
$endTimestamp = strtotime($date . " + $duration days");

if ($currentTimestamp >= $startTimestamp && $currentTimestamp < $endTimestamp) {
  $pdoTools = $modx->getService('pdoTools');
  return $pdoTools->getChunk($chunk);
}

Указал год — сработает только для него. Не указал, ежегодно. Если длительность не указана, то она равна 1 дню.

Вообще очень правильный вопрос.

Загружаем конфиги из файлов

Оперативно. На ум приходит только старый анекдот:
— Скажите, больной перед смертью потел?
— Да.
— Это хорошо.

Если сказать, что с такими мейнтейнерами как Джейсон, MODX будет загибаться быстрее, чем без них, то это будет уже миллионное повторение. Он потушил энтузиазм многих активных модыксеров, которые в итоге перешли в другие лагеря разработки.

Я в своё время его спросил, нафига добавлять контейнер Pimple, разработка и поддержка которого прекращена? Почему не взять развивающийся и более навороченный PHP-DI? Насколько я помню, он ответил какую-то чушь в стиле — зато легкая, а нам больше и не нужно. Даже Марк тогда присоединился к моему вопросу. Но Джейсон сказал, что переделывать он ничего не будет. Это было ещё до выпуска релиза MODX3, когда можно было хорошо почистить легаси.

Отличный пример как делать нельзя. Это максимально жесткий сценарий оверхеда нагрузки.
Подробности описаны мной тут.

Можно так.

Для этого используют брокеры сообщений. Kafka, RabbitMQ и т.п.

Но тут есть важный аспект — развиваться как фрилансер или как наемный работник. Прокачаться полноценно можно только в более менее развитой компании с современной инфраструктурой. Это моё личное мнение. Изучить Spiral в качестве повышения скила будет полезно, но применить его (фреймворк) в компании вряд ли получится. Ибо я как техлид не взял бы этот инструмент из-за одной простой причины — очень сложно найти разработчиков под него и усложняет дальнейшую поддержку. Да и как заказчик не стал бы заказывать свой проект у фрилансера на Spiral. Именно по той же причине — проблемы в дальнейшей поддержке. Хотя я этот фреймворк пробовал и мне он понравился. Но с практической точки зрения ему нет применения.
Поэтому я бы советовал смотреть вакансии в интересных компаниях и прокачивал бы соответствующие скилы.
Это чисто моё мнение.

AjaxForm на стреройдах

Наверно, имелось ввиду «на стероидах»?

Будешь проезжать Пашу дёрни )

Давай попробую через аналогии.
MODX — это поезд. Для простого сайта хватит пары вагонов. Нужно просто завести его и он поедет. И ехать он будет достаточно быстро. Если нужна дополнительная функциональность — добавляешь вагоны. Чем больше вагонов, тем тяжелее поезду. Зафиксируем: MODX — это транспорт.

Laravel — это завод по изготовлению транспорта. Ты можешь сам сделать любой нужный транспорт под свою задачу. Хочешь самолет, хочешь гоночную машину, хочешь тот же поезд, но с 3-мя локомотивами, блэкджеком и плюшками.
Соответственно нужны другие знания. Это другой уровень. Но сразу сесть и поехать ты не сможешь. Придётся попотеть и приложить все усилия, чтобы не получился велосипед на камазовских покрышках или гоночная машина с квадратными колёсами.

А если без аналогии. На Laravel можно написать любую CMS (в том числе и MODX). Обратное невозможно.

П.С. ZoomX позволяет сделать окна в поезде отрывающимися, чтобы ехать было более комфортно, чтобы дышать стало чуть свободнее. Но переделать поезд в самолёт он не может.

П.П.С. Лично я не вижу в ближайшем будущем предпосылок отказа от CMS. Их доля будет неуклонно падать из-за того, что появляются другие инструменты. Но полного отказа от них не будет. Это очень удобный инструмент для быстрой разработки сайтов.

Терпения тебе там в лесу. Модыксер на докере не скоро проедет. )))

Фронтов набирают. Vue/Nuxt уровня мидл и выше.

А ты ишу писал? Нет ишу — нет проблемы! )

Есть. И я мог бы там спокойно, без оглядки на ворчунов, пописывать статейки про kubernetes, helm, werf. Но… если ты заметил, у меня и на него нет времени. (

Я могу сравнить только с теми, которые знаю — wordpress, joomla, битрикс. MODX проще. Но под капот лучше не заглядывать, чтоб не расстраиваться.

Ничего я не покинул. Просто физически времени не хватает. А писать не про MODX тут приравнивается к богохульству. )

Лично я против того, чтобы на портале посвященному MODX писали о том, что с MODX не связано.

А я нет. Не вижу ничего плохого в том, что к нам зайдет какой-нибудь nodejs разработчик и узнает о существовании MODX. )

Для несложный сайтов конечно лучше CMS. MODX одна из лучших. У него только одна беда — он не развивается. У нас в компании есть проекты на MODX и на Битрикс. По сравнению с последним MODX — это глоток чистого воздуха.