Николай Савин

Эта ошибка может возникать в случае большого, длительного запроса. Серверу Mysql просто не хватает времени обработать запрос. Что за запрос я в вашем случае не понимаю, но предположу, что объем данных, к которым обращаетесь — становится с годами слишком большим.
Возможно пора отрезать старые данные.

Я бы сказал, что твоя проблема в том, что не хочешь сам пошагово разбирать, что пишешь, как устроена работа с файлами в PHP. Проще спросить, чтобы другие думали. А другим это не всегда удобно.
Давай по порядку.
1. В таблицу пишется не абсолютный путь файла, а относительный. Не удивительно, что применяя MODX_ASSETS_PATH ты ничего не находишь. Используй просто /assets/ или если хочешь MODX_ASSETS_URL.
2. Это что за запись такая? Откуда такой синтаксис?

$q->where(array("url" == $this_path));

Правильно будет вот так

$q->where(array("url" => $this_path));

3. Используй getIterator вместо getCollection этот метод потребляет меньше памяти.

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

$source->toArray();

Только это вероятно будет бесполезная распечатка. Потому что здесь идет речь об источнике файлов, а не о передаваемом файле

Для получения входящих переменных можно использовать следующий код

$modx->log(1, print_r(array_keys($scriptProperties), 1));

В msGallery и ms2Gallery никаких событий нет, и не предвидится.
По простой причине — они сами по себе никак файлами не управляют, не загружают, и даже не знают, где эти файлы лежат по сути.
Они только обрабатывают входящие команды и передают массив данных загрузчику MODX, который в свою очередь передает команду на загрузку (или другие операции) источнику файлов.
Источник файлов может быть разным, не только локальным. К примеру на какой-нибудь S3 Amazon загружать.

Вывод — пользоваться встроенными событиями на загрузку MODX.

Боюсь ошибиться, но как будто бы да — PHP тут бессилен, он ожидает имя файла с собственно именем.

А какая разница. И в плагинах и в консоли один и тот же PHP интерпретатор

Ниже написано готовое решение

IF на MODX3 — звучит как анекдот

Сайты должны быть изолированными друг от друга. Вот и вся уязвимость

Уже найден

На всякий случай уточню. Минишоп не назначает другой class_key по умолчанию.
В вашем случае — скорее всего постарались чьи то умелые руки.

Василий вам решал любые ваши задачи по требованию?

Бро, ну это ж платные компоненты. У них есть владелец, есть служба техподдержки. Они не принадлежат сообществу. Мы не можем их адаптировать. Речь идет о бесплатных компонентах.

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

Это превосходная идея. Призываю всех, кто меня знает поддержать подобный сбор. Давайте создадим прецедент. Уверен, Если получится перевести один компонент на MODX3 — то до конца года еще десяток компонентов получат вторую жизнь на обновленной платформе.

По рукам, мой контакт у тебя есть, не стесняйся

Ну за донатик я тебе прям готовый код напишу ))

Навскидку, без реального кейса под рукой.
Я бы написал плагин на событие msOnGetOrderCost
Схема плагина будет вот такого примерно вида

if ($cost < 7000) {return true;}
// тут проверяю состав корзины, не лежит ли уже подарок там
$cartArr = $cart->get();
foreach($cartArr as $row) {
    // Если уже есть подарок выходим 
    return true;
}
// если дошли сюда пора добавлять подарок
$cart->add($id);

Ужас ))
Правильнее плагином это делать внутри MODX.