MiniShop для MODX3. Что происходит и когда ждать?
Ожидаемо все чаще возникают вопросы когда ждать minishop для MODX3.
Давайте разберемся что вообще происходит. В этой заметке я постараюсь ответить на все вопросы.
Для начала, принято решение не делать дополнительную ветку miniShop2 а выпустить отдельный продукт MiniShop3 или сокращенно ms3. С большой буквы, как положено называть PHP классы.
Это связано с тем, что MODX2 еще несколько лет будет актуален, его никто не забрасывает. Ребята активно используют miniShop2 и присылают запросы на улучшения, да и сами улучшения тоже. Пусть развивается отдельно. Это не отменяет того что нововведения и улучшения могут портироваться в обе стороны.
Кроме того будет отличаться кодовая база и архитектура.
За годы использования накопилось множество вопросов к архитектуре компонента, большинство из которых невозможно было решить не сломав существующие проекты. С запуском нового продукта наконец появляется возможность попытаться решить эти вопросы ничего не ломая.
Как вы понимаете такой подход усложняет работу. Ведь нужно не просто перенести кодовую базу. Нужно придумать решение поставленных задач, написать новый код, убедиться в совместимости новых кусков с общей логикой проекта, оттестировать все нюансы, подготовить документацию и бесконечно отвечать на вопросы тех кто переходит на MODX3. Вопросов конечно тоже будет больше.
Пока речь идет только о запланированном. Еще не факт что хватит сил, терпения и финансирования все реализовать.
Меняем поля базы данных.
В каталоге Model теперь находятся модели для работы с базой данных. Никакой логики.
Каталога handlers который появился не так давно в miniShop2 тоже больше нет.
Зато будет каталог Controllers как положено.
Полностью новый JS
Разумеется больше никакого jquery. Только чистый JS написанный с использованием классов и подключаемых модулей. Теперь нет необходимости переопределять файл со всей логикой целиком. Вы сможете переопределить, например, только корзину.
Кроме того, мы хотим реализовать API внутри JS, который можно будет использовать если вы делаете фронт на каком нибудь VUE.
В minishop2 весь JS завязан на формах и селекторах. Пора менять ситуацию. По идее нужна возможность передавать серверу произвольные массивы сырых данных без использования форм, так же как это сделано в PHP API
Например:
Очень кратко затрону всем знакомые вопросы.
Опции товаров.
Есть ряд вопросов к архитектуре и реализации. Будет полностью пересмотрена работа опций.
Админка.
Несмотря на сохранение фреймворка extJS — админка все таки претерпела изменения. Страница ресурса реализована несколько по другому и не получится просто перенести существующие extJS файлы. Часть нужно переписывать.
Также к пункту «Админка» можно отнести создание заказа из админки с нуля. В miniShop2 такого нет.
Верстка
Bootstrap5 для шаблонов и чанков, а также свежий шаблон для писем с более полным содержанием заказа.
Ну и многое другое еще хочется сделать из того, что лучше сделать сразу и спасти сотню другую проектов от последующего обновления с возможностью поломки.
На этот вопрос нет ответа от слова совсем. Так как это OpenSource мы занимаемся им в свободное время, практически без финансирования. Все хотят кушать. За последние три месяца нам удалось собрать поддержку менее чем в 10 тысяч рублей. Этой суммы хватит, чтобы обмыть релиз, когда он случится, но никак не полноценно работать без оглядки на финансовую составляющую вопроса.
Вопрос риторический. Но давайте рассмотрим его под микроскопом.
Кто-то может сказать что конкретный релиз стоит конкретную сумму.
На самом деле разработка продукта не заканчивается выпуском очередного или в нашем случае первоначального релиза.
Кроме разработки продукта нам предстоит долгое, внимательное тестирование, которое занимает времени не меньше самой разработки.
Далее необходимо подготовить документацию проекта. То что сейчас есть для MS2 даже близко не стоит рядом с документацией старших братьев
Сравните качество документации например в этих проектах
Нам нужно подготовить приличный демо-магазин для возможности пощупать проект и принять решение об использовании MiniShop
Отдельно для маркетинговых целей нужен еще сайт-презентация. Вообще если мы всерьез хотим популяризировать MODX и MS — на маркетинг нужно затрачивать немало сил.
Далее встают вопросы техподдержки, ответов на вопросы, сбора опыта использования и ведения бэклога для пожеланий и дополнений.
Ну и конечно, никто не отменяет необходимости дорабатывать и улучшать продукт. Идей очень много. Мы давно пришли к тому, чтобы внедрять в компонент часть платных дополнений в базовой реализации.
Итого даже без калькуляции видно, что на содержание и развитие проекта нужно довольно много ресурсов. Как финансовых, так и человеческих.
Человеческие ресурсы есть. А вот финансовых не хватает. Если каждый кто делает интернет-магазины используя наши наработки пришлет хотя бы один процент от той суммы, которые зарабатывает, используя miniShop — мы сможем выделить больше времени и сил и принести пользу. Вкладывая сейчас в проект — вы инвестируете в свой будущий доход.
Развитие MiniShop происходит исключительно благодаря Вам друзья!
Финансовая поддержка с вашей стороны, позволяет выделять больше времени на развитие сообщества и обновлять наши проекты, которые в свою очередь приносят пользу и вам.
Поддержать нас можно, используя следующие каналы для доната:
Огромное спасибо, всем кто поддерживает!
Давайте разберемся что вообще происходит. В этой заметке я постараюсь ответить на все вопросы.
1. MiniShop3
Для начала, принято решение не делать дополнительную ветку miniShop2 а выпустить отдельный продукт MiniShop3 или сокращенно ms3. С большой буквы, как положено называть PHP классы.
Это связано с тем, что MODX2 еще несколько лет будет актуален, его никто не забрасывает. Ребята активно используют miniShop2 и присылают запросы на улучшения, да и сами улучшения тоже. Пусть развивается отдельно. Это не отменяет того что нововведения и улучшения могут портироваться в обе стороны.
Кроме того будет отличаться кодовая база и архитектура.
2. MiniShop3 это не адаптация знакомого продукта под рельсы MODX3. Мы меняем архитектуру.
За годы использования накопилось множество вопросов к архитектуре компонента, большинство из которых невозможно было решить не сломав существующие проекты. С запуском нового продукта наконец появляется возможность попытаться решить эти вопросы ничего не ломая.
Как вы понимаете такой подход усложняет работу. Ведь нужно не просто перенести кодовую базу. Нужно придумать решение поставленных задач, написать новый код, убедиться в совместимости новых кусков с общей логикой проекта, оттестировать все нюансы, подготовить документацию и бесконечно отвечать на вопросы тех кто переходит на MODX3. Вопросов конечно тоже будет больше.
3. Что нового?
Пока речь идет только о запланированном. Еще не факт что хватит сил, терпения и финансирования все реализовать.
Меняем поля базы данных.
- В основном изменения коснулись ссылок на смежные таблицы. К таким полям добавим суффикс _id к примеру msOrder.payment становится msOrder.payment_id и т.п. Так именования полей становятся более очевидными и самодокументированными
- Переименовали многострадальное поле rank которое является зарезервированным словом в mySQL. Предварительно остановились на синониме position — еще не поздно предложить более актуальное именование поля
- Из таблицы заказа удалено поле address. Таблица с Адресом теперь будет привязываться по другому
В каталоге Model теперь находятся модели для работы с базой данных. Никакой логики.
Каталога handlers который появился не так давно в miniShop2 тоже больше нет.
Зато будет каталог Controllers как положено.
Полностью новый JS
Разумеется больше никакого jquery. Только чистый JS написанный с использованием классов и подключаемых модулей. Теперь нет необходимости переопределять файл со всей логикой целиком. Вы сможете переопределить, например, только корзину.
Кроме того, мы хотим реализовать API внутри JS, который можно будет использовать если вы делаете фронт на каком нибудь VUE.
В minishop2 весь JS завязан на формах и селекторах. Пора менять ситуацию. По идее нужна возможность передавать серверу произвольные массивы сырых данных без использования форм, так же как это сделано в PHP API
Например:
MiniShop.Cart.Add(id, count, options)
MiniShop.Order.Add(key, value)
MiniShop.Order.Submit()Очень кратко затрону всем знакомые вопросы.
- Полноценная мини-корзина из коробки
- Кнопки плюс-минус в корзине
- Более полная информация внутри JS запросов с возможностью отдавать данные аналитике
Опции товаров.
Есть ряд вопросов к архитектуре и реализации. Будет полностью пересмотрена работа опций.
Админка.
Несмотря на сохранение фреймворка extJS — админка все таки претерпела изменения. Страница ресурса реализована несколько по другому и не получится просто перенести существующие extJS файлы. Часть нужно переписывать.
Также к пункту «Админка» можно отнести создание заказа из админки с нуля. В miniShop2 такого нет.
Верстка
Bootstrap5 для шаблонов и чанков, а также свежий шаблон для писем с более полным содержанием заказа.
Ну и многое другое еще хочется сделать из того, что лучше сделать сразу и спасти сотню другую проектов от последующего обновления с возможностью поломки.
4. Когда ждать?
На этот вопрос нет ответа от слова совсем. Так как это OpenSource мы занимаемся им в свободное время, практически без финансирования. Все хотят кушать. За последние три месяца нам удалось собрать поддержку менее чем в 10 тысяч рублей. Этой суммы хватит, чтобы обмыть релиз, когда он случится, но никак не полноценно работать без оглядки на финансовую составляющую вопроса.
5. Сколько нужно денег?
Вопрос риторический. Но давайте рассмотрим его под микроскопом.
Кто-то может сказать что конкретный релиз стоит конкретную сумму.
На самом деле разработка продукта не заканчивается выпуском очередного или в нашем случае первоначального релиза.
Кроме разработки продукта нам предстоит долгое, внимательное тестирование, которое занимает времени не меньше самой разработки.
Далее необходимо подготовить документацию проекта. То что сейчас есть для MS2 даже близко не стоит рядом с документацией старших братьев
Сравните качество документации например в этих проектах
Нам нужно подготовить приличный демо-магазин для возможности пощупать проект и принять решение об использовании MiniShop
Отдельно для маркетинговых целей нужен еще сайт-презентация. Вообще если мы всерьез хотим популяризировать MODX и MS — на маркетинг нужно затрачивать немало сил.
Далее встают вопросы техподдержки, ответов на вопросы, сбора опыта использования и ведения бэклога для пожеланий и дополнений.
Ну и конечно, никто не отменяет необходимости дорабатывать и улучшать продукт. Идей очень много. Мы давно пришли к тому, чтобы внедрять в компонент часть платных дополнений в базовой реализации.
Итого даже без калькуляции видно, что на содержание и развитие проекта нужно довольно много ресурсов. Как финансовых, так и человеческих.
Человеческие ресурсы есть. А вот финансовых не хватает. Если каждый кто делает интернет-магазины используя наши наработки пришлет хотя бы один процент от той суммы, которые зарабатывает, используя miniShop — мы сможем выделить больше времени и сил и принести пользу. Вкладывая сейчас в проект — вы инвестируете в свой будущий доход.
Развитие MiniShop происходит исключительно благодаря Вам друзья!
Финансовая поддержка с вашей стороны, позволяет выделять больше времени на развитие сообщества и обновлять наши проекты, которые в свою очередь приносят пользу и вам.
Поддержать нас можно, используя следующие каналы для доната:
Огромное спасибо, всем кто поддерживает!
31 августа 2022, 19:28
Поблагодарить автора
Отправить деньги
Комментарии: 45
Спасибо за ваш труд! Закинул малость, что было на Юмани. Стараюсь всегда донатить как только такие посты выкладываете.
P.S. Может есть вариант как то закрепить на главной странице сразу блок со сбором донатов на развитие miniShop?
Если каждый кто делает интернет-магазины используя наши наработки пришлет хотя бы один процент от той суммы, которые зарабатывает, используя miniShop — мы сможем выделить больше времени и сил и принести пользу.К сожалению сейчас не очень с заказами на сайтики, но подход хороший вы написали, буду закладывать процент на развитие miniShop в бюджеты проектов.
P.S. Может есть вариант как то закрепить на главной странице сразу блок со сбором донатов на развитие miniShop?
Здорово, что ребята находят силы и время развивать продукт, спасибо им за это! Но чтобы компоненту хоть немного приблизиться к профильным решениям на рынке Ecommerce, его реально надо ставить на коммерческие рельсы и открывать обсуждение функционала в широкие массы, как и сбор средств на его развитие. Чтобы я хотел видеть в ecommerce решении для MODX из коробки:
1)Хоть какой-никакой адекватный функционал управления заказами из админки, я имею ввиду, возможность создавать заказы, печатать документы по ним, адекватный пересчет всех параметров заказа (состав, доставка, оплата, скидки), также нужен минимальный функционал выйти на связь с клиентом, хотя бы через отправку E-mail. Сегодня чтобы это реализовать нужно поставить минимум 6 дополнений, которые сломают интерфейс окна заказа, так как каждое добавляет свои поля и настройки в extjs как попало, потому что нет регламента расширения интерфейса окна заказа. Приходится лезть в исходники extjs этих компонентов и переписывать их.
2)Заложенная в коробку и продуманная система скидок/подарков/бонусов — это ключевой блок, на котором разработчики смогут зарабатывать на своих дополнениях. То, что сейчас есть, куча дополнений, где каждое считает несогласованно с другими — это проблема плохой архитектуры. Один компонент переписывает напрямую сессию, второй пытается через методы пересчитывать, в итоге один перебивает расчеты другого — полная вакханалия. Нужен четкий интерфейс для дополнений, чтобы их можно было выстраивать в логические цепочки для конечного расчета заказа. Кому-то нужно сначала применить промокод, а потом скидку от суммы, а кому-то наоборот, это должно решаться простейшим изменением порядка срабатывания и желательно не завязанного на приоритет плагина компонента. Где-то видел, уже не помню на какой платформе, решение — раздел скидок сделан в виде цепочки, куда можно перетягиванием добавлять узлы (компоненты скидок, промокодов, бонусов) — и прям мышкой можно настроить их порядок срабатывания и другие условия совместной работы, типа установка пороговой суммы при которой следующий узел будет активным. Это самое удобное решение из всех, что я видел)
3)Сосредоточиться на API, если будет полное покрытие функционала на API, это даст просто нереальную свободу, будут писать и собственные админки для менеджеров в виде пакетов на всяких Vue.js и React.js и дополнения смогут использовать всю мощь API, вместо того, чтобы придумывать свои велосипеды. Я считаю, что если магазином можно будет пользоваться на полную, просто сидя в том же Postman и посылая запросы — это будет победа и залог на хорошие перспективы развития. Не сделать это на старте — будет ситуация как с текущим miniShop2, тонны дополнений, где часть ломает работу магазина, из-за того, что не поспевают за обновлениями базы, и часть, где царит велосипедостроительство, так как нет API и четких интерфейсов. Как итог, с последней версией miniShop2 адекватно работают, на моей практике из всего modstore, ну компонентов 10-15, и то если их допилить.
4)По поводу опций товаров — я надеюсь, что ребята используют EAV для архитектуры, так как это самое популярное решение сейчас во всех топовых Ecommerce продуктах. Ну и да систему фильтрации хорошо бы тоже иметь из коробки, это неотъемлемая часть любого интернет-магазина, странно было бы видеть этот функционал отдельным компонентом вне коробки, хотя чего удивляться, сейчас он вообще в компоненте поиска по сайту запилен (mSearch2)
5)По поводу финансирования разработки — однозначно нужно завести всякие «бусти» для донатов, но чтобы деньги пошли, нужна мотивация, а для этого нужно что-то показывать, прогресс, демо, видосы, больше деталей, классная дока. Всё это в сумме может дать необходимую мотивацию поддерживать проект, а редкие посты в сообществе о том, что ну процесс идет, нужны деньги — так себе мотивирует) Без обид. Я сам готов поддерживать проект и финансово и идеями, так как у меня довольно много интернет-магазинов в разработке и на поддержке, правда всё меньше на MODX, но хочется верить, что ситуация исправится. Готов поддерживать при условии, что буду видеть прогресс и развитие.
1)Хоть какой-никакой адекватный функционал управления заказами из админки, я имею ввиду, возможность создавать заказы, печатать документы по ним, адекватный пересчет всех параметров заказа (состав, доставка, оплата, скидки), также нужен минимальный функционал выйти на связь с клиентом, хотя бы через отправку E-mail. Сегодня чтобы это реализовать нужно поставить минимум 6 дополнений, которые сломают интерфейс окна заказа, так как каждое добавляет свои поля и настройки в extjs как попало, потому что нет регламента расширения интерфейса окна заказа. Приходится лезть в исходники extjs этих компонентов и переписывать их.
2)Заложенная в коробку и продуманная система скидок/подарков/бонусов — это ключевой блок, на котором разработчики смогут зарабатывать на своих дополнениях. То, что сейчас есть, куча дополнений, где каждое считает несогласованно с другими — это проблема плохой архитектуры. Один компонент переписывает напрямую сессию, второй пытается через методы пересчитывать, в итоге один перебивает расчеты другого — полная вакханалия. Нужен четкий интерфейс для дополнений, чтобы их можно было выстраивать в логические цепочки для конечного расчета заказа. Кому-то нужно сначала применить промокод, а потом скидку от суммы, а кому-то наоборот, это должно решаться простейшим изменением порядка срабатывания и желательно не завязанного на приоритет плагина компонента. Где-то видел, уже не помню на какой платформе, решение — раздел скидок сделан в виде цепочки, куда можно перетягиванием добавлять узлы (компоненты скидок, промокодов, бонусов) — и прям мышкой можно настроить их порядок срабатывания и другие условия совместной работы, типа установка пороговой суммы при которой следующий узел будет активным. Это самое удобное решение из всех, что я видел)
3)Сосредоточиться на API, если будет полное покрытие функционала на API, это даст просто нереальную свободу, будут писать и собственные админки для менеджеров в виде пакетов на всяких Vue.js и React.js и дополнения смогут использовать всю мощь API, вместо того, чтобы придумывать свои велосипеды. Я считаю, что если магазином можно будет пользоваться на полную, просто сидя в том же Postman и посылая запросы — это будет победа и залог на хорошие перспективы развития. Не сделать это на старте — будет ситуация как с текущим miniShop2, тонны дополнений, где часть ломает работу магазина, из-за того, что не поспевают за обновлениями базы, и часть, где царит велосипедостроительство, так как нет API и четких интерфейсов. Как итог, с последней версией miniShop2 адекватно работают, на моей практике из всего modstore, ну компонентов 10-15, и то если их допилить.
4)По поводу опций товаров — я надеюсь, что ребята используют EAV для архитектуры, так как это самое популярное решение сейчас во всех топовых Ecommerce продуктах. Ну и да систему фильтрации хорошо бы тоже иметь из коробки, это неотъемлемая часть любого интернет-магазина, странно было бы видеть этот функционал отдельным компонентом вне коробки, хотя чего удивляться, сейчас он вообще в компоненте поиска по сайту запилен (mSearch2)
5)По поводу финансирования разработки — однозначно нужно завести всякие «бусти» для донатов, но чтобы деньги пошли, нужна мотивация, а для этого нужно что-то показывать, прогресс, демо, видосы, больше деталей, классная дока. Всё это в сумме может дать необходимую мотивацию поддерживать проект, а редкие посты в сообществе о том, что ну процесс идет, нужны деньги — так себе мотивирует) Без обид. Я сам готов поддерживать проект и финансово и идеями, так как у меня довольно много интернет-магазинов в разработке и на поддержке, правда всё меньше на MODX, но хочется верить, что ситуация исправится. Готов поддерживать при условии, что буду видеть прогресс и развитие.
Спасибо. Очень полезное мнение.
Насчет EAV правда не уверен.
Во первых опции и так почти по этой модели выстроены. Сущности опций привязаны к категориям, которые в свою очередь определяют какие опции будут доступны у товаров.
Во-вторых полезность EAV сильно спорна и сейчас на рынке наоборт наметилась тенденция отказа от такой модели.
Например Magento перешли к flat таблицам.
Вот хотя бы Хабр можно почитать
Насчет EAV правда не уверен.
Во первых опции и так почти по этой модели выстроены. Сущности опций привязаны к категориям, которые в свою очередь определяют какие опции будут доступны у товаров.
Во-вторых полезность EAV сильно спорна и сейчас на рынке наоборт наметилась тенденция отказа от такой модели.
Например Magento перешли к flat таблицам.
Вот хотя бы Хабр можно почитать
Да с этой статьей уже знаком, и там в первом абзаце пишут, что EAV это про универсальность, а нам по сути это и нужно, угадать какая точно архитектура будет нужна конкретному магазину нереально, EAV как коробочное решение будет решать задачу универсально, пусть и не самым эффективным образом. А если продумать и заложить возможность полной замены реализации хранения и привязки опций — это даст ещё больше удобства, просто берешь отключаешь коробочное решение, и включаешь своё — но сомневаюсь, что многие этим будут пользоваться, моя статистика показывает, что там где уже есть EAV — мало кто пытается заменить на более производительное решение, так как хватает с головой коробочного. Но если речь про многомиллионные ассортименты и просто нереальное количество опций — то я думаю тут просто не падет выбор на MODX, как на платформу в целом.
В Magento попрежнему использует EAV, но потом таки транслирует их в обычные плоские таблицы, чтобы делать быструю фильтрацию и выборки по индексам.
И тут получается нюанс, в котором жертвуем нормализацией данных, в угоду производительности и каким-то макаром нужно следить за консистентностью данных в EAV. плоских таблицах, таблицах фасетных фильтров.
И тут получается нюанс, в котором жертвуем нормализацией данных, в угоду производительности и каким-то макаром нужно следить за консистентностью данных в EAV. плоских таблицах, таблицах фасетных фильтров.
и так из хотелок можно сделать расширение таблиц
даже если не на лету, то доп. функционалом
и нормальная размерность нужна для взаимодействия с бэкофисом
т.е. если вобще параметры товара будете расширять подумайте над тем чтобы интеграция с внешними сервисами была заложена
т.е. везде по максимум guid запихнуть хуже не станет, но пригодится
даже если не на лету, то доп. функционалом
и нормальная размерность нужна для взаимодействия с бэкофисом
т.е. если вобще параметры товара будете расширять подумайте над тем чтобы интеграция с внешними сервисами была заложена
т.е. везде по максимум guid запихнуть хуже не станет, но пригодится
Чисто мое мнение.
Когда мне звонят клиенты и говорят нужен интернет-магазин, то я предлагаю MODx (Ибо я люблю его). На что они говорят «Что? мод че? Не слышал». Ибо в рейтингах данная система себя не позиционирует как интернет-магазин.
А что в мозгах обычных клиентов ассоциирует себя как хороший интернет-магазин? Тот, который имеет интеграцию с 1С. Есть замечательный модуль по интеграции с 1С, сделайте его в коробке. Опытные программисты знают, что от базы все равно толку нет, надо это докрутить, то докрутить, вот тут уже и можно модули делать. Например на модицифации товаров (msoptionprice2) для 1С продавать модуль, но в 2 раза дороже, возьмут, для бизнеса это копейки.
Да и еще остатки введите а базу. А например, остатки по складам уже модуль
Решить вопрос с созданием опцией товаров. Самое главные затыки в них:
1. Почему не делать автотранслит при создании опции товара??? Нафига людям это объяснять
2. Люди хотят нормальную сортировку этих опций. В норм магазине от 100 категорий товаров (подкатегорий). Люди мучаются делать нужный порядок опций.
Когда мне звонят клиенты и говорят нужен интернет-магазин, то я предлагаю MODx (Ибо я люблю его). На что они говорят «Что? мод че? Не слышал». Ибо в рейтингах данная система себя не позиционирует как интернет-магазин.
А что в мозгах обычных клиентов ассоциирует себя как хороший интернет-магазин? Тот, который имеет интеграцию с 1С. Есть замечательный модуль по интеграции с 1С, сделайте его в коробке. Опытные программисты знают, что от базы все равно толку нет, надо это докрутить, то докрутить, вот тут уже и можно модули делать. Например на модицифации товаров (msoptionprice2) для 1С продавать модуль, но в 2 раза дороже, возьмут, для бизнеса это копейки.
Да и еще остатки введите а базу. А например, остатки по складам уже модуль
Решить вопрос с созданием опцией товаров. Самое главные затыки в них:
1. Почему не делать автотранслит при создании опции товара??? Нафига людям это объяснять
2. Люди хотят нормальную сортировку этих опций. В норм магазине от 100 категорий товаров (подкатегорий). Люди мучаются делать нужный порядок опций.
Дело в стратегическом мышлении, посмотрите долю, которую занимает modx, и долю битры и других заточенных CMS, вы на платных дополнениях больше заработаете по оборотам.
И не правильно вы поняли мысль, остатки по складам сделать уже платным. (По одному складу бесплатным, согласитесь, что по коду там работы на пару часов от силы.)
И не правильно вы поняли мысль, остатки по складам сделать уже платным. (По одному складу бесплатным, согласитесь, что по коду там работы на пару часов от силы.)
Я, конечно, не проверял, но мне кажется ни у одного бесплатного решения для электронной коммерции из коробки интеграции с 1С нет. В целом, я согласен с тем, что базовый функционал надо расширять, так как голый MiniShop по этому параметру сильно уступает тому же OpenCart. Но приоритетнее сделать фильтрацию из коробки, избранное, сравнение товаров, а интеграции это индивидуальная потребность конкретного бизнеса. За три года работы с Modx интеграцию с 1С делал раза два, при том что магазинов сделал несколько десятков, а вот фильтры нужны были почти в каждом.
Битрикс — это львиная часть коммерческой разработки. Его ставят, т.к. разрабы хорошо на этом зарабатывают. Заказчики ставят битрикс, т.к. это стандарт. Нет денех — WP.
Modx в этой схеме давно лишний. И дело не в рекламе. А в отсутствии внятного позиционирования и отсталости продукта от рынка.
Modx в этой схеме давно лишний. И дело не в рекламе. А в отсутствии внятного позиционирования и отсталости продукта от рынка.
Под отсталостью имел в виду возможности CMS по быстрой разработке и интеграции с компонентами глобальной экосистемы.
Шаблонизаторы/темы для быстрого старта из коробки. Удобная кастомизация админки для пользователей.
Рынок быстро меняется. Торговля ушла в маркетплейсы. Сайтостроение схлопнулось. Быстрый старт — конструкторы и WP. Магазины — Битрикс. Серьезная разработка — Laravel и т.п. Я не вижу здесь места для Modx.
Сначала позиционирование. Потом маркетинг и реклама. Смысла в рекламе Modx — ноль. Новички скачают, потыкаются, и бросят, как это и сейчас происходит. Более опытные разрабы знают возможности и даже не скачают. Для кого реклама?
Вот — рынок. Здесь даже Modx не упомянули.
Шаблонизаторы/темы для быстрого старта из коробки. Удобная кастомизация админки для пользователей.
Рынок быстро меняется. Торговля ушла в маркетплейсы. Сайтостроение схлопнулось. Быстрый старт — конструкторы и WP. Магазины — Битрикс. Серьезная разработка — Laravel и т.п. Я не вижу здесь места для Modx.
Сначала позиционирование. Потом маркетинг и реклама. Смысла в рекламе Modx — ноль. Новички скачают, потыкаются, и бросят, как это и сейчас происходит. Более опытные разрабы знают возможности и даже не скачают. Для кого реклама?
Вот — рынок. Здесь даже Modx не упомянули.
Может пойти по другому пути, и найти нормальных спонсоров, которые готовы будут инвестировать в это. Да, разработчики могут поддержать, но сколько? 40-50тыс. Про спонсоров, я бы стал рассматривать таких как Тинькофф или Юмани. Чтобы в коробке стояли бесплатные их интеграции. Плюс на демо сайте может быть их реклама.
Ох, ты знаешь… в MiniShop3 с одной стороны практически ничего не происходит.
С другой — многое из того что я планировал сделать ТОЛЬКО для MiniShop3 у нас получается реализовать в MS2. К примеру сейчас более-менее активно идет развитие JS части компонента. Так что можно сказать работа потихоньку идет, позже мы готовые протестированные решения просто перенесем в MS3
С другой — многое из того что я планировал сделать ТОЛЬКО для MiniShop3 у нас получается реализовать в MS2. К примеру сейчас более-менее активно идет развитие JS части компонента. Так что можно сказать работа потихоньку идет, позже мы готовые протестированные решения просто перенесем в MS3
Я учился писать под модекс на примере минишопа. Как писать под MODX3 есть вопросы. Думал полгода подожду выйдет минишоп3 и на его примере буду ваять. Полгода прошло а минишопа3 нет. А вопросы как писать остались. И как писать под MODX3 не понятно и даже возникает вопрос стоит ли вообще под него писать. С классами и отказом от addPackage они мне изрядную свинью подложили. У меня класс прописывается в параметрах сниппета и 1 сниппет работает с любым классом модели базы. А теперь не понятно как подлючить класс. Use переменная не работает
Рекомендую обратить внимание на компонент Collections — он адаптирован под MODX3 и достаточно неплохо устроен. github.com/modmore/Collections
Также есть вводная статья тут
modx.pro/components/20322
Ну и в целом в документации MODX многое нормально расписано про MODX3
docs.modx.com/3.x/en/getting-started/upgrading-to-3.0
В целом материала хватает — странно жаловаться на эту тему
Также есть вводная статья тут
modx.pro/components/20322
Ну и в целом в документации MODX многое нормально расписано про MODX3
docs.modx.com/3.x/en/getting-started/upgrading-to-3.0
В целом материала хватает — странно жаловаться на эту тему
Мало знаю о modx3, однако знаю что он пришел к нам уже с composer
В моем понимании composer это не только менеджер пакетов но и возможность организации автозагрузки своих классов по psr.
Почему в компонентах для modx3, причем действительно хороших, классы по прежнему подключаются через require?
github.com/modmore/Collections/blob/master/core/components/collections/controllers/selection/create.class.php
В моем понимании composer это не только менеджер пакетов но и возможность организации автозагрузки своих классов по psr.
Почему в компонентах для modx3, причем действительно хороших, классы по прежнему подключаются через require?
github.com/modmore/Collections/blob/master/core/components/collections/controllers/selection/create.class.php
Потому что это компонент для MODX2 — очевидно же.
Для MODX3 лежит в отдельной ветке github.com/modmore/Collections/tree/for-3
Для MODX3 лежит в отдельной ветке github.com/modmore/Collections/tree/for-3
Как вариант)
Но там тоже самое
github.com/modmore/Collections/blob/for-3/core/components/collections/controllers/selection/create.class.php
Но там тоже самое
github.com/modmore/Collections/blob/for-3/core/components/collections/controllers/selection/create.class.php
Видимо они предусмотрели работу сразу на двух версиях. Это процессор для двойки.
А для тройки тут
github.com/modmore/Collections/blob/for-3/core/components/collections/src/Processors/Selection/Create.php
А для тройки тут
github.com/modmore/Collections/blob/for-3/core/components/collections/src/Processors/Selection/Create.php
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Здесь упомянуты:
| Компонент | Текущая версия | Закачки |
| miniShop2 | 4.4.0-pl от 06.08.2024 | 26 104 |
| mSearch2 | 1.14.11-pl от 02.05.2023 | 18 907 |
22 ноября 2024, 21:57
Лучше деинсталировать и установить новую версию. Там полностью переписан JS.
22 ноября 2024, 20:33
Фильтрация как правило предполагает точное совпадения значений, а тебе нужен поиск.
22 ноября 2024, 19:55
Все исправилось, после замены на 'parents' => $_modx->resource.id
22 ноября 2024, 09:31
А кто подскажет, как в форму Создания/Редактирования ресурса, через ms2Form, добавить возможность выбирать несоклько параметров в одном TV?
Ну то-ест...
22 ноября 2024, 08:53
если правильно понял то так
{set $rows = json_decode($_modx->resource.constructor_block, true)}
{foreach $r...
22 ноября 2024, 08:43
Подскажите, если на странице будет две формы, они будут работать? К примеру reCaptchaV3 этого сделать не может, нужно через костыль в виде скрипта, ко...
