Сергей, при всем уважении к твоим заслугам. Я не понимаю зачем ты льешь негатив? Пришел в гости, в обсуждение хорошей новости и на каждую реплику пишешь что все плохо.
Если тебя не устраивает MODX — без проблем. Используй то, что считаешь нужным. Никто же не мешает. Но зачем приходить в гости в чужую ветку и критиковать буквально через слово? Да еще и критиковать без конструктива.
То, что мы используем не самые свежие технологии, или используем их как то не так — это наш выбор.

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

Мне тоже за доработку pdoTools обещали финансовую мотивацию. Я мог бы взять деньги, выкатить продукт и отвалить. Но я посчитал честным отказаться, хотя деньги предложили достойные. Я физически не вытяну доведение до ума новой версии. И не хочу, чтобы мне потом предъявили.

Возможно у тебя есть свои планы на минишоп3, но если нет, то это просто способ заработать денюжку с неясным результатом. Что-то мне подсказывает, что никто после тебя не полезет в него и не будет его развивать. Но это чисто моё видение ситуации. Буду раз, если ошибаюсь )

Старая песня заиграла новыми словами! Раньше — лет 7-8 назад было так — магазины теперь никому не нужны, т.к. есть Instagram, соц. сети Wix и Tilda!))). Теперь пугают маркетплейсами — все оказывается туда перемещаются! Я работаю с сайтами-магазинами строительной тематики, где формируются большие, сложные и сборные заказы. Они никак в логистику маркетплейсов не укладываются. Сколько заказчики не пересказывали сказки про то, как сосед добавил объявление на АВИТО и «телефон оборвали» — ни один из них сайт не сократил и рекламу не сиквестировал. Наоборот есть такие, которые говорят — нужен сайт и Директ, задрали бабки с маркетплейсов, сканирующие сотни объявлений в поисках самого дешевого товара.

Так что овчинка не стоит выделки

Смотря что считать овчинкой. Я взял на себя обязательства в свое время, и считаю делом чести их выполнить. Кроме того ребята поддержали дело донатами, и тем более должны увидеть результат. А уж использовать его, или нет — каждый сам для себя решит.

Как только ты спроектируешь и реализуешь минишоп с использованием современных паттернов и инструментов в виде Fast Route, Eloquent, Phinx и т.д., ты поймешь, что MODX тебе уже не нужен. Зачем? Ради древней админки? А для оплат есть куча опенсорсных модулей. Имея композер можно насобирать любую конфигурацию )
Но проблема в том, что минишоп нужен только в MODX. Отдельно он не взлетит. Уже есть готовые раскрученные решения и с ними конкуренцию выиграть невозможно. Плюс спрос на личные интернет магазины заметно упал, так как все перемещаются на торговые площадки (озон, вайлдберис, яндекс, сбермаркет и т.д.). Так что овчинка не стоит выделки ¯\_(ツ)_/¯

П.С.
Кстати, еще в прошлом году на хабре видел бенчмарки роутеров. И симфоневый был быстрее ;)

поэтому хочет использовать питоновкий FastAPI

Все гораздо проще, я писал название по памяти и перепутал с Fast Route. Это же не научная публикация была, а легкий тред в телеге.

Нужно иметь хотя бы базовое представление что такое сервисный слой, что такое инфраструктурный. Чем они отличаются. И что сервис никак не может быть репозиторием )

Спасибо за ваше критическое замечание. Мы обязательно его рассмотрим в отведенные сроки.
Прошу заметить, что несмотря на архитектурно-инфраструктурные пробелы, приложение все равно становится лучше и современнее. Некоторые xpdo модели, за счет выноса логики в отдельный слой похудели в разы. А эту самую логику в отдельных слоях (как бы они не назывались) теперь можно подменять через DI

Еще через год-два надоест писать на 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 модель.

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

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