Переезд магазина с Joomla

Проблем тут сразу несколько. Их можно условно разбить на две группы:

1) Проблема с влиянием одного дополнения на другое.

Особенно ярко она проявляется, когда несколько дополнений затрагивают один файл. Самый банальный пример: одно дополнение заменило какой-то кусок кода на свой, а другое дополнение не смогло найти нужный код и просто не стало ничего делать. Вариант похуже, если изменения все же были внесены и сломали весь код.

Более сложный пример: в массиве товаров, который отправляется для отображения, одно дополнение добавило поле "color" и такое же поле добавило второе дополнение. И таких неявных ошибок такой подход может создать очень много.

2) Проблема с обновлением и поддержкой

Обновление плагинов и особенно движка - это ад. Ловить внезапные "ой, а у меня тут что-то вдруг не работает" - это то еще "удовольствие", особенно если дополнений несколько десятков. В итоге приходится копаться в файлах кеша и выяснять какое дополнение вызвало ошибку.

В текущем виде система событий очень ограничена. Неужели так сложно натыкать фильтров и хуков в самых критических местах как это сделано в том же WP?

Я сталкивался с магазинами, где некоторые "умельцы" использовали эти поля для меток, например. Метка товара в поле ISBN - это просто феерический костыль. Особенно яркие ощущения возникают при обновлении движка, когда эти все поля, которые заботливо были переименованы "умельцем" в админке, вновь становятся ISBN, EAN и т.д.

Основной магазина является каталог товаров. Как вы считаете, нужны ли дополнительные поля для каталога?

Скажу даже больше. Даже для возможности указания для опции своего изображения также есть дополнение. Другое дело - это заставить их всех нормально вместе работать, особенно в ситуации, когда зависимых опций несколько. Об обновлении движка лучше сразу забыть.

В том же WooCommerce, например, эта проблема решена через вариации, которые фактически являются отдельными сущностями. У них изначально есть возможность указать опции, которым они соответствуют, картинки, свои артикулы, цены (включая акционные) и многое другое. Чтобы мне добавить какое-то свое поле для вариации, мне достаточно просто написать и подключить к теме небольшой плагин. Мне не нужно в том или ином виде ковырять код системы и отхватывать все "бонусы" при обновлении. Также у меня есть возможность просто переносить этот плагин от проекта к проекту.

Зачастую для статистики используются отдельные сервисы от Яндекса или Google. Подход с дублированием товаров крайне неудобен для наполнения и продвижения. Не всем заказчикам нравится перспектива заказывать вместо 2 тысяч описаний 10.

Требования у всех разные. Как показывает практика, каждый лишний клик уменьшает конверсию. По этой причине корзина и форма заказа часто размещаются на одной странице. В мире OpenCart не так популярен как у нас: статистика.

Упс.. И часто вы его обновляете?

Вот именно, что натыкать

.

Вы путает бухгалтерскую статистику с web статисткой

Да все нормально с этим.

Как ни странно, разработчики таких модулей идут охотно на контакт.

Мне кажется, что такая же участь может настичь и филтры в wp (не берусь утверждать)

Да согласен проблема есть, проблема связана с семантикой

Если color это color, то он должен быть color, хотя в приведенном случае правильно было бы color_my или my_color

От проектов по обновлению чужих проектов на OpenCart я зачастую отказываюсь по описанным выше причинам.

Если вы о синхронизации с 1С и другими сервисами, то это совершенно иная история. В некоторых случаях наличие дублей товара с другими опциями может усложнить задачу по синхронизации.

К сожалению, мой опыт говорит об обратном.

Опции, например, - это достаточно сложный функционал. Его сложность заключается в том, что они используются во многих местах системы: они выводятся на странице товара, в корзине, используются при расчете стоимости, как-то сохраняются при заказе, отображаются в списке заказов, участвуют в управлении остатками на складе и т.д..

По этой причине подобного рода функционал нуждается в качественном тестировании. Если он входит в состав движка, то есть шансы, что его более-менее внятно протестировали и отладили.

