Судя по структуре урлов в коде страниц это не так. Если бы был на Мадженто, то переезд бы не понадобился. Просто дальше ехать не куда :-). Как говориться: "Выше нас только небо, а круче нас только наши я...ца :-)".
А вы попробуйте сначала уточнить, какого экономического эффекта и в чем именно вы хотите добиться при смене движка? Какой новый функционал вам нужен, чтобы достичь желаемого экономического эффекта? Вы ведь говорите о развитии бизнеса. Но как вы его видите? В чем оно заключается? А от изменений функциональных требований со стороны безнес-процесса можно определяться и с движком. А то может и переходить не придется :-).
Ну то есть например если бы вы сказали, что вам для развития бизнеса необходим функционал сборки мебельных комплектов из элементов, то я бы порекомендовал Magento (потому что там такая возможность заложена в коробочной поставке, а в других движках этого либо вообще нет и не предвидится, либо достраивается, но с плясками святого Витта с бубном) и т.д.
Среди платных движков популярных у программистов нет :-). Они все непопулярны :-). А вообще движок нужно подбирать под функционал, а не по популярности. Я сейчас занимаюсь переносом работающего магазина с Prestashop на Magento (по параметрам в среднем раза в 3 побольше вашего). Ну геморой доложу я вам (но деваться не куда, иначе у клиента бизнес дальше не будет развиваться), так что выбирать нужно так, чтобы потом " ... не было мучительно больно ..." :-).
Популярность тут определяется не качеством, а количеством денег вбуханых в рекламу. Кроме того вы сами говорите - геморойный, и это тоже можно считать за популярность. Готовых движков с CRM среди бесплатных нет. Так что может для вас конкретно битрикс и не самое плохое решение. А платные движки все геморойные.
Это потому что этот рэйтинг - полный бред. В нем например утверждается что для создания магазинов не используются магазинные движки (в списке одни CMS общего назначения). А еще может быть по тому, что вы не дочитали его как следует. Там же внизу написано, что это обследования за период 2009-2010 годы. Этот рейтинг давно протух.
Prestashop. Opencart не подойдет. В нем с аксессуарной группировкой туго. Только престу лучше брать 1.4.
Чтобы доверять или не доверять кому-то в каком-то вопросе, нужно самому разбираться в этом вопросе. Вы ведь становитесь судьей того, что вам предлагают или делают в этом вопросе, а значит актуален вопрос: " А судьи кто?" :-).
Отличная идея! Молодцы. Плюсую :-).
Кстати вложить просьбу об отзыве в письмо об регистрации заказа не проблема. Функционал уведомления клиента о заказе по электронной почте имеет любой движок магазина. Нужно только шаблон письма поправить.
Ну поскольку вы видимо любой юмор не понимаете, то для вас любой юмор плохой :-). Бывает :-).
Целенаправленным сравнительным анализом не занимался, так что ни чего сказать не могу. PHP наиболее распространенный инструмент. Питон конечно мощнее PHP по возможностям, но он больше предназначен, как мне кажется, для разработки десктопный приложений или серверных, но не сильно связанных с HTML, точнее для AJAX приложений. PHP изначально шел как простой язык для WEB-приложений в чистом виде. Однако на питоне пишут WEB системы и очень даже серьезные и хорошие. Пример OpenERP (что-то вроде фриварного аналога 1С).
Думаю что от Питона можно добиться большей производительности, потому что если не ошибаюсь, есть варианты преобразования кода на питоне в код на С с последующей компиляцией в традиционные приложения (понятно что такое приложение будет куда шустрее чем приложение на интерпретаторе). Питон на самом деле классная вещь. Например та же OpenERP работает на собственном веб-сервере (Jango вроде тоже), то есть тут при желании можно много чего накрутить, особенно если учесть, что доступны практически все библиотеки операционки.
В общем если вы работали на Ubuntu то наверное знаете, что некоторые фишки например для настройки внешнего вида операционки там пишутся на питоне.
Ява - язык специфичный, но по возможностям сходный с питоном. Производительность во многом определяется настройками среды при запуске приложений (та же Java позволяет задавать параметры использования системных ресурсов при запуске Java-приложений). Но вообще преимущество таких языков в том, что они позволяют создавать собственные активные приложения, то есть работающие даже тогда, когда запросов от клиента не поступает. В том же PHP в некоторых случаях это бывает проблемой, когда нет возможности сделать приложения, прослушивающие системные события или состояние сетевых интерфейсов (это как правило важно при разработке мультимедийных или игровых серверов). Если бы в PHP это было, то CRON не был бы нужен :-).
Дело как правило не столько в производительности инструмента при выборе средств разработки для сайтов ИМ, сколько в скорости и легкости разработки WEB-приложений данного назначения.
На счет Ruby ни чего не могу сказать.
О нем я вообще ни чего не знаю.
То есть движки ИМ на PHP может не быстрее по производительности, но легче в кастомизации и настройках.---------- Добавлено 31.01.2014 в 18:30 ----------
Просто когда говорят о ни кому не известном движке "это лучшее из того что я видел", то чаще всего возникают сомнения, особенно если движок платный :-). Но если он не для дилетантов, то тогда понятно :-). Тогда прошу прощения. Хотя в перечисленном вами списке знакомых вам движков не было Magento :-). Вам как человеку, знакомому с ZF его код, и многие проектные решения должны понравиться :-). Особенно в сравнении с кодом OC:-).