Василий Наумкин

league/glide — отличная штука, использую с самого начала Vesp, уже несколько лет.

Но на высоконагруженных проектах столкнулся с проблемой, что когда юзер создаёт новый коммент с картинкой, а другие видят это через вебсокеты, то сразу генерируют сотни запросов на конвертацию. Так как нет никакого механизма ограничения конкурентных запросов при холодном кэше, мы получим или кучу 500-х ошибок, или подвисший сервер.

Решаю это добавлением Varnish для запросов на картинки — он пропускает только 1 запрос на конвертацию, а всем остальным в очереди раздаёт уже результат из кэша.

Да, конечно. Разве что кроме архива core.transport.zip.

Смысл же в том, чтобы сравнить свои файлы с эталонными на предмет изменений. Файлы ядра меняться не должны.

Да для всех, какие есть в дистрибутиве — лишнего-то там быть ничего не должно, по идее.

В идеале вообще автоматизировать и качать всё новое бесплатное из репозитория MODX / modstore, распаковывать и забивать в БД:
— название: MODX или дополнение
— версия дистрибутива
— путь к файлу
— sha1 хэш файла

Насколько я вижу из кода, скрипт в первый раз сохраняет хэши файлов, а потом их проверяет. Но если сайт уже заражён — то это никак не поможет.

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

То есть, берём оригинальные файлы index.php в connectors, manager и корне, а так же файлы из core — и проверяем, чтобы все они присутствовали на сайте с оригинальным хэшем.

Если все основные файлы не изменены, то сайт не заражён и должен работать корректно.

Правда, есть еще возможность заражения только файлов дополнений, без ядра. Наверное, можно и их сверять с дистрибутивами из репозитория по той же логике — скачать нужную версию и сравнить хэши…

Кстати, вот вам еще идея — создать онлайн базу для проверки хэшей файлов MODX и дополнений через API. Чтобы простые GET запросы, типа /api/hash/modx/2.8.1/core/model/modx.class.php возвращали sha1 хэш запрошенного файла или 404.

Конечно, это не спасёт от уже залитых шеллов и вредоносов, но они не будут запускаться через сайт. А если запустятся и что-то изменят, то следующая проверка это покажет. И если раз за разом файлы будут меняться — то можно уже более внимательно искать, что там такое у вас залито.

На всякий случай вкину ссылку на репо с miniShop3 который я переделал под Composer как-то раз на досуге — github.com/bezumkin/MiniShop3/

Это чисто proof of concept, для реальной работы не предназначено, просто доказательство возможности такой работы.

Никого ни к чему не призываю, просто для информации.

А планируется что-то типа ZoomX на modx 3?

Нет, я ничего такого не планирую.

Но в некоторых mmx-приложениях используется vesp/core для работы API, а у него внутри slim/slim — так что за фреймворками далеко ходить не надо, всё уже под рукой.

В Eloquent же всё интуитивно понятно)

Согласен!

После работы с ним к xPDO возвращаться нет никакого желания. Да и смысла нет.

Всё, чему ты научишься в xPDO за пределами MODX никому не надо. Eloquent для разработчика гораздо полезнее.

Это несложно, если процесс разработки хорошо отлажен и тебе ничего не мешает.

modx.pro/components/24619

Так ты сделай нормальное composer дополнение для MODX — и пусть его себе ставит кто хочет, вместе с остальными mmx-дополнениями. Древний транспортный пакет тут совсем ни к чему.

Есть же заготовка — просто используй.

Незнаю, может это не стоит считать проблемой, и вы и не планировали, что файлы в директории modx нуждаются в редактировании, но все же…

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

Я для себя решил эту проблему тем, что описывая докерфайл создаю там сразу нерутового пользователя и запускаю контнейнер от его имени. В таком случае файлы, созданные от имени этого пользователя монтируются «наружу» с именем пользователя на хостовой системе, что очень удобно.

А я использую в production образы и хост одной и той же системы — Ubuntu (Debian), поэтому всё работает от одного юзера www-data. А на локальной MacOS проблемы с правами и вовсе нет.

Ну а кстати, зачем я вообще полез править файлы в modx. Админка тупо выдает белый экран. Главная страница сайта открывается, а никакие танцы с бубнами вокруг админки пока не помогли.

Скорее всего, MODX просто не может создать директорию с кэшем из-за прав, да.

Решил ознакомится поближе, вижу вы активно снимаете и выкладываете видео на канале, а это очень подкупает.

Спасибо на добром слове, планирую продолжать!

Да, там был полный бардак с датами — сейчас привёл в порядок и написал тесты для проверки.

Обновляйся на версию 1.2.1

Composer — это главная фишка MODX 3, которую никто не использует.

Если установлены через composer, то да, будет автозагрузка.

Судя по коду ты их просто положил в namespace MODX, так что да, так тоже работает.

Лично я терпеть не могу фасады Laravel, и это одна из основных причин, почему мы с ним не сработались.

Дело в том, что при переходе в addModifier здесь, мы попадём в фасад, а не в класс \Fenom, где этот метод и объявлен:

И это жутко бесит, когда пытаешь проследить логику работы.

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

По моему, это гораздо проще и удобнее, чем городить фасады.

Но, в любом случае, спасибо за заметку. Кому-то, может, такое наоборот удобнее.

Я же выше объяснил, что происходит.

Ничего удалять не надо, просто добавляешь разрешение менять версии уже установленных пакетов ключом -W, что означает --with-all-dependencies.

Это не ошибка, там нет никаких ошибок. Он просто не может разрешить зависимость автоматически и просит тебя указать ему явно разрешение:

composer require mmx/fenom --update-no-dev --with-all-dependencies

У меня всё норм — вот, записал видосик

Тебе там пишут, что у тебя уже установлен пакет psr/container 2й версии. Проверяем, почему именно второй:

Просто потому, что можно или 1ю, или 2ю. Никаких особых требований нет, поэтому Composer выбрал версию 2.

Затем ты требуешь установить mmx/fenom — и тебе говорят, что для этого надо изменить зафиксированную версию psr/container.

illuminate/container[v8.0.0, ..., 8.x-dev] require psr/container ^1.0 -> found psr/container[1.0.0, ..., 1.x-dev] but the package is fixed to 2.0.2 (lock file version)

Как это сделать тебе говорят чуть ниже:

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Просто разреши даунгрейднуть версию ключом:

composer require mmx/fenom -W

Всё устанавливается, только что проверил на modhost.pro

Очень рад, что тебе нравится!

Примерно тоже самое, только при помощи mmxDatabase:

$id = $modx->getOption('id', $scriptProperties);
$category = $modx->getOption('category', $scriptProperties, '1', true);

$resource = \MMX\Database\Models\Resource::query()
    ->select('id', 'pagetitle')
    ->with('TvValues', static function($c) use ($category) {
        $c->select('value', 'contentid', 'tmplvarid');
        $c->whereHas('Tv', static function($c) use ($category) {
            $c->where('category', $category);
        });
        $c->with('Tv:id,name,caption,default_text');
    })
    ->find($id);

return $resource ? print_r($resource->toArray(), true) : 'Not found';

Получается 3 простых выборки, без join.

Сначала выбирается ресурс, потом значения его ТВ из нужной категории, а затем добираются основные свойства этих ТВ.

Eloquent собирает все данные вложенными массивами в итоговый результат:


Дальше можно перебирать результат на Fenom со всеми проверками на пустоту и прочее.