Еще через год-два надоест писать на xPDO

Думаю, через год-два всё будет также как и сейчас. Человек, который уже не работает с MODX, не будет принимать активное участие в его развитии. На это не хватит ни времени, ни желания.
Коля увлекся реактом. Там на годы вперед есть чем заняться в плане прокачки скилов и повышения удовлетворения от работы. Коля уже даже с PHP не работает. Допускаю, что он поэтому хочет использовать питоновкий FastAPI в минишопе )
И claude code не особо поможет, если нет понимания дизайна приложения. Нужно иметь хотя бы базовое представление что такое сервисный слой, что такое инфраструктурный. Чем они отличаются. И что сервис никак не может быть репозиторием )

Я это не в обиду Коле. Просто он поставил себе очень высокую планку, которую сложно достичь в MODX без серъезного уровня квалификации, опыта и упорства. Но парадокс в том, что как только ты выходишь из мира фриланса и получаешь опыт работы в больших и серьезных проектах, то тебе уже не хочется возвращаться в MODX )))

Моё запоздалое поздравление с пополнением! Это самый лучший проект для мужчины. И хочу заметить, что делается он не руками ))

Мне mmxDatabase очень понравился, я в одном проекте использовал и прям в восторге был. Жаль, что те проекты, что сейчас в работе — к сожалению не очень нужен он в них. Спасибо за пакет)

всё, спасибо.
надо было понизить версию PHP -_//

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

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

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

Интересное решение. Сомнения отпали окончательно)))

Ты используешь phinx как контейнер, в котором вызываешь xPDO Manager. То есть, миграции выполняются через xPDO и поэтому phinx получается здесь немного избыточным.

Но это, конечно, просто мое мнение. Я сейчас тоже решаю использовать phinx в PageBlocks, ведь в 3 версии у меня в планах создавать динамично кастомные таблицы. Склоняюсь к тому, чтобы отказаться от xPDO и использовать свой конструктор запросов для работы с базой.

Подготовил транспортный пакет, для желающих поиграться с новым конструктором полей.

В логах сервера ищи PHP Fatal Error

Спасибо, с ID вроде разобрался но теперь другая ошибка

Failed to load resource: the server responded with a status of 500 ()

const response = await fetch(url, this.fetchOptions);

куда копать? права на папку sendit пересмотреть?

если пресет не прописывать в sendit.inc.php то письмо о заказе прилетает на почту (и в письме кстати нет ID товара), но в заказах minishop не показывается

потому что никакой заказ не создаётся, а просто отправляется форма через FormIt.

если прописать пресет, то ругается что ID не заполнен

Значит до сервера ID не доходит. Смотри ошибки в консоли

Тогда вопрос: а зачем нужен Phinx? При создании новых полей он не участвует, новые таблицы не создаёт. Миграции происходят только при обновлении компонента?

Смотри. В конструкторе полей, поле добавляется в нативную таблицу ms3_products. Это делает миграция.
Путь такой.
1. Заполняю модальное окно данными, жму сохранить
2. Контроллер создает миграцию (Alter table Add column) и сразу же ее запускает. Вот на этом моменте используется phinx
3. Делаем запись в таблицу extra_fields.
4. Ну и где то за кадром происходит слияние нативной карты модели msProductData и новых дополнительных полей.

Примерно такая же схема при удалении поля.
Жму кнопку удалить, создается миграция на удаление колонки из таблицы. Она запускается сразу же, после создания.

Я думал, что после миграции ты запускаешь билдер

Почему схема такая, а не предложенный тобой вариант.
Ну для начала поля из extra_field можно отключать. Колонка физически остается в базе данных, но перестает попадать в карту msProductData. Это может быть полезным.

Кроме того физически перегенерированную карту msProductData обновление минишопа просто перезапишет. Можно конечно это разрулить на уровне резолверов, но зачем? Предложенная схема вроде справляется с задачей

А как ты их между собой связал? Это же разные сущности.

Я думал, что после миграции ты запускаешь билдер, который будет обновлять схему, карту и классы, и тогда магия $modx->map[$class] не нужна.

Но, похоже, это не так. Тогда вопрос: а зачем нужен Phinx? При создании новых полей он не участвует, новые таблицы не создаёт. Миграции происходят только при обновлении компонента?