Если речь идет о сторонних модулях, то тут возможны варианты, как говорится. К сожалению, их разработчики далеко не всегда подходят к их тестированию со всей ответственностью. Еще меньше они заморачиваются с тестированием совместимости их решений с другими схожими.

На это накладывается проблема отсутствия внятного API для опций и многих других функций. Грубо говоря, разработчикам постоянно приходится выдумывать свои костыли и изобретать велосипеды. В итоге вероятность появления ошибок очень сильно увеличивается.

На практике это мы и наблюдаем: установили несколько модулей для опций, например, они вроде как работают, но картинка в корзине не та, на почту отправляется не то, в списке заказов они отображаются не так и т.д., цену считают неправильно.

В WordPress в общем и WooCommerce в частности вероятность подобной ошибки значительно ниже. Связано это с тем, что данная система целиком и полностью построена на событиях и фильтрах. Наличие огромного количества стабильных вспомогательных функций в движке также упрощает с ним работу.

Возьмем банальнейший пример: для товара нужно добавить возможность выбора метки из списка. Сначала рассмотрим аспект разработки.

В OpenCart для этого нужно сначала добавить соответствующее поле в базе данных, добавить его в шаблон товара в админке вместе с переводами строк, написать его проверку, сохранение и вывод из базы данных. После этого нужно изменить файл модели на фронтенде, поправить контроллер, дописать в массив с товарами это поле и только после этого я смогу его выводить в шаблоне каталога. Если требуется это выводить еще в каком-то модуле, то и там тоже нужно внести эти изменения. Грубо говоря, мне нужно внести изменения в десяток файлов и базу данных, чтобы банально вывести одно несчастное поле.

В WooCommerce для реализации этого функционала мне нужно написать всего две функции: одну для отображения поля в админке и одну для его сохранения. После этого их нужно прикрепить к событиям woocommerce_product_options_general_product_data и woocommerce_process_product_meta. В функции отображения поля я могу воспользоваться функцией woocommerce_wp_select, чтобы не вбивать ручками select-ы с label-ами. Для вывода метки в любом месте шаблона я могу использовать стандартную функцию get_post_meta.

Очевидно, что в случае с OpenCart допустить ошибку на порядок проще, поскольку код движка правится в очень многих местах. В WordPress - в одном.

Второй аспект - это поддерживаемость кода. В случае с WordPress я могу без проблем вынести функции их связывание с событиями в отдельный файл темы или плагин. После этого я могу его переносить между всеми своими проектами на разных версиях WordPress и он там с огромной долей вероятности будет работать. Разработчики, которые будут после меня заниматься проектом, также смогут без лишней головной боли разобраться что тот код делает.

В случае с OpenCart мне сначала нужно внести изменения в кучу файлов, составить xml-файл с описанием что и где нужно менять. После этого нужно откатить изменения во всех файлах и проверить по кешу правильно ли отрабатывает ocmod/vqmod. На этом мои развлечения не заканчиваются. Перед началом каждого проекта на новой версии OpenCart мне нужно проверять ничего ли не сломалось, заменяется ли нужный код в нужных местах. Также мне нужно внести изменения в базу данных. Разработчику, который будет позже работать с этим всем колгоспом, также придется несладко.

Ну и последний аспект - это обновление.

В случае с WP с обновлением существенных проблем не должно возникнуть, поскольку код использует стабильные функции/API, которые разработчики крайне редко меняют. Перед этим PHPStorm еще несколько раз предупреждение выдаст, что мол такой-то функционал помечен как deprecated.

В случае с OpenCart с обновлением проблем на порядок больше. Вот захотелось Даниелю вдруг модель для продуктов поменять. Модификации, которые с этим связаны, могут тихо перестать работать, гордо сообщая при этом в логах при каждой генерации страницы. И вот имеем красивую такую "бомбочку".

Резюмируя, хочу отметить, что на данном этапе с точки зрения удобства разработки и поддержки WordPress на порядок удобнее для разработчика чем OpenCart.