Написание модуля для OpenCart 3.x
OpenCart — одна из популярных CMS для магазина, но в стандартном виде в нем не очень-то много возможностей, что компенсируется большим количеством платных и бесплатных модулей. В этой статье на простом примере я постараюсь рассказать как создать свой модуль для OpenCart 3.x.
Модуль OpenCart может быть исполнен в нескольких вариантах:
- Файл-модификатор OCMOD, который изменяет уже существующие в системе файлы. Подробнее о том, как написать модификатор читайте в следующей статье.
- Набор php, twig и других файлов, которые добавляют новые возможности в системе как отдельная программа и не затрагивающие стандартный функционал.
- Комбинированный — сочетание модификатора и файлов php, twig и т.д.
В этой статье рассказывается как написать свой модуль для OpenCart добавляющий новые возможности в систему.
Начну с того, что OpenCart построен на схеме MVC (Model-View-Controller). Это значит, что модуль может состоять из следующих файлов:
- Контроллер (Controller) — php-файл, который будет вызван первым и отвечает за логику работы конкретного модуля, определяет, что именно будет делать модуль, обрабатывает взаимодействие с пользователем и т.д. Контроллер может использовать (хотя и не обязательно) Модель и Представление.
- Модель (Model) — php-файл, отвечающий за чтение и запись данных в базу данных, т.е. содержит функции для получения или сохранения данных. Файл модели не обязателен.
- Представление (View) — файл какого-то html-шаблона, который определяет каким образом будет выведена информация на экран браузера. В OpenCart 3.x для создания шаблонов применяется обработчик шаблонов Twig и поэтому файл имеют расширение .twig.
Для поддержки мультиязычности в OpenCart так же есть языковые файлы, о которых будет чуть ниже. Файлы OpenCart-а организованы по папкам, контроллеры в своих, представления в своих и т.д. Итак, для создания модуля и правильного расположения файлов, нам понядобятся следующие папки и файлы:
Кроме контроллера, модели и представления, у модуля так же обычно есть так называемые языковые файлы, которые находятся в папках:
Впринципе, если планируется только 1 язык, то можно сделать языковые файлы только для него.
Минимально, у модуля должен быть хотя бы 1 php-файл — контроллер. Остальные составляющие, впринципе, могут и отсутствовать, если модуль не работает с базой данных и ничего не выводит пользователю. Но думаю, не имеет смысла рассматривать такой модуль, т.к. таким образом, мы не сможем понять всю цепочку создания полноценного модуля.
Итак, представим, что мы разрабатываем пример модуля для OpenCart 3.x, который будет иметь административную часть (back) и пользовательскую (front). В административной части, он будет иметь лишь одну настройку «Статус», которую можно менять на Включено/Выключено. А в пользовательской части пусть просто выведет страницу с текстом «Пример модуля на OpenCart 3.x», если он включен или сообщение об ошибке, если выключен. Файлы примера модуля пусть будут иметь имя example, т.е. example.php, example.twig и т.д.
Административная часть модуля
Приведу сразу исходные тексты файлов, думаю, на примерах будет проще понять что для чего нужно. Всего их 4 шт: контроллер, модель, представление и языковой файл для русского языка. Вкратце как происходит взаимодействие напишу сразу после исходного кода.
Контроллер модуля admin/controller/extension/module/example.php
Создание контроллера предполагает чтение из базы единственной настройки — статуса (включено/выключено), выведение на экран представления (шаблона) и сохранение настройки, когда пользователь нажал соответствующую кнопку.
Модель модуля admin/model/extension/module/example.php
Создание модели подразумевает работу с базой данных, а именно сохранение и чтение данных. В данном случае, можно использовать стандартные opencart-овские методы, но при необходимости, вы конечно можете, создавать свои таблицы и сохранять и читать из них.
Языковой файл модуля admin/language/ru-ru/extension/module/example.php
Здесь все просто: нужно написать все используемые фразы и предложения и их переводы на русский, которые будут использоваться в представлении (шаблоне).
Представление (шаблон) модуля admin/view/template/extension/module/example.twig
Как упоминалось выше, для создания представлений-шаблонов, нужно использовать twig. Русскоязычную документацию можете посмотреть, например, на x-twig.ru
Теперь еще несколько слов о том, как всё примерно работает и взаимодействует.
Когда мы нажимаем на кнопку перехода в настройки модуля, в адресной строке получается адрес заканчивающийся на index.php?route=extension/module/example&user_token=123. Токен в конце соответственно будет другой. Нас интересует часть extension/module/example — именно она и говорит opencart-у, где находится файл нашего контроллера.
Получивший управление файл контроллера загружает файл-модель для обращения к базе данных, загружает языковой файл и выводит шаблон twig на экран браузера.
Обратите внимание: в первых строках контроллера и модели идут названия классов: class ControllerExtensionModuleExample extends Controller и class ModelExtensionModuleExample extends Model. Как видим, в их названиях присутствует путь к модулю и название модуля. Если назвать классы как-то иначе, ничего работать не будет.
Пользовательская часть модуля
Контроллер модуля catalog/controller/extension/module/example.php
Создание контроллера пользовательской части похоже на административную, только не нужно сохранять настройки, нужно только написать код, который вывводит информацию в зависимости от того включен модуль или нет.
Модель модуля catalog/model/extension/module/example.php
В нашем примере модель пользовательской части маленькая, т.к. нужно лищь прочитать одну настройку.
Языковой файл модуля catalog/langugage/ru-ru/extension/module/example.php
Представление (шаблон) модуля catalog/view/theme/default/template/extension/module/example.twig
Задача представления вывести на экран посетителю либо страницу с заголовком «Пример модуля на OpenCart 3.x», либо с сообщением «Модуль выключен» в зависимости от того, что выбрано в статусе модуля в его настройках.
Принцип работы пользовательской части такой же, как и административной. В адресной строке будет соответственно index.php?route=extension/module/example, что и говорит opencart-у какой файл контроллера нужно использовать и из какой папки.
В административной части и в пользовательской я использовал по 4 файла (контроллер, модель, языковой файл и представление). Однако, как я писал выше, впринципе, вы можете создать более компактный модуль, сократив количество файлов только до одного контроллера, если он всё необходимое сделает сам. Так же, можно и наоборот, написать более сложный модуль, который будет состоять из нескольких контроллеров, нескольких моделей и нескольких шаблонов.
Создание архива для загрузки модуля установщиком расширений
Когда модуль полностью готов, его лучше оформить в виде архивного файла, который OpenCart может загрузить и установить в систему. Для этого нужно создать папку upload и поместить в нее все файлы модуля со всей структурой папок в которых они находятся. Затем папку нужно упаковать в zip-архив с именем название_модуля.ocmod.zip. В примере выше получится архив example.ocmod.zip.
Теперь модуль готов для автоустановки установщиком расширений.
После установки модуля он появляется в списке модулей.
Модуль нужно активировать нажав на зеленую кнопку со знаком «плюс», после чего можно зайти в настройки модуля через синюю кнопку со знаком «карандаш».
Источник статьи: http://codernotes.ru/articles/php/napisanie-modulya-dlya-opencart-3-x.html
ocroshka
Пишем свой модуль для opencart 3.0
Сегодня мы будем готовить свой модуль для opencart с нуля. Такая необходимость часто возникает у разработчиков магазинов. Если сегодня это необходимость возникла и у вас — читаем далее
Структура файлов и директорий
Для начала нужно понимать, что opencart и его модули написаны по схеме mvc или даже mvcl. Для многих это понятная и привычная схема, но не для всех. Поэтому пару слов об mvc в opencart
M — Model. Отвечает за работу с базой данных
V — Viewer. Отвечает за отображение модуля конечному пользователю
C — Controller. Отвечает за взаимодействие между моделью и вьювером
L — Language. Отвечает за языки, для которых будет формироваться контент
Следственно у нас должен появиться набор директорий для админки и фронтэнда:
- admin/controller/extension/module
- admin/model/extension/module — не обязательно, если не предполагаются запросы к базе данных
- admin/language/ru-ru/extension/module — это для русского языка. Если нужны другие языки — нужно и для других
- admin/view/template/extension/module
- catalog/controller/extension/module
- catalog/model/extension/module — не обязательно, если не предполагаются запросы к базе данных
- catalog/language/ru-ru/extension/module- это для русского языка. Если нужны другие языки — нужно и для других
- catalog/view/theme/default/extension/module
Итого 31 (Тридцать одну!) директорию нам нужно создать. И это только для иерархии.
Неужели нет способа проще? Конечно же есть, но о нем позже. Нам же нужно понимать как устроен opencart и как он работает.
Теперь определяемся с именем модуля и его назначением. Пусть это будет «Рекомендуемые плюс» (featuredplus). А делать он будет вот что:
Рекомендовать товары покупателям в зависимости от категории, в которой они находятся.
В каждую конечную директорию (module) для контроллера, модели и языка нужно поместить php файл, а в конечную директорию вьюверов — twig файл с именем нашего модуля. Таким образом у нас получится следующая структура:
- admin/controller/extension/module/featuredplus.php
- admin/language/ru-ru/extension/module/featuredplus.php
- admin/language/en-gb/extension/module/featuredplus.php
- admin/view/template/extension/module/featuredplus.twig
- catalog/controller/extension/module/featuredplus.php
- catalog/language/ru-ru/extension/module/featuredplus.php
- catalog/language/en-gb/extension/module/featuredplus.php
- catalog/view/theme/default/extension/module/featuredplus.twig
Кто заметил, что нет файлов модели? Тот получает виртуальный леденец 😉
Как же так? — Спросите вы. Мы разве не будем брать информацию о товарах из базы данных?
Будем. Но наш модуль не будет обращаться к базе данных. Мы просто подключим в контроллере нашего модуля модель товаров opencart. А модель товаров в свою очередь берет информацию из базы данных.
Источник статьи: http://ocroshka.ru/dlya-razrabotchikov/pishem-svoj-modul-dlya-opencart-3-0/
Как написать свой модуль в OpenCart? Часть 1
Автор этой записи несколько лет назад сам искал информацию по этой теме и скажу, что материала достаточно не много. OpenCart только начал обрастать атрибутами серьезного проекта. В моем понимании это автоматизированные тесты и документация. Если у вас со знанием английского есть небольшие сложности, можно поискать и найти документацию для разработчиков на русском языке, за что ребятам большое спасибо. Кстати, проект открыт и вы тоже можете присоединиться к описанию классов и файлов, если есть свободное время и желание.
Сегодня мы напишем простой модуль для OpenCart 2.3 – самой свежей на момент написания статьи версии этого движка интернет магазина.
В качестве примера мы создадим модуль Яндекс.Метрики с админ частью по аналогии с предустановленным модулем Google Analytics. Несмотря на свою продвинутую мультиязычность, комьюнити OpenCart не особо заморачивается с поддержкой различных систем сбора аналитики (что-то кроме Google Analytics), хотя их существует множество – Яндекс.Метрика,Piwik, Adobe Marketing Cloud, Kissmetrics, Open Web Analytics и многое другое. Лично я считаю это недочетом. Давайте исправлять.
Итак, сейчас в разделе Модули->Расширения->Аналитика вы увидите следующую картину:
Мы будем добавлять новый модуль Яндекс.Метрика, взяв за основу существующий – Google Analytics. Т.е. после наших действий этот экран должен выглядеть так:
Не удивляйтесь почему модули оформлены Разделами. Дело в том, что OpenCart отлично поддерживает мультимагазин, т.е. возможность размещения на одном сервере и бекенде нескольких магазино с различными товарами, оформление и конечно же модулями (расширениями). Соответственно для каждого подмагазина (возможно) понадобится свой код счетчика.
Начинаем
Наш будущий модуль имеет сразу две части – публичную в качестве добавления кода счетчика Яндекс.Метрики на страницы и административную, где модуль можно включать-выключать, а так же вносить изменения в код счетчика. Начнем с административной части.
Административная часть модуля
Любой модуль OpenCart начинается с контроллера, т.к. движок написан на паттерне MVC. Поэтому в папке admin/controller/extension/analytics создайте новый файл yandex_metrica.php
Должно получиться так:
Теперь, начнем этот файл наполнять логикой, беря за основу находящийся уже в этой папке контроллер google_analytics.php .
Я всегда советую начинать писать модули с копирования существующих и переделывания их под себя, т.к. документация по OpenCart, особенно в части написания модулей оставляет желать лучшего.
Объявим новый класс ControllerExtensionAnalyticsYandexMetrica как дочерний глобального класса Controller , а также используя модификатор области видимости private объявим переменную в виде массива, в который будут записываться ошибки. Эта строка обязательная для корректной отладки своего модуля, а так же логирования ошибок PHP в служебный файл лога.
Далее создадим функцию index(). Эта функция исполняется при попытке прямого обращения к нашему модулю через GET запрос index.php?route=extension/analytics/yandex_metrica
Первым делом создадим файл локализации yandex_metrica.php для нашего модуля в папке /admin/language/ru-ru/extension/analytics . Все конечно понимают, что в данном случае мы создаем русскую локализацию модуля. Если вы хотите создать для английской версии, то путь немного отличается /admin/language/ en-gb /extension/analytics , эта локализация кстати базовая для OpenCart и он будет брать ее в случае отсутствия у него локализации для выбранного в настройках магазина языка.
Содержание этого файла:
Теперь мы можем вернуться к коду контроллеру и подключить этот файл локализации в наш контроллер /admin/controller/extension/analytics/yandex_metrica.php . Так же присвоим некоторым переменным значения.
Теперь добавим немного логики. Подключим Модель для работы с глобальной таблицей настроек OpenCart – setting, зададим логику обработки предупреждений и ошибок, а так же напишем что будет происходить при нажатии кнопки “Сохранить”.
Логика написанного достаточно проста. Сначала мы подключаем модель для работы с таблицей глобальных настроек OpenCart $this->load->model(‘setting/setting’); , дальше с помощью конструкции if мы задали условие, что если есть запрос методом POST и он прошел валидацию, то мы сохраняем полученные данные в БД с помощью функции модели editSetting . Обратите внимание, что функция получили в качестве параметров кроме прочего и значение store_id . Как я говорил выше, OpenCart поддерживает мультимагазин и параметр store_id позволяет разделять настройки для разных подмагазинов.
Дальше, если валидация не прошла (т.е. перемеменные $this->error[‘code’] и $this->error[‘warning’] не пустые) данные не будут сохранены, а текст ошибки выведется на странице модулей.
Давайте создадим хлебные крошки, которые потом выведем в Представлении, у нас они 3-го уровня вложенности: Главная страница админки -> Модули -> Яндекс.Метрика
Обратите внимание, что с точки зрения разработчиков OpenCart хлебные крошки нужно хранить в многомерном массиве, который потом будет выводиться в цикле foreaсh . Ничего против такого подхода не имею.
Обращаю внимание начинающих разработчиков OpenCart на булевое значение переменной true в значении переменной массива $data[‘breadcrumbs’][‘href’] . Тот, кто уже знаком с более ранними версиями OpenCart безусловно знает, что раньше там было значние SSL , например, как бы этот код выглядел в OpenCart 1.5.6.4:
Значние константы SSL, а теперь уже булевой переменной true определяет префикс http(s):// в URL Представления. Если у вас в настройках файла config.php указаны значения констант для путей с https://
Так же для полноценной работы HTTPS необходимо настроить соответствующий параметр в административной части:
Однозначно возникает вопрос, зачем так заумно решать эту задачу с HTTPS? Например, если у нас включен HTTPS для магазина, а ссылка, которую вы хотите поставить должна вести на обычный http://… Сценариев, где это может понадобиться я пока не встречал, но смею предположить, что речь идет о внешних ссылках, т.к. HTTPS зачастую включают для всего сайта целиком – административной и пользовательской части. Автор статьи настоятельно рекомендует использовать именно такой способ формирования ссылок: из Контроллера в Представление через переменную $this->url->link , т.к. в этом случае они корректно работают с ЧПУ OpenCart.
Продолжим писать код в наш контроллер. Добавим код, который будет отвечать за код ссылки кнопок Редактирования и Отмены в списке подмагазинов и определим получения токена. Токен нужен для сессии, т.к. административная часть защищена паролем.
Напишем два условия на значение полей – поля для самого кода Яндекс.Метрики и переключателя статуса Включено-Выключено.
Если есть POST запрос, то содержание переменной кода берется из значения поля формы в Представлении и передается в Контроллер, в противном случае Контроллер передает в Представление значение, которое записано в БД и получено от Модели. Аналогично происходит и с полем Статус.
Осталось дописано всего несколько строк.
Т.к. блок шапки, левой колонки и футера обрабатывается в отдельных Контроллерах, их нужно подключать отдельно, чтобы вывести в Представлении.
Последняя команда непосредственно отвечает за передачу всех данных из Контроллера в Представление.
Осталось написать еще одну функцию validate() в нашем классе модуля и можно считать, что с контроллером мы расправились.
Все конечно же понимают, что в данной функции мы проверям наличие прав на редактирование модуля, а также не попытался ли пользователь передать в Контроллер из Представления пустое поле Код. Теоретически у нас может и отсутствовать код, но для этого есть поле Статус, которым можно отключить отображение кода счетчика в клиентской части, тем самым оптимизировав вывод интерпретатором PHP кода.
Мы сэкономили на кодировке Модели для этого модуля, но т.к. Представление будет передавать нам Поля HTML с другими именами, его все таки придется создать, чем мы и займемся в следующей части этой статьи.
Источник статьи: http://netsh.pp.ua/2017/04/how-to-module-opencart/