Николай Савин

Особенно тревожит то, что даже активные разработчики вроде biz87 признаются в использовании нейросетей для базового кодирования — это говорит о недостатке «живых» разработчиков в экосистеме.

На отца руку поднял, негодяй. Удалить его что-ли?

mFilter3 планируется да. Концепта еще никакого нет, я не знаю где ты нашел подробности. Скорее всего это будет принципиально другой подход в работе.

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

Хорошие новости — это будет сильно быстрее, чем история с минишопом.

Ну и пусть растут себе. Ветки MODX2 и miniShop2 (в том числе и прилагаемые компоненты) — почти заброшены. Обновления если и бывают — то крайне редко.

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

Если прям хочется сделать все правильно и красиво — то идешь на github, находишь там нужный компонент и делаешь Pull Request с исправлением. Пул Реквесты мы принимаем, и патчи выпускаем.

Ну это все на уровне кода фиксится же. Причем некоторые вещи довольно просто. Если нет желания возиться — всегда можно привлечь программиста.

@Евгений Webinmd обрати внимание. Некоторые вещи можно пофиксить и выкатить патч

Среди перечисленного кода нет ошибок. Это предупреждения. Они никак не ломают код, не прерывают работу проекта. Ворнинги можно отключить на уровне PHP, на уровне веб сервера (htaccess, nginx), на уровне PHP.ini

Простое переключение на php >8.0 приводит к многочисленным ошибкам и ворнингам (деприкейт-функции) в журнале ошибок.

Прям таки к многочисленным? А ну покажи что за ошибки? Доработкой под PHP8.0 занимались, известные немногочисленные проблемы закрывали.

Есть ли смысл тратить время на устранение всех этих ошибок?

Ну если тебе за это платят деньги — то наверное смысл есть. Между PHP 7 и PHP 8, серьезных проблем совместимости нет и никогда не было. Восьмерка поддерживает все из семерки, но чуть строже относится к синтаксису. То есть некоторое количество правок синтаксиса — и все заработает. Я думаю в течение дня с помощью нейронок можно успешно хоть на PHP8.4 перейти.

Тут еще смотря какой набор компонентов используется. Чем их больше — тем и кода больше нужно подгонять.

Василий, что-то ты мудришь сильно. Давай по порядку.
Для начала все это не движ от Symfony DB и Controllers. В MiniShop3 обычный классический PHP подход. Почитай про PSR-4, крайне рекомендую.

Во-вторых, про метод addPackage в MODX3 забудь. Это делается один раз автоматически при загрузке MODX. Далее MiniShop3, MODX, PHP уже знают про все классы, которые есть в каталоге /core/components/minishop3/src/

Если ты создаешь любой кастомный класс, например

/core/components/minishop3/src/Controllers/Cart/CartCustom.php

ты обязан использовать namespace. В твоем случае это будет

namespace MiniShop3\Controllers\Cart;

И полное имя подключаемого класса будет

MiniShop3\Controllers\Cart\CartCustom

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

Вот примерная заготовка для создания класса. расширяющего стандартную корзину

<?php

namespace MiniShop3\Controllers\Cart;  //  Обрати внимание это путь к каталогу Controllers\Cart\

use MiniShop3\Controllers\Cart\Cart;  //  Это мы подключили стандартный класс корзины, который будем переопределять

class CustomCart extents Cart
{
    //  Вот и все.  Класс подключен и расширен. Никаких addPackage
}

Ну и в системных настойках нужно указать имя расширенного класса (путь не нужен, он по namespace уже известен).

Я сделаю инструмент для подключения классов, без прописывания системных настроек
Будет отдельная инструкция.

Честно говоря, не до конца понимаю зачем ты в принципе лезешь в дебри, для тебя не понятные. Это разработка для программистов. Анонса всеобщего использования минишопа еще не было. Часть архитектуры еще не готова, то что готово, до конца не оттестировано. Если прям так тянет пощупать компонент — изучай то, что готово и анонсировано.

Василий, Складывать классы в каталог custom не обязательно лет уже 7 как. Еще с тех времен как Василий изготовил подключение служб. Кладешь в любой удобный каталог и указываешь путь к классу.
То же самое по идее и в MS3. Только тут уже нужно использовать namespace и use. Я подготовлю документацию в скором времени. Кроме того будет визуальная утилита подключения служб, вместо того чтобы в консоли команды запускать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привет.

Будет ли поддержка 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 — исключительно работа с базой. Ее задача сходит в базу и выполнить поставленную задачу.

Нужно вызывать вот такой класс

MODX\Revolution\Processors\Security\Login

Пример вызова

$response = $this->modx->runProcessor(\MODX\Revolution\Processors\Security\Login::class, $this->scriptProperties);

Нет ощущения. что дело не в неработающих примерах, как вы это подаете?
Для начала прекращайте смешивать синтаксис — у вас проблемы из-за этого, в том числе. Напишите все нормально либо в fenom, либо в MODX синтаксисе. Это разные технологии, они по разному устроены и работают.

Продолжаю эксперименты с AI контентом. Для сравнения подключил DeepSeek к нашем дайджесту. Как по мне, получилось намного лучше, сравнение с Yandex GPT наглядное.

@Aleksandr Huz на этот раз тебя не забыли.
DeepSeek конечно отсыпал знатно и всему сообществу, и мне за минишоп и отдельным товарищам

нам бы интернет-магазин для MODX3 какой нибудь. Да поиск с фильтрами к нему.

Ну логично. Скрипт делает выборку по таблице modResource, и там такого поля нет. Оно лежит в другой таблице msProductOption.
Попробуй писать msProductOption.flat_area вместо простого flat_area