Евгений Дурягин

Где вызываете $modx->setOption('cache_resource_key', 'resource/pjax'), так же как и в примере в плагине на OnWebPageInit?
Проверил — в кэше обе папки core/cache/resource/web/resources/ и core/cache/resource/pjax/web/resources/

У getPage и pdoPage есть параметр cache_key, в котором указывается ключ кэширования. Но по умолчанию берется из настройки cache_resource_key, которая заранее и меняется через setOption. Т.е. оба сниппета должны автоматом разделять кэш.

Для первого пункта есть ClientConfig modx.com/extras/package/clientconfig

В MODX обновления файлов происходит распаковкой из архива ручками.
Поэтому если сам не проконтролируешь какие файлы перезаписывать из архива — все затрется.

А выход есть, можно, например, расширить класс пользователя и сделать связь со своей таблицей дополнительных аттрибутов.

И при следующем обновлении MODX это все затрется…

Проще присваивать аватар в плагине на событии OnUserFormSave или OnBeforeUserFormSave

Еще может в настройках MySQL. Например, что указано в sql mode в PHPMyAdmin на вкладке «Переменные».
Похоже что установлен strict режим.

Но схему перегенерировать все равно придется перед добавлением поля, заккоментировав $manager->removeObjectContainer() и $manager->createObjectContainer()

Можно $manager->addField('className', 'fieldName');

Раз в ошибке указывается что ему нужны id и secret, то и в настройках надо указать id и secret, а не key.
Т.е. параметр должен быть

{"id":"","secret":""}

Насколько понял тут предлагается размещать на сайте картинку, которая указывает на специальный PHP скрипт.
А он уже сверяется со временем запуска скриптов и запускает их
Если это так, то не рекомендую так делать.
1. У посетителей будет лишняя картинка, которая может грузится очень долго, если операция долгая
2. Непрогнозируемое время запуска. Бэкапы должны запускаться ночью, а вдруг ночью никто на сайт не зашел?

У setcronjob тоже есть бесплатный тариф.
Да и совсем не то. Мониторинг сервера и сервис крона все-таки разные вещи. Можно конечно приспособить мониторинг под крон (если вообще в мониторинге есть возможность указать произвольный URL, а не просто сайт) и и то получиться скорей всего только на платном тарифе, т.к. на бесплатном отправляется HEAD, но специальный сервис для крона гибче, даже на бесплатном тарифе.

Можно воспользоваться любым внешним cron, который запускает процессы по URL.
Например www.setcronjob.com/
Тарифа 10$ в год хватит чтобы запускать процесс хоть каждые 15 минут.
Есть и бесплатный тариф, его хватит чтобы запускать 1 процесс раз в сутки.
Но ограничено время в 15 секунд (скрипт все равно отработает, но будет считаться ошибочным и результата не видно) и тариф нужно раз в месяц подтверждать.

Закрыли передачу параметров через POST при получении access_token
Pull Request отправил

При изменении ресурса нужно передавать еще

'tvs' => true

Это вроде из-за того что MODX по умолчанию использует пользовательский обработчик для сессии и при завершении PHP он разрушается раньше, чем успевают записаться последние изменения в сессии, которые APC видимо кэширует.
Попробуйте создать плагин на событие OnInitCulture

<?php
register_shutdown_function('session_write_close');

OnInitCulture конечно не совсем подходящее событие, но оно просто единственное, которое выполняется всегда, даже если MODX в API режиме. По крайней мере на MODXCloud это помогло.

За это отвечает параметр tvs_below_content в настройках системы, но это глобальная настройка для всех ресурсов. А редактор убрать можно через Form Customization

Если в настройках tickets.default_template установить в 0 (Tickets должны быть версии 0.9.3 и выше) стандартный Form Customization шаблон меняет без проблем. По идее должно и плагином.

$ps = $modx->getObject('modPropertySet',array("name"=>"Имя_параметров"));
$params = array_merge($ps->getProperties(),array(
  'element'=>'getResources'
  ,'limit' => 50
));
$modx->runSnippet('getPage', $params);

Создать один или несколько источников файлов, дать права на использование только этих источников.

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