Допустим, в новой версии компонента добавлено новое поле — значит, нужно создавать новую миграцию и обновлять схему ещё раз?

Честно говоря, я не понимаю явного преимущества использования phinx в этом кейсе.

Ранее, мы использовали резолверы для создания и обновления таблиц и это почти всегда приводило к неприятностям, по мере появления новых полей

Может быть, просто потому что я с такими неприятностями не сталкивался.

Привет.

Будет ли поддержка modx3?

Так MS3 целиком предназначен для MODX3. Я не занимаюсь развитием платформы для MODX2.

Продукты будут в отдельной таблице?

Тут ничего не изменилось. Поля товара как хранились в ms2_products так и хранятся.

Миграции phinx — а xpdo объекты будут работать

А как ты их между собой связал? Это же разные сущности.
Если вопрос о том, как новые поля попадут в xpdo модель — то там наш старый привычный еще из ms2 способ, который на лету обновляет $meta['map']

Цепочка загрузки:

• 1. OnMODXInit → $ms3->loadMap()
• 2. MiniShop3::loadMap() → $this->extraFields->loadMap()
• 3. ExtraFields::loadMap() → загружает ms3_extra_fields (active=1)
• 4. ExtraFields::getFieldInfo() → формирует метаданные
• 5. ExtraFields::addFieldToMap() → МОДИФИЦИРУЕТ $modx->map[$class] ← ВОТ ГДЕ МАГИЯ!
• 6. xPDO видит новые поля как нативные

Если придираться, то:

Тут я бы разделил ответ
1. Репозиторий — это паттерн. Нет четких правил по его использованию или обязательств его использовать. Так что каждый волен делать так, как видит. Вот Laravel до пятой версии вообще всю логику внутри моделей тягал и ничего.
2. На практике, насколько я видел как пишут другие, сервис и репозиторий по сути своей одно и тоже. Их задача разгрузить контроллер, вынести логику в отдельный контейнер.

Я вижу так.
Контроллер принимает запрос от API и отдает ответ. На этом все. Его зона ответственности Request-Магия-Response.
Репозиторий и\или Service — логика. Здесь идет разбор запроса, обращения к DB, построение ответа. Задача сервиса — подготовить ответ согласно запроса.
Model — исключительно работа с базой. Ее задача сходит в базу и выполнить поставленную задачу.

Отличный план.

1. Будет ли поддержка modx3?
2. Продукты будут в отдельной таблице?
3. Миграции phinx — а xpdo объекты будут работать? Миграция будет запускаться вручную или при обновлении компонента? Например, при создании поля, что будет происходить?

Сервисы создают записи, обновляют и удаляют ее, дергая каждый свою XPDO модель.

Если придираться, то:
Сервис — это бизнес-логика и обработка данных
Репозиторий — запросы к базе
Контроллер — запросы, ответы и валидация данных

То есть, контроллер вызывает сервис, сервис вызывает репозиторий, а он в свою очередь обращается к модели.

Мой верный помощник Claude Code

Поделитесь, пожалуйста, вашим опытом работы с ним — какой план используете, сталкиваетесь ли при ежедневной работе с нехваткой лимитов, сравнивали ли с другими ИИ?

доброго времени суток.
Актуализируйте плиз, всё по статье рабочее?
если пресет не прописывать в sendit.inc.php то письмо о заказе прилетает на почту (и в письме кстати нет ID товара), но в заказах minishop не показывается
если прописать пресет, то ругается что ID не заполнен…
если вручную даже прописать или вообще из пресета убрать обязательность поля ID то после нажатия на кнопку просто ничего не происходит…
в чем может быть причина? всё как в статье, за исключением иправления косяка в JS — oncLickModal.

Есть форма на FormIt с полем типа файл — как это поле будет отображаться в гугл таблице? Смогут ли просмотреть этот файл все пользователи, кто имеет доступ к таблице?

Сам отвечу, может кому-то пригодится.

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

В моем случае письмо со ссылкой на оплату отправляется при выставлении дополнительного статуса заказа «Принят к оплате». Соответвенно сразу фейлится.

В итоге пришлось сделать копию класса и внести правки – добавить новый статус и поправить условие проверки.

Ну не знаю, только устарновил Sendit и у форм c AjaxForm появились уведомления