Николай Савин
С нами с 01 января 1970; Место в рейтинге пользователей: #215 марта 2026, 20:35
Minishop2 это завершенная история. Архив. Крайне сомневаюсь, что в него будут добавляться какие то изменения. Это просто некому делать. Заинтересованн...
Порядок значений опций товара 10
15 марта 2026, 13:18
На всякий скопирую код для Bootstrap 4 (есть старый проект, лень переезжать на 5 версию):
/* Закрыть модальное окно после отправки */
document.addEve...
[SendIt] Несколько полезных нововведений в версии 1.1.2 27
13 марта 2026, 16:00
Предлагаю в целом обсудить понятие «вариант товара».
Я пришел к тому, что варианты — являются отдельными товарами. Возьмём для примера футболку. У ...
ms3Variants - Реализация вариантов одного товара в MiniShop3 7
12 марта 2026, 22:19
опытным путем выяснил что ошибку валидации радио кнопок можно вылечить добавив в форму еще один вариант
<input type="radio" name="...
Валидация radio кнопок в Sendit 1
11 марта 2026, 09:11
Привет!
Все верно:
1-го нет в магазине modstore и modx.com
2-й платный
mxEditorJs - блочный редактор Editor.js для MODX 3 2
10 марта 2026, 22:13
Все верно, сорян, в своем сообщении написал не то что хотел =)
msGiftCards - дополнение для MODX 2 + miniShop2 для продажи, применения и учета подарочных сертифика... 5
06 марта 2026, 09:38
Александр, данный компонент более недоступен для приобретения?
miniShop 2.9.1-pl 57
04 марта 2026, 21:09
Немного нетипичный пост на этом форуме. Будем считать это экспериментом. Кратко вводную информацию я выложил у нас в телеграм-сообществе — получил мно...
Baymard Institute: 61 рекомендация для e-commerce, о которых стоит знать 1
Ну если тебе за это платят деньги — то наверное смысл есть. Между PHP 7 и PHP 8, серьезных проблем совместимости нет и никогда не было. Восьмерка поддерживает все из семерки, но чуть строже относится к синтаксису. То есть некоторое количество правок синтаксиса — и все заработает. Я думаю в течение дня с помощью нейронок можно успешно хоть на PHP8.4 перейти.
Тут еще смотря какой набор компонентов используется. Чем их больше — тем и кода больше нужно подгонять.
Для начала все это не движ от Symfony DB и Controllers. В MiniShop3 обычный классический PHP подход. Почитай про PSR-4, крайне рекомендую.
Во-вторых, про метод addPackage в MODX3 забудь. Это делается один раз автоматически при загрузке MODX. Далее MiniShop3, MODX, PHP уже знают про все классы, которые есть в каталоге /core/components/minishop3/src/
Если ты создаешь любой кастомный класс, например
ты обязан использовать namespace. В твоем случае это будет
И полное имя подключаемого класса будет Именно такое имя тебе нужно указывать в системных настройках или подключаемых сервисах.
Вот примерная заготовка для создания класса. расширяющего стандартную корзину
Ну и в системных настойках нужно указать имя расширенного класса (путь не нужен, он по namespace уже известен).
Я сделаю инструмент для подключения классов, без прописывания системных настроек
Будет отдельная инструкция.
Честно говоря, не до конца понимаю зачем ты в принципе лезешь в дебри, для тебя не понятные. Это разработка для программистов. Анонса всеобщего использования минишопа еще не было. Часть архитектуры еще не готова, то что готово, до конца не оттестировано. Если прям так тянет пощупать компонент — изучай то, что готово и анонсировано.
То же самое по идее и в MS3. Только тут уже нужно использовать namespace и use. Я подготовлю документацию в скором времени. Кроме того будет визуальная утилита подключения служб, вместо того чтобы в консоли команды запускать.
Если тебя не устраивает MODX — без проблем. Используй то, что считаешь нужным. Никто же не мешает. Но зачем приходить в гости в чужую ветку и критиковать буквально через слово? Да еще и критиковать без конструктива.
То, что мы используем не самые свежие технологии, или используем их как то не так — это наш выбор.
Смотря что считать овчинкой. Я взял на себя обязательства в свое время, и считаю делом чести их выполнить. Кроме того ребята поддержали дело донатами, и тем более должны увидеть результат. А уж использовать его, или нет — каждый сам для себя решит.
Спасибо за ваше критическое замечание. Мы обязательно его рассмотрим в отведенные сроки.
Прошу заметить, что несмотря на архитектурно-инфраструктурные пробелы, приложение все равно становится лучше и современнее. Некоторые xpdo модели, за счет выноса логики в отдельный слой похудели в разы. А эту самую логику в отдельных слоях (как бы они не назывались) теперь можно подменять через DI
Путь такой.
1. Заполняю модальное окно данными, жму сохранить
2. Контроллер создает миграцию (Alter table Add column) и сразу же ее запускает. Вот на этом моменте используется phinx
3. Делаем запись в таблицу extra_fields.
4. Ну и где то за кадром происходит слияние нативной карты модели msProductData и новых дополнительных полей.
Примерно такая же схема при удалении поля.
Жму кнопку удалить, создается миграция на удаление колонки из таблицы. Она запускается сразу же, после создания.
Почему схема такая, а не предложенный тобой вариант.
Ну для начала поля из extra_field можно отключать. Колонка физически остается в базе данных, но перестает попадать в карту msProductData. Это может быть полезным.
Кроме того физически перегенерированную карту msProductData обновление минишопа просто перезапишет. Можно конечно это разрулить на уровне резолверов, но зачем? Предложенная схема вроде справляется с задачей
Так MS3 целиком предназначен для MODX3. Я не занимаюсь развитием платформы для MODX2.
Тут ничего не изменилось. Поля товара как хранились в ms2_products так и хранятся.
А как ты их между собой связал? Это же разные сущности.
Если вопрос о том, как новые поля попадут в 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 — исключительно работа с базой. Ее задача сходит в базу и выполнить поставленную задачу.
Пример вызова
Для начала прекращайте смешивать синтаксис — у вас проблемы из-за этого, в том числе. Напишите все нормально либо в fenom, либо в MODX синтаксисе. Это разные технологии, они по разному устроены и работают.
@Aleksandr Huz на этот раз тебя не забыли.
DeepSeek конечно отсыпал знатно и всему сообществу, и мне за минишоп и отдельным товарищам
Попробуй писать msProductOption.flat_area вместо простого flat_area