Проблем тут сразу несколько. Их можно условно разбить на две группы:
1) Проблема с влиянием одного дополнения на другое.
Особенно ярко она проявляется, когда несколько дополнений затрагивают один файл. Самый банальный пример: одно дополнение заменило какой-то кусок кода на свой, а другое дополнение не смогло найти нужный код и просто не стало ничего делать. Вариант похуже, если изменения все же были внесены и сломали весь код.
Более сложный пример: в массиве товаров, который отправляется для отображения, одно дополнение добавило поле "color" и такое же поле добавило второе дополнение. И таких неявных ошибок такой подход может создать очень много.
2) Проблема с обновлением и поддержкой
Обновление плагинов и особенно движка - это ад. Ловить внезапные "ой, а у меня тут что-то вдруг не работает" - это то еще "удовольствие", особенно если дополнений несколько десятков. В итоге приходится копаться в файлах кеша и выяснять какое дополнение вызвало ошибку.
В текущем виде система событий очень ограничена. Неужели так сложно натыкать фильтров и хуков в самых критических местах как это сделано в том же WP?
Я сталкивался с магазинами, где некоторые "умельцы" использовали эти поля для меток, например. Метка товара в поле ISBN - это просто феерический костыль. Особенно яркие ощущения возникают при обновлении движка, когда эти все поля, которые заботливо были переименованы "умельцем" в админке, вновь становятся ISBN, EAN и т.д.
Основной магазина является каталог товаров. Как вы считаете, нужны ли дополнительные поля для каталога?
Скажу даже больше. Даже для возможности указания для опции своего изображения также есть дополнение. Другое дело - это заставить их всех нормально вместе работать, особенно в ситуации, когда зависимых опций несколько. Об обновлении движка лучше сразу забыть.
В том же WooCommerce, например, эта проблема решена через вариации, которые фактически являются отдельными сущностями. У них изначально есть возможность указать опции, которым они соответствуют, картинки, свои артикулы, цены (включая акционные) и многое другое. Чтобы мне добавить какое-то свое поле для вариации, мне достаточно просто написать и подключить к теме небольшой плагин. Мне не нужно в том или ином виде ковырять код системы и отхватывать все "бонусы" при обновлении. Также у меня есть возможность просто переносить этот плагин от проекта к проекту.
Зачастую для статистики используются отдельные сервисы от Яндекса или Google. Подход с дублированием товаров крайне неудобен для наполнения и продвижения. Не всем заказчикам нравится перспектива заказывать вместо 2 тысяч описаний 10.
Требования у всех разные. Как показывает практика, каждый лишний клик уменьшает конверсию. По этой причине корзина и форма заказа часто размещаются на одной странице. В мире OpenCart не так популярен как у нас: статистика.
Самый основным недостатком OpenCart и CMS на его основе является система расширений.
На данный момент основным способом изменения и дополнения функционала системы является правка исходного кода движка посредством ocmod/vqmod. Грубо говоря, в xml-ках (а в 2.х и в базе данных) описано что и где нужно заменить в коде системы. Решение само по себе крайне проблемное в плане поддержки и разработки, особенно в свете тяги разработчиков системы к переписыванию критических кусков кода.
Вот казалось бы, вышла 2.0 версия, где наконец-то добавили подобие системы событий, чтобы программист мог хоть как-то повлиять на работу системы без вмешательства в исходники. Но нет. В версии 2.2 ее полностью переписали. У меня как разработчика подобный подход вызывает целую гамму прекрасных и не очень цензурных ощущений. По этой причине я для себя принял решение пока воздержаться от запуска новых проектов на этой системе до момента стабилизации кода.
Вторым критическим минусом, который органически вытекает из первого является отсутствие возможности указать для товара собственные дополнительные поля. В самом простом случае это может быть банальная метка типа "Хит продаж", "Акция", "Новинка". Выделять под нее атрибут как-то не очень правильно и неудобно в плане наполнения.
Еще один минус - это отсутствие системы вариаций. Да, в OpenCart есть возможность добавления опций, но нет возможности указать, что вот такой-то товар есть только с такой комбинацией опций. Самый явный пример - магазины с одеждой, где у кофты есть цвет и размер. На складе может не быть определенных размеров и цветов. OpenCart эту ситуацию никак не отрабатывает. Также нет возможности указать для вариаций свой цвет, краткое описание и, что очень важно, артикул. У белой кофты он может быть один, а у такой же кофты в другом размере - совсем другой. Вот и приходится извращаться с дублированием одного и того же товара с разными опциями.
Четвертый минус - это страница оформления заказа. Я знаком с OpenCart с 2009 года. Каковой та страница была, таковой и осталась в 2016. Никаких тебе оформлений на одной странице, апселов и прочего. Вот и приходится ставить дополнительные модули для реализации этого базового функционала.
Еще один минус - это отсутствие человеческого блога для публикации тех же новостей. Да, есть достаточно много дополнений различной степени паршивости, но неужели это так сложно реализовать в рамках движка?
Шестой минус - это работа с базой данных. Да, в написании SQL-запросов ручками есть своя романтика, но неужели нельзя сделать какой-то более-менее внятный API для этого всего?
У вас объем товаров не такой большой, чтобы всерьез беспокоиться на тему производительности.
Гораздо важнее - это наличие работоспособных модулей для реализации нужных вам систем оплаты, доставки, синхронизации со всякими там 1С, выгрузками на Яндекс.Маркет и многое другое. Дело в том, что время вменяемого программиста стоит гораздо дороже чем более производительный сервер.
Второй важный фактор - это наполнение. Он отчасти перекликается с вопросами синхронизации. Чем проще админка и чем сложнее там накосячить - тем проще будет организовать ее наполнение.
Ну и третий момент - это простота поддержки. Она состоит из двух составляющих: насколько система сама по себе поддерживаема и насколько легко найти программиста, который сможет ее поддерживать за разумные деньги.
Если вам нужно запустить небольшой магазин, то и OpenCart, и WordPress + Woo - это вполне достойные варианты. Лично мне как разработчику больше нравится последняя связка. Ее легче поддерживать и расширять.
С OpenCart 2.x все гораздо веселее. Даниель с другими разработчиками в последние месяцы очень активно там все меняет и переписывает. Это начинание, конечно, похвально, но я бы не стал запускать сайт на нестабильном коде.
Вполне возможно, что указанный плагин по какой-то причине не работает, если у вас на небольшой нагрузке ложится сервер с базой данных. Проверьте записывается ли фактически кеш.
Объектный кеш также стоит включить, это совершенно другая штука.
Для существенного снижения нагрузки на базу данных вам достаточно установить на сервер расширение APC/APCu для PHP, скачать соответствующий плагин для кеширования для WordPress и включить его. Это самое простое и банальное.
Yurecm, это можно сделать с помощью команды: du -sh /путь_к_папке_с сайтами/*
Очень много придется переписывать.
IPB 2.3.6 вышел около 8 лет назад. Судя по отзывам эта CMS более-менее внятно работает на PHP 5.3. С 5.4 уже есть серьезные проблемы.
Тогда в чем заключается проблема?
На самом деле 37% всех магазинов в мире работают на связке WordPress и WooCommerce (статистика). В РФ эту связку используют в среднем 21%.
Самый существенный минус WordPress в общем и WooCommerce в частности - это производительность. В свое время я проводил серию тестов и оказалось, что OpenCart в среднем в 2-2.5 раза быстрее (на тестовой машине у меня время генерации страницы каталога составляло 0.19 секунд против 0.09 у OpenCart).
С другой стороны у WordPress и WooCommerce есть много своих достоинств. Самое основное - это существующая экосистема с огромным количеством модулей, отличной документацией и обилием информации по работе с системой.
Вторым основным достоинством является реализация системы расширений. В подавляющем большинстве случаев у разработчика есть возможность изменить поведение системы без изменений исходного кода движка. Можно настроить даже такие специфические вещи как собственные стили и кнопки в редакторе. Данное обстоятельство очень сильно упрощает обновление и поддержку системы.
Этому также способствует и стабильность кода движка. Именно благодаря ей у разработчика есть возможность планомерно разрабатывать свои дополнения, не тратя при этом много времени на адаптацию к новым версиям системы.
Описанное в трех предыдущих абзацах является основными недостатками OpenCart. У Даниеля (это один из основных разработчиков данной системы) присутствует необъяснимая тяга переписывать ключевые куски кода от версии к версии.
Казалось бы, зачем было менять способ передачи переменных в шаблон с $this->data['foo'] = $foo; в версии 1.5 на $data['foo'] = $foo; в версии 2.0? Зачем было менять способ присваивания шаблона с $this->template = 'module/module.tpl'; на $this->response->setOutput($this->load->view('module/module.tpl', $data)); ? Зачем было трогать способ подключения перевода и менять $this->data = $this->language->load('path/file'); на $data = $this->language->load('path/file'); ?
В итоге имеем то что имеем: многие модули и темы оформления для версии 1.5 не работают на 2.0, вся совместимость сломана. Этот весь цирк продолжается и в рамках 2.х версии. Достаточно просто посмотреть коммиты в репозитории на гитхабе. Как следствие, имеем вопросы в духе: "а чего это так мало хороших тем".
У PrestaShop схожая ситуация. Разработчики активно пилят версию 1.7, где собираются переходить на Symphony. Обратная совместимость со многими модулями и темами также будет нарушена. Грубо говоря, начинать новый проект на 1.6 нецелесообразно, а на 1.7 пока еще рано.
Если у вас проблема заключается в автоматизации заполнения описаний, то тут скорее-всего нужно будет писать какой-то свой скрипт. В его рамках можно реализовать различные шаблоны для описаний, их уникализацию и прочие специфичные вещи.
Вообще лучше описания заказывать у копирайтеров. Поисковые системы это оценят.
Если вы решили оставаться на версии 2.3.6, то для ее работы с интерпретатором PHP 7.0 скорее-всего придется внести кучу правок в сам движок, чтобы он более-менее внятно работал.
Вообще старые CMS с новыми версиями интерпретатора не всегда хорошо работают. У меня есть старый проект на Joomla 1.5. На новых версиях PHP она заводится очень трудно. Вот и приходится пока сидеть на 5.4.
В свое время я достаточно активно изучал этот вопрос. После перехода с PHP 5.6 на 7.0 у сайта на самом обычном WordPress с Woo и сотней товаров скорость генерации страницы увеличилась более чем в два раза. Потребление памяти также ощутимо падало.
Схожие результаты получили ребята из Badoo: Badoo перешли на PHP7 и сэкономили $1M. Вообще в PHP 7.0 переписали и оптимизировали очень многое. Об этом вышел целый цикл статей: Внутреннее представление значений в PHP7.
