Проблемы создания модулей для Opencart

Разберем основные трудности в написании дополнений для Opencart а также рассмотрим вопросы совместимости для разных версий

ноябрь 01 , 2018

В этой статье хотелось бы поднять вопрос о проблемах разработки модулей, их совместимости, и общие концепции в данной области.

Как мы знаем Opencart очень простая и гибкая CMS для создания интернет магазинов. В этой системе изначально заложена возможность расширения функционала. Особенно это заметно стало со второй версии Opencart где появился ocmod.

История версий и доступные для разработчика инструменты.

Opencart 1.x

Opencart 1 версии - модули

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

Как дополнение, можно было установить систему модификаций кода vqmod которая являлась как надстройка, но работала отлично. С помощью vqmod разработчик мог создать файл модификатор в xml формате где прописать какой файл(ы) редактируем, какую строку ищем и что далее делаем. Вставляем код до, после или заменяем найденную строку. Это было настоящим прорывом т.к. позволяло редактировать практически любой файл магазина.

Конечно этим активно пользовались разработчики и найти модуль без vqmod практически нереально т.к. это удобно и функционально.

Opencart 2.x

Opencart 2 версии - модули

После того как поняли что надстройка vqmod работает отлично (не без сюрпризов, но об этом ниже) в новой версии Opencart 2.0 разработчик Opencart-a Daniel Kerr решил внедрить встроенную систему модификаций ocmod которая работает практически также как и vqmod но с некими отличиями. Если ранее кеш файлов был на диске в папке vqmod/vqcache то сейчас кеш сохраняется в system/storage/modification (для OC 2.3) а сами xml в ocmod-e можно установить уже через админку и содержимое файлов xml записывается в базу данных.

Такая система установки дополнений на порядок улучшила "юзер френдли" Opencart. Теперь для установки любого модуля нет необходимости вручную что-то загружать через ftp на сервер. Со второй версии модуль достаточно установить через админку и почистить кеш модификаторов.

Opencart 3.x - кошмар для разработчика? :)

Opencart 3 версии - модули

В этой версии принципиально мало что поменялось, но конечно есть и свои улучшения, или нет? Система установки модулей не поменялась, разве что установить модуль теперь нужно только архивом (name.ocmod.zip) а не файликом (name.ocmod.xml) что достаточно неудобно из-за того что надо теперь файл упаковывать в архив, но это мелочь. 

В самой новой версии добавили возможность редактирования шаблона прямо в админке. При таком редактировании код шаблона сохраняется в базе данных, и Внимание! никакой ocmod его уже не возьмет! Вот это сюрприз. По началу я и понять не мог что происходит т.к. мой модуль ставится все ок, в кеше создается файл, но он не работает. Долго голову ломал пока не понял что дело во встроенном Theme Editor.

Проблемы при разработке и совместимость модулей для Opencart

1) Пользователи модулей

Да, это самая распространенная "проблема". Уж извините за такую трактовку. Вы покупатели модуля так сказать всегда правы, но не всегда :) Дело в том что многие не читают инструкцию в три строчки а потом забирают у автора много часов времени дергая по вопросам которые есть в описании. Или часто что-то не так настроив, установив в итоге мучаете автора. Я это к чему. Что 90% проблем уже описаны в документации или же возникают из-за того что модуль неправильно настроен. Не ленитесь читать описания.

Если ничто другое не помогает, прочтите, наконец, инструкцию! (Аксиома Кана и Орбена)

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

2) Измененный код - методы как сделать наиболее совместимые модули

Наверное 60% проблем  (по моим модулям) идет из-за того что в магазине очень измененный код. Часто на многих сайтах разработчики особо не заморачиваются вопросами совместимости и кастомизируют код до такой степени что стандартного из Opencart-a там остается очень мало. И понятно что любой модуль как минимум не станет на таком магазине с коробки.

Например часто модули подвязываются под стандартные строки

$this->load->model('catalog/category'); или же $data['product'][] = array(

Конечно, если строки будут такими:

$this->load->model( 'product/category' ); или $data['product'][$category_id][] = array(

То система модификаций нужную строку  просто не найдет и не вставит свой код. Это на уровне контроллера такое может быть. На уровне шаблона все гораздо сложнее. Ладно в контроллере мы еще можем "словить" пару строк, но в шаблоне, где очень часто своя кастомная верстка, никак не прикрепится к какой-либо строке. И понятно что о совместимости и универсальности и речи быть не может.

Как побороть кастомность кода? Есть пару рекомендаций. Первое что необходимо сделать это подвязываться к началу строки а не к строке полностью. Либо искать такие строки что наименее редко изменяются. Второе, это использовать в xml поиск по регулярному выражению. Этот метод отлично работает т.к. можно привязываться к строкам даже если они изменены. Еще метод - это делать пару вхождений в файл, как это сделано в модуле MicrodataPro 7.0. То есть подвязка идет сразу на несколько строк. Так повышается надежность подвязки модуля, ведь если строка не найдена модуль подвязывается к другой строке. Такой подход себя оправдал на одном моем модуле.

Для работы с шаблоном рекомендуется использовать привязку например к строке <?php echo $footer; ?> а js скриптом переносить блок модуля в нужное место. Понятно, что настройку куда подвязывать блок модуля можно вывести в настройки модуля.

3) Другие дополнения - как источник проблем.

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

Самая основная - это использования автором модуля метода replace в xml дополнениях. О чем речь. Например разработчик дополнения добавляет в title приставку с " - страница " . $page; То есть в пагинации добавляет номер страницы в title. Можно сделать правильно а можно и нет.

Неправильный метод: это ищем строку:

$this->document->setTitle($category_info['meta_title']);

и заменяем на:

$this->document->setTitle($category_info['meta_title'] . " - страница " . $page);

Конечно, после этого дополнение которое привязывается к строке $this->document->setTitle($category_info['meta_title']); ее просто не найдет и не поставит свой код. Вывод - одно мешает другому.

А правильно надо было бы искать строку 

$this->document->setTitle($category_info['meta_title']);

И после строки добавлять: 

$this->document->setTitle( $category_info[ 'meta_title' ] . " - страница " . $page);

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

Еще проблема может быть в том что другие модули прописывают свой код в ваш модуль. Например xml обрабатывает все файлы в папке module и ищет строку $data['product'][] = array(. А в этой папке уже есть ваш модуль и в нем есть искомая строка. Конечно код модуля пропишется в ваш и в большинстве случаев система будет ругаться на этот код. А пользователь будет обращаться к вам за помощью. Обойти это можно как и было написано выше - просто проставляя пробелы в "нужных" местах или заменяя имя переменных.

Выводы

Как видим в Opencart есть хорошая база для расширения функционала, но в ней есть свои узкие стороны. С опытом разработки модулей совместимость и качество безусловно повышается. А это на руку пользователям и самому движку.