Александр
Спасибо за комментарий. Функционал уже достаточно большой. Основные вещи все есть, но конечно же многое еще нужно делать. Стиль кодинга - это как жену выбирать. К примеру в моделях названия файлов не index.php, но тем не менее спасибо что ознакомились.
Спасибо за комментарий. Переход на ваниллу отвязывает от JS-фреймворков вроде JQuery и позволяет в любой момент подключить любой фреймворк вроде React, Angullar, Vue без проблем по надобности локально или глобально. В современной разработке на JS переход на ваниль - это важный этап. Именно поэтому и Bootstrap5 перешли на ваниль - чтобы не быть зависимыми от фреймворков, и чтобы всегда можно было подключать в случае необходимости любой фреймворк по желанию для конкретных надобностей.
Спасибо за вопросы. Команда у нас 2 человека. Один верстает, другой пишет код. Также вместе делаем общую работу. У нас есть довольно большой опыт работы с другими движками, и поэтому мы рано или поздно пришли к своему проекту. Видения по монетизации проекта у нас есть, но они никак не связаны с продажей модулей или ограничением чего либо в движке. Т.е. сам проект как чистый опенсорс всегда будет бесплатным. Монетизация в таких проектах в нашем видении должна быть на услугах, сервисах и т.п. Описывать планы по монетизации мы не будем. Нужно сделать и будет видно. Никаких платных версий мы не планируем. Пока что вся монетизация - это добровольные пожертвования, которые могут дать люди, если сами этого захотят. Мы сосредоточены на разработке проекта.
Проект бесплатный. As is. Никто не заставляет пользоваться. Это альфа-релиз, и требовать от него продакшена не стоит. Сразу документация не делается, учитывая что все без финансирования. Штат не многолюдный у нас.
Спасибо за поддержку. Мне тоже кажется что React более подходящий вариант. Он все таки больше библиотека, нежели фреймворк.
Валюту можно также выставить по умолчанию. Кроме того у нас реализована система валют, где нет базовой привязки при изменении самой валюты, и не требуется перевыставлять цены по всему каталогу при смене базовой валюты. Достаточно указывать актуальный курс. Можно просто забивать цены в любой валюте и она будет всегда отображаться в базовой как в админке , так как в каталоге. Это как бы относительная величина, которая позволяет решить проблему смены валюты для забивки товара. Удобно бывает некоторые товары забивать в базовой величине долларами а некоторую рублями, но при этом все выведется в дефолтной валюте как менеджеру, так и покупателю. При указании цены при создании товара есть выбор валюты, и если забить в другой валюте, то отображаться будет в той, что по дефолту. Обычно при смене базовой валюты во многих современных и старых решениях нужно все цены перебить заново. Мы постарались проработать этот вопрос по своему, для большего удобства.
В админке выставляется базовый язык для магазина и язык для админки, который сохраняется на логин админа. Именно он выставляется когда заходит админ внутрь. Видимо кто-то переключал на английский, так как народ заходит из разных стран. Дашбоард у нас пока чистый, и к моменту релиза он заполнится нужной инфой в виде графиков, таблиц и т.п. что там нужно.
Да, у нас еще много работы. Пока что альфа-релиз выпущен только для ознакомления. К моменту релиза там многое добавится для полноценной работы.
Спасибо за поддержку. Если знаете платформы, где было бы актуально разместиться с описанием проекта, то буду рад совету.
Спасибо. Так как мы начинали проект в 2018, то на тот момент был Bootstrap 3, а он завязан на jQuery. В настоящий момент мы готовим js на ваниль с таким расчетом, чтобы перейти на 5 бутстрап (который тоже на ваниле). При этом после того, как решим все замены плагинов на ваниль, то получим систему, свободную от js-фреймворка, и уже можно будет выбирать на свой вкус любой фрейм или библиотеку: ReactJS, Vue, Angullar и т.п. тем, кто захочет ее подключать для своих нужд. Пока еще не вышла стабильная версия 5 бутстрапа, мы меняем свои библиотеки js, обработчики модальных окон и т.п. на ваниль. Это займет время, но зато даст возможности в разработке js-части в будущем. В принципе это описано чуть выше, но суть думаю ясна. В идеале мы оставим ваниль, а если и будем использовать современные решения, то уже не jQuery. Вероятно это будет ReactJS или что-то другое. Слишком дорого обходится завязка на фреймворк в плане долговременной поддержки и задела на будущее и нужны долгоиграющие и современные фреймы, при том чтобы они уже не глобально использовались в проекте, а локально для определенных нужд, с целью более простой их замены в случае необходимости. Проблема jQuery изначально в бутстрапе на момент начала разработки. Поэтому тогда и не использовались нынешние решения, которые более актуальны. Поэтому использовали то, что было в jQuery. Никто не думал что 5 бутстрап наконец-то эволюционирует в ваниль. А это большой шаг вперед по сравнению с конкурентными решениями. И мы намерены перейти на ваниль в ближайшее время. Я думаю к моменту выхода готового рабочего релиза 1.0 мы уже перейдем на 5 бутстрап и ваниль.
Спасибо. Я думаю нужно переопубликовать туда. P.S. там аудитория небольшая, так что думаю туда нужно специализированную статью подготовить
На хабру не попасть без инвайта. Много статей разных за все годы отправлял, но отклоняют все. Там своя каста.
Спасибо. Я еще не очень освоился на этом ресурсе, и трибуна показалась наиболее подходящей. А какой раздел Вы бы посоветовали?
В новой серии: "И тут пришла Грета Тунберг с инспекцией к Маску. А все ли так чисто и экологично?"
А че, идея интересная. Успехов автору!
Молодцы. Начали и сделали. Дальше дело за развитием и поддержкой. Главное чтобы польза была людям.
Вот блок-схема всего движка
Прикрепляю диаграмму того, как устроено MVC + L у нас. Такая схема позволяет размещать свои и сторонние библиотеки в общей папке модели. При желании свои библы можно скидывать на репу и затягивать композером. В том же опенкарте свои классы раскиданы по всему магазину. При желании конечно же можно и там все скидывать, но действий больше. В опенкарте на каждый раздел (admin, catalog, install) свои controller, view, model. У нас же все едино.
Вы правы. Это надо прокачивать. Аудиторию не выбирают а работают с ней.
Да в чем проблема... Если Вы уверены к примеру в том что Ваша идея 100% рабочая, так сделайте это или заплатите за это и станьте богатым/знаменитым. Но ведь Вы сами не уверены в своей же идее до такой степени, чтобы так рисковать и начать над ней работать. Но предлагаете мне испробовать Вашу идею. Это жизнь, люди, общество... Так мы устроены. И я Вас понимаю вполне. Вы с добрыми намерениями.
Она золотая... Спасибо за понимание.
Спасибо. Как Вы думаете, мне это интересно? Опенсорс делают потому что эта тема интересна разработчику. Если в будущем будет интересно, то я обязательно вспомню Ваш комментарий. В любом случае спасибо за то что уделили время ознакомлению с темой.
Я за Вас очень рад. Не понимаю только Вашу мотивацию тут писать.
Я не понимаю при чем тут платят и опенсорс? Мягкое твердое? Я вопринимаю критику. А Вам надо еще поучиться критике а не критиканству. Вы молодой.
Вы за меня переживаете? Или как мне это понимать?
Структура построена на статических классах, так как именно в этом проекте это удобно при такой архитектуре. Где нужно там и объекты есть, но в целом статика да, превалирует так как с ней здесь удобнее в виду именно этой архитектуры. Там отлаживать проблем нет никаких. Если потребуется объектная модель и без нее будет сложнее выполнить какую-то функцию, то применяется этот подход. Но если разработчик выбрал такой подход, то это не значит что надо за это критиковать. Кто-то любит красное, кто то зеленое. Это дело вкуса разработчика. Класс PDO потому что это обертка над PDO с mysqli (а не над mysqli), что ясно видно в классе. Так что это чистый PDO с оберткой. Абстракция не нужна так как 99% потенциальных юзеров этого движка - это MySQL на хостингах. Нет смысла держать абстракцию через ORM ради 1%. Гораздо выгоднее снизить нагрузку за счет обертки. И писанины по запросам так меньше и гибкости больше. Все что касается что бы лучше или не лучше - ребята, вам дали готовое бесплатно а все не так и не этак. Совесть имеется? Это не конкретно к Вам а вообще к этому срачу что тут развели. Все умные пришли критиканы, без своих проектов давай других чихвостить. Хлебом не корми дай только за 2 минуты глянуть гит и тут же сделать выводы о всей архитектуре. Это не серьезно, не изучив архитектуру делать безапелляционные заявления. Никто из критиканов даже не установил на локалку - на гите че то там кликнули, не нашли знакомых вещей - значит говно, давай обгажу сейчас и потешу свое самолюбие. Заминусую тут карму и буду доволен... Да мне если честно плевать на критику. Мы делаем и дальше будем делать. Собака лает а караван идет.
Спасибо. У нас в структуре движка многие запросы БД кэшированы статикой классов.Также сбор данных за счет json идет как правило с 1-2 таблиц, а не с кучи таблиц как это в других движках. Мы грузили по 1000 товаров, и не было заметно чтобы хоть как то падала производительность.
Но есть один способ запуститься на <5.7. Просто переименуйте поля json в longtext в файле /model/databases/mysql.sql Мы пока еще не используем SQL команды для поиска внутри json, и поэтому так все заработает. Поля json введены у нас для совместимости в будущем, но объекты json могут быть и в longtext для вашего случая. В целом всю обработку json мы пока ведем через парсинг строки, так как не было еще случаев чтобы использовать json-запросы. Но в будущем перейдем на них.
сейчас проверил на 7.1 - все норм без ошибок проходит... Ошибки будут в некоторых функциях, но не более... Проверьте версию mysql
P.S. Проверил с версией < 5.7 - выскочили ваши ошибки. Так как в БД нужны поля json, то они пошли уже с версии 5.7 и далее. Это пока в новинку на хостингах и не везде еще есть.
Помнится как клялись и божились что Windows 10 станет последней, и не будет меняться название. Будут только новые сборки. Билл Гей слово держит.