Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 72
15 лет пользуемся собственным движком, написанным (на коленке) еще в 11м классе. С тех пор доработали там все, что можно было, не используя фреймворков. Летает в несколько раз быстрее большинства других магазинов за счет простой и незамысловатой логики. Но есть все, включая самое страшное зло — EAV.
Разработать с нуля — большой труд. Если у вас не команда в 10 человек с опытом или нет пяти лет на вдумчивую разработку — бросайте это гиблое дело. Что-нибудь обязательно упустите.
К слову, сейчас начали еще бОльший труд — перенос сего чуда на asp.net mvc в качестве эксперимента — проще застрелиться)
Разработать с нуля — большой труд. Если у вас не команда в 10 человек с опытом или нет пяти лет на вдумчивую разработку — бросайте это гиблое дело. Что-нибудь обязательно упустите.
К слову, сейчас начали еще бОльший труд — перенос сего чуда на asp.net mvc в качестве эксперимента — проще застрелиться)
бросайте это гиблое дело
Не успел отредактировать камент)
Бросайте это гиблое дело с разработкой велосипеда. Берите готовое решение, про которое готовы быть уверены, что оно будет существовать долгое время, и изучайте до корней и допиливайте под себя. Это проще, быстрее и даст бОльший профит за меньшее время.
В таком случае, какой фреймворк/движок порекомендуете использовать для интернет-магазинов и интернет-сервисов, работающих по подписке, где бы помимо всего прочего, были такие вещи, как партнёрка. Вопрос ко всем читателям.
Зависит от ваших привязанностей в технологиях. Если вы любите всё новое и экспериментальное, гляньте на Laravel (везде новые технологии и подходы, быстрый старт и простота поддержки). Если проверенное и поддерживаемое — Yii (вторая версия идёт в ногу со временем, а 1.1 — рабочая лошадка с кучей материала). Если фреймворк для вас — это куча компонентов — то Symfony. Если надо что-то небольшое, по-минимуму, то гляньте в микрофреймворки. Тут и Fuel и Slim и даже FatFree.
Обошёл стороной ZF, ибо он по мне не лучше Symfony. Я на нём одно время много работал. Но в нём нет ничего выделяющегося кроме его длиннющих названий классов. Не посоветую CodeIgniter и Kohana. Они одного поля ягоды и у всех не всё так гладко. Kohana подкупает своей кажущейся лёгкостью, но шаг влево, шаг вправо — расстрел. Да и ORM местный — тот ещё геммор. Да и лишнего много, придётся чуток пилить напильником.
Лично я остановился на классике: YII 1.X, jQuery + Bootstrap, MySQL, шаблоны в чистом PHP.
Из YII активно пользуюсь всем кроме CHtml. Его я не перевариваю.
Но выбр фреймворка и технологий зависит от многих факторов, так что каждому своё.
Обошёл стороной ZF, ибо он по мне не лучше Symfony. Я на нём одно время много работал. Но в нём нет ничего выделяющегося кроме его длиннющих названий классов. Не посоветую CodeIgniter и Kohana. Они одного поля ягоды и у всех не всё так гладко. Kohana подкупает своей кажущейся лёгкостью, но шаг влево, шаг вправо — расстрел. Да и ORM местный — тот ещё геммор. Да и лишнего много, придётся чуток пилить напильником.
Лично я остановился на классике: YII 1.X, jQuery + Bootstrap, MySQL, шаблоны в чистом PHP.
Из YII активно пользуюсь всем кроме CHtml. Его я не перевариваю.
Но выбр фреймворка и технологий зависит от многих факторов, так что каждому своё.
symfony, если мы про php, или подобное. знаете в чем прелесть open source framework, их пилят, не «вася» с «петей» а куча народу, плюс у вас нет привязки к БД, вы ее строите как вам удобно, да приходиться немного больше думать.
Но, если вы не хотите думать, зачем быть программистом =)
И вообще на дворе 2016 год, ребята, все стараются не привязываться к языкам программирования, микросервисы, ставка должна быть на архитектуру.
Но, если вы не хотите думать, зачем быть программистом =)
И вообще на дворе 2016 год, ребята, все стараются не привязываться к языкам программирования, микросервисы, ставка должна быть на архитектуру.
Как раз недавно изучая возможности различных фреймворков и мнения о них, остановился на Symfony. Возникает вопрос, есть ли какие-то решения для e-commerce (готовые корзины, каталоги, прайсы, заказы, партнерки и пр), которые бы в сочетании с Symfony дали бы гибкое решение, которое можно запиливать под собственные нужды?
Ну как известно Symfony это «абстрактный» framework, то есть, вы берете что-то готовое, и переопределяете его, ну, я как Symfony эксперт, не очень, но, вот же есть official bundles для Symfony bundles
В дополнение про симфони вот хороший доклад Олег Зинченко — Symfony best practices и не только
Из готовых e-commerce есть Sylius и Elcodi
Для Symfony есть Sylius. С одной стороны, много функционала уже реализовано. С другой — движок в активной разработке, можете принять участие и привнести свои идеи
А у нас недавно наоборот (почти) перенесли asp (без .net) чудо на Yii. Использовали готовый компонент корзины, но в итоге все равно 90% переписали. В целом когда есть опыт работы с движками магазинов — пилить проще. Кстати EAV не использовали (возможно пока), большинство заказов на магазины с простыми продуктами с небольшими доработками.
Да и если автор все же решится писать свой движок интернет магазина — хорошо продумайте модульность. Чтоб корзина, платежи, доставка, дисконты и прочее прочее было реализовано на интерфейсах и не зависело от конкретной реализации.
Да и если автор все же решится писать свой движок интернет магазина — хорошо продумайте модульность. Чтоб корзина, платежи, доставка, дисконты и прочее прочее было реализовано на интерфейсах и не зависело от конкретной реализации.
а что такое EAV?
Entity-Attribute-Value.
Если попросту:
1) У вас есть базовая модель (Entity) с — Id, Name, Category. Это может быть товар, например.
2) В зависимости от категории, в которой расположен товар, к базовой модели применяются определенные атрибуты (Attribute) — Возраст ребенка, Материал (для игрушек), Вес, Габариты (для большинства товаров) и тому прочее. Ну и для связки Модель-Атрибут задается значение. Это все требует как минимум трех таблиц в реляционной базе (для NoSQL баз вроде другая ситуация, я не сталкивался, честно), не считая всей логики в БД и коде для обслуживания всей этой байды. При наличии большого количества атрибутов и категорий можно столкнуться со сжиранием большого количества памяти. Выход — кеширование и оптимизация структуры.
Если попросту:
1) У вас есть базовая модель (Entity) с — Id, Name, Category. Это может быть товар, например.
2) В зависимости от категории, в которой расположен товар, к базовой модели применяются определенные атрибуты (Attribute) — Возраст ребенка, Материал (для игрушек), Вес, Габариты (для большинства товаров) и тому прочее. Ну и для связки Модель-Атрибут задается значение. Это все требует как минимум трех таблиц в реляционной базе (для NoSQL баз вроде другая ситуация, я не сталкивался, честно), не считая всей логики в БД и коде для обслуживания всей этой байды. При наличии большого количества атрибутов и категорий можно столкнуться со сжиранием большого количества памяти. Выход — кеширование и оптимизация структуры.
Любопытно. Примерно 20% проголосовавших в опросе использую движки (выбрали третий вариант ответа в опросе). Какие движки вы используете?
Для магазинов среди коробочных решений по количеству функционала («из коробки» + сторонние модули) богаче Magento на рынке ничего нет.
Не самая плохая архитектура позволяет добавлять и сопровождать любой кастомный функционал.
Единственное — очень высокий порог вхождения для того чтобы понять «как не надо делать», зато потом, при прохождении этого порога — все намного удобнее и проще чем с другими коробочными решениями для магазинов.
Не самая плохая архитектура позволяет добавлять и сопровождать любой кастомный функционал.
Единственное — очень высокий порог вхождения для того чтобы понять «как не надо делать», зато потом, при прохождении этого порога — все намного удобнее и проще чем с другими коробочными решениями для магазинов.
Я вот воздержался в опросе. Используем свой движок (допиливая под клиента) и Magento (если клиенту нужны возможности полной кастомизации продуктов, готовые расширения или клиент не уверен что дальнейшей поддержкой будем заниматься мы).
Когда я начал прорабатывать структуру для модуля монетизации интернет-сервиса (расширенные возможности по платной подписке + партнёрка), то структура данных стала сильно походить на структуру данных обычного интернет магазина. Так ли это? Есть ли какие-то некоробочные решения для подобных задач?
Как я понимаю, на своем движке у вас цена будет существенно ниже чем на Magento — верно?
C Magento не сталкивался. Поэтому сложно ответить на вопрос…
Зависит от задачи. Где больше часов работы, там и цена выше. Обычно соизмеримо.
Дело в том, что сейчас базовые знания php, js, html, mysql + свежие познания symfony позволяют создавать несложные сервисы. Вот и пытаюсь для себя понять, стоит ли дальше идти в этом направлении, создавая собственный код, используя расширения и фреймворки. Или же выбрать какой-то гибкий и функциональный движок, разобраться в нём, и уже допиливать его под все нестандартные потребности. Собственно моё смятение связано именно с этим вопросом. Выбрать, в каком направлении лучше копать.
Прежде чем писать свое решение — поработайте с готовыми. Иначе как вы сможете понять что такого надо сделать в своем движке, чего нет в имеющихся? А вдруг там есть все (ну или почти все) что вам надо и «допилить» будет в разы проще чем создавать заново?
Вроде «железная» логика — или нет?
Вроде «железная» логика — или нет?
В этом то всё и дело. Что уйдя от готовых решений в пользу чего-то своего пару лет назад, сегодня я понимаю, что в итоге создается нечто похожее на то, что и так уже было реализовано другими. Другой вопрос, что обеспечит необходимую гибкость: коробочные решения или фрейморвки с модулями?
А какая вам нужна гибкость? Все интернет магазины основаны примерно на одной и той же бизнеслогике:
Различные типы покупателей (покупают) различные типы товаров (с применением) различных типов скидок (оплачивая товары) различными методами оплаты (и указывают) различные методы доставки товара.
Для обеспечения этого используется четыре основные системы:
1. система управления товарами, пользователями, методами оплаты/доставки, правилами скидок, и прочими сущностями.
2. система учета товаров, заказов, оплат и доставок.
3. система работы с пользователями (акции, рейтинги, отзывы, голосования, расссылки) и т.п.
3. система сбора и визуализации аналитики для анализа работы вышеперечисленных систем.
В большинстве коробочных решений это все уже реализовано с помощью десятков мегабайт кода. Дополнительные типы товаров, оплат, доставок, аналитики и прочего реализованы сторонними разработчиками, а это еще десятки мегабайт кода. Многие банки, платежные системы, сервисы доставки, системы аналитики и работы с клиентами уже написали свои модули для готовых движков. Не думаю, что вам в одиночку удастся повторить все это и тем более сделать лучше чем есть в готовых решениях.
Различные типы покупателей (покупают) различные типы товаров (с применением) различных типов скидок (оплачивая товары) различными методами оплаты (и указывают) различные методы доставки товара.
Для обеспечения этого используется четыре основные системы:
1. система управления товарами, пользователями, методами оплаты/доставки, правилами скидок, и прочими сущностями.
2. система учета товаров, заказов, оплат и доставок.
3. система работы с пользователями (акции, рейтинги, отзывы, голосования, расссылки) и т.п.
3. система сбора и визуализации аналитики для анализа работы вышеперечисленных систем.
В большинстве коробочных решений это все уже реализовано с помощью десятков мегабайт кода. Дополнительные типы товаров, оплат, доставок, аналитики и прочего реализованы сторонними разработчиками, а это еще десятки мегабайт кода. Многие банки, платежные системы, сервисы доставки, системы аналитики и работы с клиентами уже написали свои модули для готовых движков. Не думаю, что вам в одиночку удастся повторить все это и тем более сделать лучше чем есть в готовых решениях.
Посмотрите ExpressionEngine, раз вас интересуют не только магазины, но и веб-сервисы в целом, может это то, что вам нужно.
Да и еще такой момент — продавать магазины на готовом популярном движке намного проще чем на самописном.
Большинство заказчиков даже готовы переплачивать за это, т.к. это сильно снижает их риски по сопровождению такого магазина.
Большинство заказчиков даже готовы переплачивать за это, т.к. это сильно снижает их риски по сопровождению такого магазина.
Любопытнее, что 72% (а особенно первые 16%) велосипедят для разработки несложных проектов. Готовые движки вполне позволяют подстраивание под конкретный проект. Они для этого и написаны и в их разработку вложены тысячи человеко-часов. И тут Вы либо собираете команду и вкладываете эти тысячи часов (что недопустимо для несложных проектов), либо кое-как кодите на коленке нечто одному Вам понятное…
Использую 2-а инструмента — или Yii или свой фреймворк, фактически состоящий из набора необходимых функций, разделения логики и отображения, модуля материалов. Готовые движки не люблю из-за того, что под реально большой или уникальный проект приходится уж много всего перепиливать…
Какие по Yii есть решения для e-commerce?
SamDark вот это написал https://github.com/samdark/yii2-shop
Правда, не могу сказать, это все-таки готовое решение для продакшна или просто крутой пример использования Yii 2.
А вообще, как показывает практика, чтобы сделать достойный e-commerce сервис, писать стоит самостоятельно, с использованием фреймворков и учитывая все особенности конкретного проекта.
Фреймворк хоть и не даст максимальной производительности, но запуститься можно будет быстрее конкурентов, а это большое дело.
Правда, не могу сказать, это все-таки готовое решение для продакшна или просто крутой пример использования Yii 2.
А вообще, как показывает практика, чтобы сделать достойный e-commerce сервис, писать стоит самостоятельно, с использованием фреймворков и учитывая все особенности конкретного проекта.
Фреймворк хоть и не даст максимальной производительности, но запуститься можно будет быстрее конкурентов, а это большое дело.
Это не решение. Это результат мастер-класса. Там даже написано:
This is example project implementing a shop created to help people learn Yii 2.0. It was created during 8 hours workshop performed in Ekaterinburg, Russia. The idea was to show how to deal with Gii, grids, filtering and other Yii 2.0 usage. It is by no means a complete shop script. It may contain bugs, shortcuts etc.
В опросе не хватает варианта
— использую свой движок / фреймворк
т.е. это не первый вариант, т.к. с нуля не пишется
2 и 3 вариант подразумевается, что инструмент не вами создан.
— использую свой движок / фреймворк
т.е. это не первый вариант, т.к. с нуля не пишется
2 и 3 вариант подразумевается, что инструмент не вами создан.
Я использую ezCatalog для интернет-магазинов. Есть практически все, что надо. Писал несколько модулей под него ещё. Все достаточно просто.
Я использовал Bitrix/OpenCart/Magento
Переносили интернет-магазин со старого PHP+ShopScript на Python+Flask и в процессе случайно ещё раз написали Django
Но вообще собрать стек «под задачу», используя микрофреймворки вроде Flask или Silex + ORM/шаблонизатор/генератор форм etc., часто бывает проще, чем перепиливать коробочное решение под заказчика.
Но вообще собрать стек «под задачу», используя микрофреймворки вроде Flask или Silex + ORM/шаблонизатор/генератор форм etc., часто бывает проще, чем перепиливать коробочное решение под заказчика.
В данный момент для магазина использую Laravel, Symfony безусловно хороша, но для магазина она перебор. Эти два фреймворка имеют отличную гибкость и огромное количество возможностей. Благодаря адекватному IOC можно заменить вообще все дефолтные возможности на что-то свое или подключить сторонние решения без проблем.
Все остальные фреймворки либо имеют слишком жесткую структуру которая лишена даже самой минимальной гибкости и создание виджета превращается в ад (Привет Yii1, ZF ), либо наоборот слишком размазаны и собрать что-то толковое из них проблемно (CodeIngiter, Kohana).
Сейчас база на mysql но мне перестало хватать его возможностей, в планах миграция на Postres.
Все остальные фреймворки либо имеют слишком жесткую структуру которая лишена даже самой минимальной гибкости и создание виджета превращается в ад (Привет Yii1, ZF ), либо наоборот слишком размазаны и собрать что-то толковое из них проблемно (CodeIngiter, Kohana).
Сейчас база на mysql но мне перестало хватать его возможностей, в планах миграция на Postres.
Если честно, то на большую тройку (WP, Drupal, Joomla) у меня аллергия.
Обслуживал сайты на этих движках в начале карьеры и то как устроена архитектура в них честно говоря меня «немного напрягало».
Сейчас они уже на много лучше но все еще не совсем то что нужно. Плюс если по желанию заказчика нужно сделать что-то не совсем стандартное то многое в этом придется приписывать. И при обновлении движка все эти правки очень весело вылетят в трубу.
Коллеги недавно обновляли Joomla до последней версии — нахватались проблем на пол месяца. Если же не обновлять то первый эксплойт — и на сайте висят веселы банера с масками гая фокса =)
Обслуживал сайты на этих движках в начале карьеры и то как устроена архитектура в них честно говоря меня «немного напрягало».
Сейчас они уже на много лучше но все еще не совсем то что нужно. Плюс если по желанию заказчика нужно сделать что-то не совсем стандартное то многое в этом придется приписывать. И при обновлении движка все эти правки очень весело вылетят в трубу.
Коллеги недавно обновляли Joomla до последней версии — нахватались проблем на пол месяца. Если же не обновлять то первый эксплойт — и на сайте висят веселы банера с масками гая фокса =)
Разрабатываем свой движок https://github.com/yupe/yupe на Yii 1.x мигрируем на Yii 2.x
Если вы опытный разработчик — напишите все сами, и будете рады. НО! Вы должны быть и «опытным», и «разработчиком» сразу, а не просто думать, что с толикой времени и мозга разберетесь во всем. Проблема будет в кол-ве времени, и в применимости на практике.
Если же нужен результат, да еще и чтобы админка была более-менее, то придется выбирать из готовых комбайнов (как бы они не были монструозны, дороги, геморойны), и из них городить либо что-то стандартное, либо кастомное.
Но это, конечно, именно разговор о ситуации, когда вам магазин нужен для дела, а не когда вы пилите код ради кода. Просто могу сказать по опыту, что «продаваны» от любого магазина могу легко захотеть вдруг (в рамках развития бизнеса) такое, что никак в исходную стройную и простую логику его работы не укладывается (пример — сложную систему скидок, скажем), и что без костылей не сделаешь. Как начинаем делать костыли — мы тут же понимаем, что наш продукт никак не лучше старого доброго монстрика из тех, что «дружат с 1С*», но только монстрика пишет команда человек в 100, а вы тут такой один, а функционал нужен чуть не завтра, и нет времени сделать под него админку, а уж про безопасность остается только молиться.
Что же касается «я возьму opensource-движок, и добавлю топор, тьфу, модули по вкусу», то тут, увы и ах, имеем низкое качество (даже нет — низкую приспособленность) модулей в их обычном виде, и необходимость платить/тратить время за/на допил их под реалии строящегося магазина. И еще неизвестно, что легче и проще в сопровождении.
Сказать по правде, мало есть магазинов, где админка была бы просто удобна. Чуть больше магазинных движков, где админка вменяема (пусть и не всегда понятна сначала), а самопис порой грешит такими косяками в работе бекэнда, что чуть не phpmyadmin впору давать в комплекте с магазином, чтобы хоть как-то он управлялся.
* Что такое «дружба с 1С», и насколько она вообще заработает в произвольно взятой фирме на из конфиге 1С и их сетапе сайта с конкретным движком — я в курсе. Просто этот лейбл («что-то там с 1С») позволяет брать деньги за движок без стеснения, так что граница проводится легко.
Если же нужен результат, да еще и чтобы админка была более-менее, то придется выбирать из готовых комбайнов (как бы они не были монструозны, дороги, геморойны), и из них городить либо что-то стандартное, либо кастомное.
Но это, конечно, именно разговор о ситуации, когда вам магазин нужен для дела, а не когда вы пилите код ради кода. Просто могу сказать по опыту, что «продаваны» от любого магазина могу легко захотеть вдруг (в рамках развития бизнеса) такое, что никак в исходную стройную и простую логику его работы не укладывается (пример — сложную систему скидок, скажем), и что без костылей не сделаешь. Как начинаем делать костыли — мы тут же понимаем, что наш продукт никак не лучше старого доброго монстрика из тех, что «дружат с 1С*», но только монстрика пишет команда человек в 100, а вы тут такой один, а функционал нужен чуть не завтра, и нет времени сделать под него админку, а уж про безопасность остается только молиться.
Что же касается «я возьму opensource-движок, и добавлю топор, тьфу, модули по вкусу», то тут, увы и ах, имеем низкое качество (даже нет — низкую приспособленность) модулей в их обычном виде, и необходимость платить/тратить время за/на допил их под реалии строящегося магазина. И еще неизвестно, что легче и проще в сопровождении.
Сказать по правде, мало есть магазинов, где админка была бы просто удобна. Чуть больше магазинных движков, где админка вменяема (пусть и не всегда понятна сначала), а самопис порой грешит такими косяками в работе бекэнда, что чуть не phpmyadmin впору давать в комплекте с магазином, чтобы хоть как-то он управлялся.
* Что такое «дружба с 1С», и насколько она вообще заработает в произвольно взятой фирме на из конфиге 1С и их сетапе сайта с конкретным движком — я в курсе. Просто этот лейбл («что-то там с 1С») позволяет брать деньги за движок без стеснения, так что граница проводится легко.
> На пути к развитию очередного проекта я решил попробовать использовать какой-нибудь фреймворк. Изучив различные варианты, выбор пал на Symfony. Благо к этому моменту я уже начал понимать принципы объектно-ориентированного программирования, поэтому раскуривание маны не заняло много времени, результатом оказался доволен. Масса рутины выполнялось за меня.
Всегда умиляют идиотичная вера в то что фреймворк может предоставить что то полезное для разработки, например конкретной используемой вещи как e-commerce.
> Проект был незамысловатый, по сути сайт с различными разделами, без авторизаций, оплат и т.п. Тем не менее, пришлось создать несколько сущностей для разных разделов (услуг, новостей и т.п.). Создавая очередную сущность я окончательно поймал себя на мысли, что мои структуры данных, идеи по их оптимизации и т.п. сильно напоминают то, что я видел в движках, которые использовал раньше.
Ну конечно, просто взять CMS Wordpress или Bitrix нельзя для этой реализации типовой части сайта (новостей услуг и прочих инфо разделов ) это же слишком просто — нужно реализовать это самому продублировать функционал на фрейморке вместо того чтобы пилить собственно сам магазин, который потом просто интегрируется в CMS.
Я уж молчу про то что этих ecommerce как собак нерезаных развелось.
Всегда умиляют идиотичная вера в то что фреймворк может предоставить что то полезное для разработки, например конкретной используемой вещи как e-commerce.
> Проект был незамысловатый, по сути сайт с различными разделами, без авторизаций, оплат и т.п. Тем не менее, пришлось создать несколько сущностей для разных разделов (услуг, новостей и т.п.). Создавая очередную сущность я окончательно поймал себя на мысли, что мои структуры данных, идеи по их оптимизации и т.п. сильно напоминают то, что я видел в движках, которые использовал раньше.
Ну конечно, просто взять CMS Wordpress или Bitrix нельзя для этой реализации типовой части сайта (новостей услуг и прочих инфо разделов ) это же слишком просто — нужно реализовать это самому продублировать функционал на фрейморке вместо того чтобы пилить собственно сам магазин, который потом просто интегрируется в CMS.
Я уж молчу про то что этих ecommerce как собак нерезаных развелось.
Один магазин мне делали на заказ на MODx, второй — пробовали писать на OpenCart, но уперлись в ограничения архитектуры. Начал ходить по рынку. В той конфигурации, что мне нужно — цена выходила 250-300к.
В итоге решил делать сам, хотя есть опыт только RESTful систем на Rails. Писать тоже стал на Rails + ActiveAdmin + PostgreSQL. Сейчас осталось только корзину допилить и все, буду запускать. Сначала к этому с опаской относился, а сейчас уже рад, что сам решился. Получился очень шустрый Интернет-магазин, поскольку структура товаров понятна — за несколько часов спокойно пишу импорт товаров из любых ИМ, прикрутил весь функционал который хотел, при этом с минимальными обращениями в базу данных. В общем, доволен. Но это решение под конкретную задачу. Делать универсальный движок я не планирую.
Единственное что — нелюбовь к frontend только усилилась. Не люблю я их, и больше всего времени уходит именно на вопросы верстки, а не логики. :(
В итоге решил делать сам, хотя есть опыт только RESTful систем на Rails. Писать тоже стал на Rails + ActiveAdmin + PostgreSQL. Сейчас осталось только корзину допилить и все, буду запускать. Сначала к этому с опаской относился, а сейчас уже рад, что сам решился. Получился очень шустрый Интернет-магазин, поскольку структура товаров понятна — за несколько часов спокойно пишу импорт товаров из любых ИМ, прикрутил весь функционал который хотел, при этом с минимальными обращениями в базу данных. В общем, доволен. Но это решение под конкретную задачу. Делать универсальный движок я не планирую.
Единственное что — нелюбовь к frontend только усилилась. Не люблю я их, и больше всего времени уходит именно на вопросы верстки, а не логики. :(
Хабр уже даже не чизкейк…
Изначально написал полностью сам поскольку время поджимало да и функционал и начальный был прост. Писал на PHP на Codeigniter, со временем разросся фичами.
Сейчас, с появлением хорошего опыта, переписываю полностью на Laravel с хорошо продуманной архитектурой.
Сейчас, с появлением хорошего опыта, переписываю полностью на Laravel с хорошо продуманной архитектурой.
Хочу еще упомянуть PrestaShop — доводилось ковыряться в нем немного, довольно функциональная админка и код вроде нормальный. А самое интересное что его потихоньку на Symfony переписывают.
Wordpress + e-commerce тема на ваш вкус + пару плагинов для Woocommerce = 50-200$ за готовый интернет-магазин.
Тяжело? В интернете ОЧЕНЬ много информации, как всё это запилить, там работы на пару дней.
О чем речь вообще, господа? :)
Тяжело? В интернете ОЧЕНЬ много информации, как всё это запилить, там работы на пару дней.
О чем речь вообще, господа? :)
Если цель — получить стандартный магазин, то вопросов нет, но на секунду предположим, что мы хотим добавить что-нибудь эдакое, что выходит за понимание стандартных функций.
Например:
— применительно для Москвы и Московской области, если доставка в МО, то предоставить клиенту возможность выбрать свой дом на карте и автоматически высчитать доплату за каждый км от МКАД, сразу включить эту доплату в стоимость доставки.
— добавить возможность пользователю самостоятельно компоновать товар и по разным хитрым схемам высчитывать стоимость (например, составная пицца)
— партнёрка, которая будет начислять баланс покупателям за покупки, совершенные по их рекомендациям
В общем любые фантазии, которые каким-то образом могут стимулировать продажи.
Не получится ли, что на конкретные задачи нет сторонних плагинов, а запиленные доработки слетят после первого же серьёзного обновления движка?
Например:
— применительно для Москвы и Московской области, если доставка в МО, то предоставить клиенту возможность выбрать свой дом на карте и автоматически высчитать доплату за каждый км от МКАД, сразу включить эту доплату в стоимость доставки.
— добавить возможность пользователю самостоятельно компоновать товар и по разным хитрым схемам высчитывать стоимость (например, составная пицца)
— партнёрка, которая будет начислять баланс покупателям за покупки, совершенные по их рекомендациям
В общем любые фантазии, которые каким-то образом могут стимулировать продажи.
Не получится ли, что на конкретные задачи нет сторонних плагинов, а запиленные доработки слетят после первого же серьёзного обновления движка?
Вам на любой платформе не найти плагины под «любые фантазии», а писать самопал — запустить сайт не «завтра», а через год, и пожалеть об этом, поняв что зря потратили время.
Тут уже писали — на популярных движках реализованы многие полезные функции, которые на самопале займут значительное время разработки.
Тут уже писали — на популярных движках реализованы многие полезные функции, которые на самопале займут значительное время разработки.
объясню подробнее — мы рассматриваем вариант не единоразового проектирования отдельно взятого интернет-магазина, а «поставить на поток». И в таком случае проще и лучше будет допилить «бложик с плагином», т.к. на выхлопе это даст куда большие возможности применения.
Я рассуждаю со своей точки зрения.
Да, magento — «царь зверей». Но у меня нет команды разработчиков, тем более компетентных. А запустить пару десятков интернет-магазинов (из них стабильно работают около 50% — до сих пор общаемся) — получилось, на «бложике с плагином».
*малый бизнес, ничего эпохального
Да, magento — «царь зверей». Но у меня нет команды разработчиков, тем более компетентных. А запустить пару десятков интернет-магазинов (из них стабильно работают около 50% — до сих пор общаемся) — получилось, на «бложике с плагином».
*малый бизнес, ничего эпохального
Использую движок Shop-Script 6. Одному написать свой движок очень проблематично. Там и выкладка, и статистика, и брошенные корзины. Товары + категории + корзина — это наверное 15% от всего функционала нормального интернет-магазина.
Свой движок можно написать на месяц и работать будет годами без пробдем
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
На пути к созданию собственного движка интернет магазина