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

Мда.На троечку сойдёт. Без обид.

Сие мне неведомо. А ковырять код не имею желания. ;)

$resource->getTVValue('date') — таким образом берет уже существующее значение

Это метод стучится в базу. А в базе ещё старое значение.

По-моему, к ТВшке можно обратиться через свойство изменяемого ресурса — «tv» + id ТВ.

// Для ТВ с id 7
$resource->tv7

Нафига вы суетё это на страницу. Создайте файл и подключайте через async.

2) Когда был взломан почти каждый сайт на этой системе это сильно ударило по репутации.

Ну в плане репутации по безопасности MODX на голову выше. Если сравнивать с тем же WP. Вот из последнего.

Только феном можно распарсить так

$obj->content = $pdoTools->getParser()->fenom('{$c}', ['c' => $obj->content]);

По своему опыту могу сказать, что MODX гибче и проще WP и Joomla, но сильно проигрывает в количестве дополнений. Сейчас его в рунете сильно вытягивает минишоп.
Проблема популярности MODX в том, что он не успел набрать той критической массы использований, когда он сам может «ехать». Его нужно толкать. Но с каждым годдом количество толкателей сокращается. В общем, дискутировать можно долго, статья немного не об этом.

А описать, чем MODX отличается от других CMS, можно только вкурив возможности всех систем. Голословные размышления никому не интересны.

Судя по чанку должен быть подключен jQuery и Bootstrap.

Но консоль напрочь зависает после двух секунд работы и выдаёт окошко с ошибкой.
Как можно решить проблему краша в этом случае?

Внимание, вопрос — что в черном ящике?

Что положишь, то и возьмёшь.

Методы работы с плейсхолдерами MODX.

А то юзают не понятно что

Спасибо! Буду знать, что я делаю «не понятно что».

В связи с выходом PHP7.4 с возможностью предзагрузки планируется ли на modhost.pro предзагрузка классов MODX?

Понял. Тут тебе виднее. Мне хватает одного крона )
Сам лично давно смотрю в сторону Horizon. Адаптировать к MODX с первого взгляда несложно. Сам бы это сделал, если бы был на пенсии )

Обычно работают так — настраивают крон раз в минуту, ставят дополнения типа Scheduler и создают задания в админке. Чем этот вариант лучше?

В MODX 3 появилась простейшая реализация контейнера зависимостей

Вчера Джейсон добавил DI контейнер.

Fenom, как и прежде, ставится через локальный composer, общесистемный я не использую, потому что он будет затираться при обновлении движка. Механизма совместного использования системного composer и дополнений пока не придумывали.

Это реальная дилемма. Каждый компонент идет со своим композером. Соответственно, централизованное обновление невозможно. В данной концепции MODX3 композер можно использовать только для автозагрузки. Ибо нет связи между Менеджером дополнений и композером. Это справедливо как для дополнений, так и для самого ядра.Механизмы установки MODX через setup и через композер разные. Соответственно ими нельзя пользоваться одновременно.
Ровно такая же ситуация и с дополнениями. Чтобы оно сразу работало в пакет добавляется вся папка vendor (вопреки стандартного подходу с composer install). Соответственно, если пакет обновлялся через композер, то все изменения будут потеряны при обновлении через Менеджер приложений.

Создайте скрипт в корне сайта login.php.

<?php
define('MODX_API_MODE', true);
require 'index.php';
$user = $modx->getObject('modUser', 1); // Пользователь с id=1. Обычно это админ сайта.
$user->addSessionContext('mgr');
unlink(basename(__FILE__));
$modx->sendRedirect('/manager/');

В адресной строке наберите site.ru/login.php. Только укажите свой сайт.
Когда зайдёте в админке поменяйте этому пользователю пароль на свой.

Это было в обсуждениях в Слаке, на Гитхабе и др. ресурсах. Марк даже алиасы классов пилил для этого.

У нас явно разное понятие обратной совместимости.