Drupal vs Opencart

Сразу скажу, что я друпалер, поэтому перевес будет не в сторону Opencart. Но попробуем разобраться объективно.

Сравнивать CMS Drupal с Opencart довольно проблематично, т.к. первая — это CMS без какой либо специализации, в то время как Opencart написана с одной целью — быстро запустить онлайн продажи, и там нет ничего сверх обозначенной цели.

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

Начнем с условной таблицы сравнения возможностей. С одной стороны это Drupal (версии 8/9/10), с другой Opencart (v 3/4)

DrupalКритерийOpencart
даДокументация на русском языкеда
даВизуальный редакторв зачатке
twigШаблоныtwig
даМодульная архитектурав зачатке
даМультиязычностьда
даПоддержка ЧПУв зачатке
даФорумы
даБлогив зачатке
модулиинтернет-магазинда
дафайловый менеджерв зачатке
модулиплатежные системыда
модулиформы обратной связимодули
10000кол-во существующих модулей расширения, порядок 1000
модулиSEOмодули
Symphony, PHPпод капотомPHP
composerуправление зависимостямиcomposer
drushуправление из консоли
даподдержка мультисайтинга
данаследование файлов в шаблонахда
даархитектура поддерживает общепринятые практики разработки
даархитектура удобна для командной разработки

Из таблицы видно, что Opencart имеет какой то зачаточный функционал, который не касается прямо функционала магазина. И если у вас есть PHP программисты в штате, то теоретически, они вам напишут систему управления контентом в обертке движка «опенкарт».

Архитектура

Но сколько бы у вас не было оптимизма изначально, все эти мечты об «идеальном магазине на opencart» рано или поздно разобьются о последние 2 строки в таблице. Архитектура движка такова, что вы не сможете развивать проект, как это обычно принято в лучших домах силиконовой долины практиках программирования.

Поясню.

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

В Drupal — вы чаще всего просто обновляете плагин и работаете дальше с вашим проектом. И ваши доработки, также работают. И шаблон работает и изменения логики.

В Opencart — не так. Если вам очень нужны изменения, которые несет новая версия плагина. Вы будете вновь интегрировать свои доработки, шаблоны, логику.

Например, в архитектуре opencart нет такого понятия как hooks (зацепки). Hooks позволяют без изменения кода ядра или плагина, другому плагину внести изменения в результаты работы, логику, шаблоны.

Лучшие практики

Единственное, что можно выделить в Opencart как «использование общепринятых практик разработки» это применение паттерна MVC+L. Но реализация паттерна находится на зачаточном уровне, и выполнена на столько неудобно, насколько вообще может быть выполнена.

Поясню.

К примеру, вы скачиваете новый плагин. Это набор файлов, который взаимосвязан общей задачей, историей, логикой.

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

В Opencart — не так. Файлы плагина буквально размазываются ровным слоем по всему проекту. А если вы работаете над каким то модулем, то в IDE у вас будут открыты файлы из разных закоулков файловой системы, а их названия будут вас постоянно сбивать с толку.

Модули

Оба проекта имеют некоторый ассортимент модулей для расширения функций движка. То, что модулей для Opencart на порядок меньше, возможно, не показатель, т.к. и целей у движка на порядок меньше.

Проблема в том, что бесплатных качественных модулей, для opencart существует очень не много. А качество их кода чаще всего очень низкое, так как нет нормальной архитектуры, развитых API и сообщества, которое проводит тестирование и code review. Плагины едва ли могут дополнять или расширять функционал друг друга, т.к. взаимодействие между ними не организовано архитектурой. Потому они предлагают изолированный от остальных компонентов функционал и имеют описанные выше проблемы с обновлениями.

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

Еще пример.

Вы решили установить некий SEO модуль для Opencart. Например, он позволяет задавать meta поля для товаров. Но у вас есть еще и модуль блога и есть желание добавить еще одно meta поле, улучшить функцию модуля. SEO модуль ничего не знает о модуле блога и не позволяет задать произвольные meta поля. Вы ставите программисту задачу — расширить функции SEO модуля и «прикрутить» его к модулю с блогом.

Он делает свою PHP магию, и это работает.

Выходят новые версии SEO модуля и блога. Там новые нужные вам функции.

Программист ставит вас перед выбором:

  • ставим модули и теряем доработки;
  • не ставим обновленные модули, но дорабатываем нужные вам новые функции своими силами;
  • ставим модули и внедряем старые доработки снова.

Пока модуль делает именно то что вам нужно — проблем не будет.

Перспективы

Если вы планируете развитие проекта, то вас будет заботить такие вещи как — безопасность и масштабируемость.

Opencart не предлагает внутренних API, которые бы взяли на себя рутину, обеспечивающую безопасную работу с формами, файлами, архитектурой проекта. Всё отдано в руки программиста. На сколько хорошо он продумает и реализует код, хранение данных, файлов — так всё и будет.

Drupal «под капотом» содержит API всех подсистем CMS. Программист практически не сталкивается с задачами низкоуровневой организации данных, проверок форм и т.п. Его время уходит на бизнес логику и фронт-енд — то, что нужно бизнесу. О безопасности же, в основном, заботится движок.

Opencart проекты — это чаще всего труд одного программиста-фриленсера, времянки перед запуском интернет-магазина на чем то более перспективном.

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

Быстродействие

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

Drupal + Symphony — это десятки тысяч файлов сразу же, прямо из коробки. UNIX сервер, который «ворочает» сайт под drupal — должен иметь или хороший файловый кеш, или быстрый твердотельный накопитель.

Opencart в противовес — быстр и неприхотлив. Там просто нечему тормозить. Но результат может зависеть от программиста. Код легко станет уязвимым, медленным и не эффективным.

Подобие вывода

Если у вас выбор между Drupal и Opencart, то это не сложный выбор. Очевидно — Drupal.

Возможно, задача — это быстро сделать и запустить магазин, и кажется, что Opencart — то, что надо. Но Drupal также позволит вам быстро собрать и запустить магазин, но при этом будет перспектива развития.

Написать комментарий

 

Комментарии к «Drupal vs Opencart»

Понравилась статья? Есть вопросы? - пишите в комментариях.



Комментарий: