MiniShop3 - чего ждать в Beta версии.
В прошлой заметке, я объявил о релизе MS3 в альфа редакции. Такая редакция подразумевает базовую пробную версию. Черновую реализацию основных идей. Компонент доступен для опытных пользователей и не рекомендован для массового создания боевых магазинов.
Сегодня я расскажу о том, когда будет Beta версия для широкого круга пользователей и что мы в нее добавим.
К подготовке обновления я приступил уже на следующий день после анонса первой версии, и на всех парах лечу ко второму релизу, который уже будет выкладываться в репозитарий modstore.pro для широкого доступа.
После аудита я выбрал для себя задачи, которые необходимо решить. Разделил их на три условных блока
1. Подключение платежных модулей и модулей доставки (на момент написания уже реализовано)
2. JS модули, события, колбэки.. Все что нужно, чтобы встроиться в JS код и дополнить его своей логикой.
В MiniShop2 мы использовали callback систему
На смену колбэкам приходит система хуков, очень похожая на события в MODX.
Теперь мы можем на каждое ключевое событие написать хук, который выполнит свою логику, и например позволит остановить пополнение корзины. Подробнее про JS расскажу в отдельной заметке.
Проговорю еще раз суть доработки. В Альфа-версии был уже готовый набор JS модулей. В Бета-версии появится возможность расширения модулей собственным кодом примерно как в плагинах MODX. Ну и общее улучшение архитектуры, качества кода.
В JS меня сопровождает настоящий гуру языка @Евгений Шеронов за что ему большое спасибо.
3. Расширение моделей и управление полями админки. Задолго до Альфа-релиза я, совместно с @Наумов Алексей анонсировал подобную возможность и даже заложили некоторую базу. Но дело застряло. Управление extJS модулями через визуальный конструктор у меня не пошло. Из-за сложной структуры extJS оказалось, что нужно написать бессмысленно много PHP кода. Когда счет новых процессоров пошел на второй десяток — пришлось остановиться.
Однако фича анонсирована, часть работы уже проделана. Хочется сохранить лицо. На данный момент появилась новая идея как минимальными силами наладить управление полями админки. Будем посмотреть, может что-то и получится.
4. Ну и еще одна крупная работа. Как вы знаете в последних версиях MiniShop2 я добавил возможность работы через систему отложенных заданий (очередей), при помощи компонента Scheduler — любезно подготовленным Марком Хамстрой.
Для MiniShop3, я (что логично) планирую и дальше использовать эту систему, дополнив ее новым заданиями. Но как оказалось компонент не поддерживает MODX3 — а значит мне придется выпустить аналог.
Все расписывать не буду. Перечислю часть задач.
1. К примеру я хочу добавить десятка два новых событий, для удобной работы плагинов.
2. Активно просят заложить систему остатков. Сделаем.
3. Активно просят заложить возможность работы с дробным числом товаров. Тут нужно подумать, а нужно ли.
4. Перевод лексиконов (на данный момент только русский язык)
Ну и еще с десяток задач у меня записано.
Кстати — если вы хотите сделать подарок и мне — то вы знаете что делать. Все реквизиты есть на отдельной странице
Друзья, для тестирования и доработки мне нужен боевой проект с реальными товарами и продажами. Потому предлагаю вам партнерство.
Чтобы проверить компонент и сделать его еще лучше Я готов реализовать для вас простой магазин на новой платформе за условно небольшую сумму.
Условия
1. У вас есть готовая верстка (сверстанный дизайн или шаблон)
2. Интернет-магазин без онлайн-интеграций со складами, 1С и CRM
3. Без фильтра и поиска (или что-то очень простое). Сами понимаете MODX3 не богат на решения
4. Без обвесов вроде бонусной системы, промо-кодов и прочего (см пункт 3)
Если вы хотите сделать быстрый, простой, недорогой магазин чтобы проверить концепт вашей бизнес-идеи, если готовы реализовать трафик на проект — мы обязательно договоримся. Пишите в телеграм t.me/biz87
Сегодня я расскажу о том, когда будет Beta версия для широкого круга пользователей и что мы в нее добавим.
Beta-редакция MS3 — сроки и состав релиза.
К подготовке обновления я приступил уже на следующий день после анонса первой версии, и на всех парах лечу ко второму релизу, который уже будет выкладываться в репозитарий modstore.pro для широкого доступа.
После аудита я выбрал для себя задачи, которые необходимо решить. Разделил их на три условных блока
Мажорный блок работ.
Здесь крупные задачи, от реализации которых зависит нормальное функционирование магазина и его расширяемость компонентами.1. Подключение платежных модулей и модулей доставки (на момент написания уже реализовано)
2. JS модули, события, колбэки.. Все что нужно, чтобы встроиться в JS код и дополнить его своей логикой.
В MiniShop2 мы использовали callback систему
miniShop2.Callbacks.add('Cart.add.before', 'restrict_cart', function () {
miniShop2.Message.error('Добавление товаров в корзину запрещено!');
return false;
});
На смену колбэкам приходит система хуков, очень похожая на события в MODX.
Теперь мы можем на каждое ключевое событие написать хук, который выполнит свою логику, и например позволит остановить пополнение корзины. Подробнее про JS расскажу в отдельной заметке.
document.addEventListener('DOMContentLoaded', () => {
ms3.hooks.addHook('beforeRemoveCart', beforeRemoveCart)
})
async function beforeRemoveCart (hooksData) {
await fetch('some-url')
.catch(e => {
console.error(e)
Object.assign(hooksData, { cancel: true })
})
}
На момент написания заметки — это тоже уже реализовано. Еще немного причешу код — и JS готов к боевому применению. Проговорю еще раз суть доработки. В Альфа-версии был уже готовый набор JS модулей. В Бета-версии появится возможность расширения модулей собственным кодом примерно как в плагинах MODX. Ну и общее улучшение архитектуры, качества кода.
В JS меня сопровождает настоящий гуру языка @Евгений Шеронов за что ему большое спасибо.
3. Расширение моделей и управление полями админки. Задолго до Альфа-релиза я, совместно с @Наумов Алексей анонсировал подобную возможность и даже заложили некоторую базу. Но дело застряло. Управление extJS модулями через визуальный конструктор у меня не пошло. Из-за сложной структуры extJS оказалось, что нужно написать бессмысленно много PHP кода. Когда счет новых процессоров пошел на второй десяток — пришлось остановиться.
Однако фича анонсирована, часть работы уже проделана. Хочется сохранить лицо. На данный момент появилась новая идея как минимальными силами наладить управление полями админки. Будем посмотреть, может что-то и получится.
4. Ну и еще одна крупная работа. Как вы знаете в последних версиях MiniShop2 я добавил возможность работы через систему отложенных заданий (очередей), при помощи компонента Scheduler — любезно подготовленным Марком Хамстрой.
Для MiniShop3, я (что логично) планирую и дальше использовать эту систему, дополнив ее новым заданиями. Но как оказалось компонент не поддерживает MODX3 — а значит мне придется выпустить аналог.
Минорный блок работ
Здесь задачи меньшей важности. В основном это доработка различных частей архитектуры.Все расписывать не буду. Перечислю часть задач.
1. К примеру я хочу добавить десятка два новых событий, для удобной работы плагинов.
2. Активно просят заложить систему остатков. Сделаем.
3. Активно просят заложить возможность работы с дробным числом товаров. Тут нужно подумать, а нужно ли.
4. Перевод лексиконов (на данный момент только русский язык)
Ну и еще с десяток задач у меня записано.
Патчевый блок работ
Совсем мелкие правки, которые замечаю в процессе работы. Надеюсь и вы, друзья дадите обратную связь.Документация
А куда же без нее. Вынес это в отдельный блок. Буду писать. @Баха Волков предлагает сделать для документации отдельный сайт, ввиду большого объема, вместе с демо. Что вы думаете по этому поводу? Пишите свое мнение в комментариях.Сроки выпуска нового релиза
Планирую завершить все работы в декабре и сделать подарок сообществу на Новый Год.Кстати — если вы хотите сделать подарок и мне — то вы знаете что делать. Все реквизиты есть на отдельной странице
Интернет-магазин за копейки
Друзья, для тестирования и доработки мне нужен боевой проект с реальными товарами и продажами. Потому предлагаю вам партнерство.
Чтобы проверить компонент и сделать его еще лучше Я готов реализовать для вас простой магазин на новой платформе за условно небольшую сумму.
Условия
1. У вас есть готовая верстка (сверстанный дизайн или шаблон)
2. Интернет-магазин без онлайн-интеграций со складами, 1С и CRM
3. Без фильтра и поиска (или что-то очень простое). Сами понимаете MODX3 не богат на решения
4. Без обвесов вроде бонусной системы, промо-кодов и прочего (см пункт 3)
Если вы хотите сделать быстрый, простой, недорогой магазин чтобы проверить концепт вашей бизнес-идеи, если готовы реализовать трафик на проект — мы обязательно договоримся. Пишите в телеграм t.me/biz87
Поблагодарить автора
Отправить деньги
Комментарии: 11
Отдельный сайт с докой? По идее, почему нет, если будет главная, будет как доп реклама как modx так и магазина. Все кто-нибудь лишний раз присоединится к сообществу.
Мне кажется отдельная документация это лишняя работа. Тут бы демо версию нормально допилить
Оставленная «на потом» дока будет камнем на шее успешного запуска нового модуля.
Про платную расширенную версию ещё не забываем.
Про платную расширенную версию ещё не забываем.
На смену колбэкам приходит система хуков, очень похожая на события в MODX.А зачем хуки, если есть события в JS?
Расскажи ка мне друг мой, как ты при помощи события отменишь добавление в корзину или отправку заказа?
А как, при подписке на одно событие — ты прервешь выполнение других, если первое событие сигнализирует о прерывании действия. И еще пожалуйста дай знать, как работать в событиях с асинхронными запросами.
Я и сам думал обойдусь событиями. Но основательно взявшись за работу, понял что они нефига не справляются.
А как, при подписке на одно событие — ты прервешь выполнение других, если первое событие сигнализирует о прерывании действия. И еще пожалуйста дай знать, как работать в событиях с асинхронными запросами.
Я и сам думал обойдусь событиями. Но основательно взявшись за работу, понял что они нефига не справляются.
Не знаю где написать хотелку. Напишу тут.
А можно сделать так, чтобы если товары в корзине с устаревшей ценой, то у них цена становилась актуальной?
А то приходится плагин свой делать для этого. А мне кажется это важно и логично для любого магазина…
Тут конечно могут быть сложности, когда используются всякие компоненты скидок и прочего. Но можно сделать галочку в админке — актуализировать цены если в корзине они старые.
А можно сделать так, чтобы если товары в корзине с устаревшей ценой, то у них цена становилась актуальной?
А то приходится плагин свой делать для этого. А мне кажется это важно и логично для любого магазина…
Тут конечно могут быть сложности, когда используются всякие компоненты скидок и прочего. Но можно сделать галочку в админке — актуализировать цены если в корзине они старые.
Это не «хотелка», а обязательный стандартный функционал любого магазина.
Причём с механикой уведомлений о том, что цена в корзине изменилась в ту или иную сторону и на сколько.
Тоже самое с остатками.
Компоненты скидок и т.п. сами должны реализовывать свою логику в зависимости от изменения цены товара в корзине.
Причём с механикой уведомлений о том, что цена в корзине изменилась в ту или иную сторону и на сколько.
Тоже самое с остатками.
Компоненты скидок и т.п. сами должны реализовывать свою логику в зависимости от изменения цены товара в корзине.
Не только цена может измениться, но и товара уже может не быть в наличии.
Крутые обновления! Просто класс! Спасибо!
Хотел уточнить:
У меня даже есть концепт, как отличать компоненты, у нас есть постфикс версии, как правило это -beta или -pl (и даже -pl2 и т.п.). Я анализировал код установщика и не нашел никаких опасных привязок к этим постфиксам.
А значит, мы можем использовать постфикс в стиле:
Scheduler 1.4.1-pl → Scheduler 1.4.1-modx-pro, где modx-pro — github-логин автора форка. Довольно системно получается, и ничего не сломает. Можно использовать и в других компонентах аналогично!
После этого спокойно выпускать новые версии, не оглядываясь на оригинальный пакет. Раз уж там не понятно почему, не принимают PR-ы (вроде этого), из-за чего, полагаю @Николай Савин и не рассматриваешь изначально затащить туда поддержку MODX3 (хоть она и заявлена у оригинального автора).
Что скажете, коллеги?
Хотел уточнить:
Scheduler… Для MiniShop3, я (что логично) планирую и дальше использовать эту систему, дополнив ее новым заданиями. Но как оказалось компонент не поддерживает MODX3 — а значит мне придется выпустить аналог.Есть предложение поддерживать Fork, а не плодить компоненты!
У меня даже есть концепт, как отличать компоненты, у нас есть постфикс версии, как правило это -beta или -pl (и даже -pl2 и т.п.). Я анализировал код установщика и не нашел никаких опасных привязок к этим постфиксам.
А значит, мы можем использовать постфикс в стиле:
Scheduler 1.4.1-pl → Scheduler 1.4.1-modx-pro, где modx-pro — github-логин автора форка. Довольно системно получается, и ничего не сломает. Можно использовать и в других компонентах аналогично!
После этого спокойно выпускать новые версии, не оглядываясь на оригинальный пакет. Раз уж там не понятно почему, не принимают PR-ы (вроде этого), из-за чего, полагаю @Николай Савин и не рассматриваешь изначально затащить туда поддержку MODX3 (хоть она и заявлена у оригинального автора).
Что скажете, коллеги?
А толку то, в репозитории только 1 пакет с одним именем может лежать. Нет же выбора загрузки версии. Точнее вроде как есть, но никто не будет следить за этим. Да и версии компонентов от разных авторов могут развиваться в разном направлении.
Проблема в том, что авторы бросают свои дополнения и перестают развивать. И даже присланные PR не внедряют. Вот Sheduler на gitjhub висит с последним обновлением 2 года назад, и что с ним делать, если автору пофигу?..
Проблема в том, что авторы бросают свои дополнения и перестают развивать. И даже присланные PR не внедряют. Вот Sheduler на gitjhub висит с последним обновлением 2 года назад, и что с ним делать, если автору пофигу?..
Из-за сложной структуры extJS оказалось, что нужно написать бессмысленно много PHP кода. Когда счет новых процессоров пошел на второй десяток — пришлось остановитьсяВообще конечно когда классные процессоры выпустили для MODX это было думаю круто. Наверно сократило кол-во кода. Наумкин помню ими восторгался. Но все равно это для меня оказалось не хорошим решением. Кода все равно много писать пришлось. Для getTables я CRUD делал в одном файле. Это сократило кол-во контроллеров php с 5-7 на таблицу на 1 контроллер общий для всех таблиц.
Можно попробовать процессоры create, getlist, update и т.д. переписать на 1 процессор на таблицу для extJS. Или может даже 1 процессор на все таблицы. Но здесь не уверен. ExtJs сейчас уже подзабыл.
Либо у нас сейчас есть крутые ИИ и с задачей написать кучу однотипных процессоров Cursor думаю справиться :-). Только промт сообразить как написать :-).
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.