Все-таки не минуя index.php, но из-за того, что включен режим API (MODX_API_MODE), плагины действительно не сработают.

Вы знаете вы ввергли меня в сомнения)
Попробовал, и выяснил, включен или нет API — не имеет значения плагин не срабатывает, если напрямую обращаться, например, к assets/components/fetchit/action.php

У компонентов FetchIt AjaxForm нет обновлений уже очень давно.

У меня есть идея использовать настройку auto_prepend_file в php.ini. Тогда не нужно будет править исходники. Не знаю стоит ли реализовывать и как это скажется на производительности.

Вся экосистема PageBlocks вызывает огромное впечатление

Может там есть смысл сделать фильтр и сохранять локальный?

if (!filter_var($ip, FILTER_VALIDATE_IP)) {	
		return '127.0.0.1';
	}

Ветвления есть?

Красота!

Как ты подключаешь бота к RSS каналу?

Подскажите компонент умеет из коробки импортировать товары и фото из архива?
У нас 1С будет загружать на сайт архив с таблицей с товарами и фото.
Планируется, что в настройках импорта я укажу путь к архиву. А после импорта этот архив будет удаляться компонентом.

Такой вариант возможен, или данные должны быть распакованы и указан путь к файлу с товарами?

{'list__items' | resource | split:"||"}

Вот тебе решение, тут я использую сниппет phpThumbOn и проверяю файлы которые весят более 1мб и делаю ресайз по ширине 1024px, создай файл в корне сайта msproducts_resizer.php и запусти его, в журнале все сообщения!

<?php
// Ресайзер оригиналов изображений msProduct по быстрому
// Определяем режим API MODX
define('MODX_API_MODE', true);
require 'index.php';

// Инициализация MODX
/** @var modX $modx */
$modx->getService('error', 'error.modError');
$modx->setLogLevel(modX::LOG_LEVEL_FATAL);
$modx->setLogTarget(XPDO_CLI_MODE ? 'ECHO' : 'HTML');

// Путь к папке с продуктами
$basePath = MODX_BASE_PATH . 'assets/images/products/';

// Размер файла в байтах (1 МБ = 1048576 байт)
$maxFileSize = 1048576;

// Максимальная ширина после ресайза
$maxWidth = 1024;

// Логика поиска и ресайза изображений
function resizeImagesWithPhpThumb($basePath, $maxFileSize, $maxWidth)
{
    global $modx;

    // Получаем список всех подпапок в директории products
    $directories = glob($basePath . '*', GLOB_ONLYDIR);

    foreach ($directories as $dir) {
        // Получаем все файлы изображений в текущей подпапке
        $images = glob($dir . '/*.{jpg,jpeg,png,gif}', GLOB_BRACE);

        foreach ($images as $imagePath) {
            // Проверяем размер файла
            if (filesize($imagePath) > $maxFileSize) {
                try {
                    // Генерируем URL для ресайза с помощью phpThumbOn
                    $relativePath = str_replace(MODX_BASE_PATH, '', $imagePath); // Относительный путь
                    $thumbUrl = $modx->runSnippet('phpThumbOn', [
                        'input' => $relativePath,
                        'options' => "w={$maxWidth}&zc=1", // Ширина 1024px, сохранение пропорций
                    ]);

                    // Путь к новому изображению
                    $newImagePath = MODX_BASE_PATH . ltrim($thumbUrl, '/');

                    // Заменяем оригинальное изображение на новое
                    if (file_exists($newImagePath)) {
                        unlink($imagePath); // Удаляем старое изображение
                        rename($newImagePath, $imagePath); // Переименовываем новое изображение
                    }

                    // Логируем успешное изменение
                    $modx->log(modX::LOG_LEVEL_INFO, "Изображение {$imagePath} успешно изменено.");
                } catch (\Exception $e) {
                    // Логируем ошибку при обработке изображения
                    $modx->log(modX::LOG_LEVEL_ERROR, "Ошибка при обработке изображения {$imagePath}: " . $e->getMessage());
                }
            } else {
                // Логируем, если размер файла меньше порогового значения
                $modx->log(modX::LOG_LEVEL_INFO, "Изображение {$imagePath} меньше 1 МБ, пропускаем.");
            }
        }
    }
}

// Запуск логики
resizeImagesWithPhpThumb($basePath, $maxFileSize, $maxWidth);

Наверно сначала выполняется [[~[[+vendor.resource]]]], т к это не fenom, а потом проверяется условие…
сделал так

[[+vendor.resource:gt=`0`:then=`href="[[~[[+vendor.resource:default=`1`]]]]"`]]>[[!+vendor.name]]</a>

. Может более правильное решение?

Я ставил css файле — form .smart-captcha {height: 102px !important;}
Нормально работает, эти стили не перебивались.

Еще обнаружил странный баг в модальном окне на fancybox. Если стоит такой стиль на внешнем контейнере .modal {width: 100%;}, то бегунок капчи двигается но проверка не происходит и он снова сбрасывается в начало. Заменил параметр на «width: auto;» и все заработало.

С чем может быть связано появление 500 ошибки Call to a member function getClientIp() on null после отправки формы (в итоге не отправляется)?

К сожалению, нет. Хотя там сейчас есть новая версия, возможно это пофиксили. Как предположение у меня js не был закрыт ;. Сейчас обновил, проверил, вроде работает корректно. 1.0.3 версия.

Безусловно, использование Git является золотым стандартом в современной разработке.
Позвольте я объясню, почему IskFileGuardian является не заменой, а дополнением к таким практикам, и для кого он предназначен в первую очередь.
IskFileGuardian создан для другой аудитории и решает несколько иные задачи:
MODX часто используют менеджеры контента, владельцы малого бизнеса, веб-мастера, которые не работают с Git и не имеют SSH-доступа к серверу. Из собственного опыта скажу, многие не закрывают даже доступ к папке /core/ — типа и так сойдет.
Компонент предоставляет им интуитивно понятный интерфейс прямо в админке MODX, не требуя технических навыков.

Скрипт с git status требует настроенного Git на сервере и прав на его выполнение через cron.
Мой компонент работает на любом шаред-хостинге, где есть PHP и MODX.
Git — это инструмент для разработчика на этапе разработки и деплоя.
IskFileGuardian — это инструмент для администратора/владельца сайта на этапе эксплуатации и мониторинга безопасности. Это разные плоскости применения.

Команда git status отслеживает изменения только в файлах, которые индексируются Git. Она целенаправленно игнорирует все, что указано в файле .gitignore. Что обычно находится в .gitignore на проекте MODX?
Кэш (/core/cache/)
Загружаемые пользователями файлы (/assets/uploads/, /images/)
Логи и сессии
Иногда — папки с компонентами, установленными из репозитория MODX.

Хацкер, получивший доступ к сайту, с вероятностью 99% загрузит веб-шелл или бэкдор именно в одну из этих папок. git status никогда не покажет этот новый файл.

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

Для этого git на проде должен быть + весь код проекта должен в нём хранится. А во многих проектах git или нет вообще или только часть кода в нём.