Іван Клімчук

Нет, не стоит. Вернее какие-то моменты не мешало бы, да, вроде того же обновления. Но AutoTemplate — частный случай, что делать, если мне нужно наоборот? Ставить AntiAutoTemplate? filetranslit вероятно, хотя тоже спорно.
minifyHTML, minifyx — однозначно мимо, потому что это не ворпрес, где все уже сделали за тебя, сиди пиши свои мнения на весь мир. Кто-то может вообще все собирать с помощью gulp/grunt/webpack, зачем ему тянуть вместе с системой подделие, которое уже пару лет как не поддерживается нормально (движок минификации на php в minifyx).
Установка пакетов за раз вероятно будет когда-то, но там есть свои ньюансы. Но уже сейчас это можно делать с помощью gitify.
В будущих версиях MODX планируется удалить еще больше вещей, которые не являются остро необходимыми для ядра. Сейчас кодовая база самого MODX слишком большая и поддерживать ее в рабочем состоянии довольно затратная задача, при том, что энтузиастов помогать в этом как-то нет. Если все эти хотелки внедрять в ядро, это увеличивает энтропию, а как следствие больше ошибок, больше граничных случаев, запросов от пользователей и прочее, что делает разработку самой системы очень медленно, да и мелкую фичу можно ждать полгода, потому что кроме нее еще десяток крупных, а релизить MODX только ради мелочи — очень затратно. Все же я придерживаюсь принципов бережливого производства, так как они самые адекватные и понятные всем.
Вынесение пользовательких функций в отдельные дополнения выгодно по многим пунктам: даст возможность более плотно работать над ядром системы и быстрее выпускать по настоящему стоящие релизы, не отвлекаясь на поддержку пользовательских функций; отдельные дополнения можно релизить независимо и выпускать патчи и новые возможности намного быстрее, чем релизы ядра; легче привлечь людей в качестве мейнтейнеров на отдельные дополнения, которые будут заниматься только ими и активно их развивать (т.е. делегация полномочий). Надеюсь моих доводов достаточно для понимания текущей ситуации.

Так а вы инструкцию внимательно читали? Сам то он работает, но чтобы автоматически работал, нужно в настройках сервера добавить запуск скрипта «сайт/..../cron.php» непосредственно в cron-обработчик сервера. На каждом хотсинге это может делаться по своему, нужно у своего уже уточнять.

И раз уже fenom, то лучше не мешать синтаксис и вместо [[$Page-parent-content]] использовать {'Page-parent-content' | chunk} или {include 'Page-parent-content'}

сделайте вместо null еще один ?, а null передавайте уже из php.

$data = [null, $user_id, $field['mini'], $field['full'], $field['target'], $field['banks'], 'none', time())];
$q = $modx->prepare("INSERT INTO `users_social` VALUES (?,?,?,?,?,?,?,?)");
$q->execute($data);

Для начала хотелось бы увидеть более четко сформулированный вопрос. Потому то, что у вас в голове, только там и есть. Что означает табы из ресурсов в вашем понимании?

Ну а ссылка зачем? Читайте внимательно.

Адаптивный легче читать, если при этом не теряется смысл, но я не целевая аудитория, читаю в оригинале :)

Какая-то заметка получилась сумбурная. Куча примеров кода без объяснения и, видимо, местами без понимания всего процесса. Но начало хорошее, стоит поглубже разобраться и дело пойдет.

Проверьте настройки мыши у себя в системе, может кнопка переопределена и какой-то другой код возвращает или может плагин какой стоит. Тут вариантов может быть много, наверняка сказать сложно.

В любом динамическом дерево ссылки быдут скриптовыми. Но насколько я помню, этот момент исправляли и открыть средней кнопкой в новом окне можно (могу ошибаться, у меня нет колеса на мыши, потому не пользуюсь).

Далеко не 99%, а узость применения только на MySQL как раз и не дает использовать MODX шире, хотя возможности и запросы есть.

Таки SQLSRV который сейчас поддерживается, но используется еще реже, чем postgres, то у последнего больше прав. Касательно хостинга, он тоже бывает разный и не исключено, что есть клиенты, у которых сервисы построены на pgsql, но создать простой сайт рядом они не могут, потому что нужно ставить еще и mysql.

А почему это перебор?