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

Вполне логичное и развитие событий.

Еще через год-два надоест писать на xPDO, и захочется нормальный Eloquent.
А потом и установку\обновление перенести на Composer + запуск консольных скриптов через Symfony/Console, раз уже используется Phinx.

Давай, Николай! Может, ты заставишь сообщество MODX перейти на современные технологии! У меня с моей mmx-инициативой не взлетело, увы.

Даю добро!

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

Даже я, известный старовер, потихоньку начал пользоваться Алисой Про и Deepseek.

Но они не пишут мне код, я больше с ними советуюсь, как с резиновыми уточками. Например спрашиваю, какое ПО подойдёт для решения задачи, то есть использую как поисковик. Недавно вот понадобилось развернуть прокси для запросов в Youtube — узнал про tinyproxy, отлично работает.

Ну или надо было разробраться как работать с API Телеграм через tdlib, а это вовсе не то же самое, что Bot API. Готовых примеров для PHP я просто не нашёл, и вот здесь нейросети меня здорово выручили своими подсказками.
Что интересно, они генерировали нерабочий код, точнее код, который уже не работал с текущей версией tdlib, потому что использовал устаревшие методы. Но мне этого хватило написать свою, рабочую версию, по их примерам.

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

Рад за Николая! Еще один разработчик вышел за пределы MODX и открыл для себя много интересного.

Скопирую сюда его текст для удобства:


Я еще в прошлом году от скуки сделал composer-версию, в которой перелопатил классы и добавил инсталлятор — но интереса никто не проявил.

Думаю, выхода miniShop 3 можно уже и не ждать. Да и просто выйти — это только половина дела, его нужно поддерживать и дорабатывать, а желающих давно нет.

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