Розробка модулів
Написання модулів — чудовий спосіб зрозуміти, як насправді працюють основи ocStore. Як і решта системи, модулі побудовано за шаблоном проєктування MVC-L. У цьому розділі описано, як за допомогою кожного з компонентів MVC-L створити адміністративну та вітринну частини модуля. Це радше теоретичний посібник; найпростіше почати з того, щоб узяти за зразок один зі стандартних модулів (наприклад, bestseller) і повторити його структуру.
Базова структура каталогів#
Файли модуля поділяються на дві частини — у теках admin і catalog. Вміст кожної теки організовано за схемою MVC-L, з тією різницею, що admin відповідає лише за адміністративну частину, а catalog — за вітрину. Користувачі модуля налаштовують його в адмінпанелі магазину. Тому файли в теці admin обробляють зміну налаштувань, відображення модуля в адмінпанелі, його встановлення та видалення тощо. Відповідно, те, як модуль виглядає й працює на вітрині, визначають файли в теці catalog.

На зображенні вище показано скелет структури каталогів, якої має дотримуватися модуль. Добрий спосіб почати — відтворити цю структуру тек і створити зазначені файли. Їхній вміст залежить від того, що має робити ваш модуль, але базову функціональність описано в розділах нижче.
Функціональність модуля в адмінпанелі#
Власник магазину, який користується вашим модулем, захоче змінювати його налаштування в адмінпанелі: обирати, у яких схемах показувати модуль, вмикати чи вимикати його, задавати специфічні для модуля параметри. Як розробник модуля ви маєте створити сторінку адмінпанелі, де модуль можна редагувати, а налаштування — додавати чи змінювати.
Усі файли адмінпанелі розташовані в теці admin/. У ній є чотири теки:
controllerviewlanguagemodel
Кожному модулю потрібен щонайменше один файл у теках view і controller. Більшості модулів також потрібні файли в теках model і language. Зазвичай ці файли мають однакову назву, лише файл представлення має інше розширення (.tpl). Розгляньмо їх по черзі.

Контролер#
Першим створюють контролер сторінки модуля в адмінпанелі. ocStore знаходить модулі автоматично, просто читаючи теку admin/controller/module. Будь-який модуль у цій теці автоматично з’являється на сторінці Модулі та у списках прав на сторінці груп користувачів. Файл контролера можна назвати, наприклад, my_module.php.
У контролері завантажують мовні файли, щоб перетворити тексти на змінні, які потім використовуються в шаблоні. На схемі вище видно, як контролер обробляє змінну $_['text'] і передає її в представлення як $text. Тут також можна використовувати різні файли моделей та їхні методи, зокрема модель вашого модуля, якщо вона є. Докладніше про завантаження файлів — у статті Завантаження файлів у контролері.
Контролер може мати метод public function install(). Його буде викликано, коли на сторінці Доповнення > Модулі натиснуто посилання Встановити. Аналогічно, метод public function uninstall() викликається при натисканні посилання Видалити. У цих методах можна створювати й прибирати все, що потрібно модулю (наприклад, таблиці бази даних або налаштування). Доброю практикою є метод uninstall(), який прибирає всі зміни, внесені модулем. Приклад коду для install() та uninstall() див. у статті Встановлення та видалення модуля.
Доступ за URL#
Контролер — єдиний компонент MVC-L, до якого в ocStore звертаються за URL. В адмінпанелі URL має вигляд /admin/index.php?route=module/my_module&token=…. Адмінпанель додає до URL токен, а посилання на вітрині його не мають. Тому контролер містить метод public function index(). Це загальнодоступна «сторінка», яка завантажується за URL і відкривається при натисканні кнопки Змінити; саме на неї надсилається форма з представлення. Надіслані дані обробляються в цьому методі й зберігаються в таблиці setting бази даних — у стандартних модулях це робиться через модель setting/setting (метод editSetting()).
Представлення#
Другий обов’язковий файл адміністративної частини модуля — представлення (view). Його створюють у теці admin/view/template/module з розширенням .tpl, як і всі файли представлень ocStore. У ньому розміщують форму, яку користувач заповнює й надсилає; вона надсилається в метод index() контролера модуля. Найпростіше створити представлення, скопіювавши подібний наявний файл і змінивши поля форми відповідно до налаштувань вашого модуля. Файл можна назвати my_module.tpl.
У представленні доступні тексти з мовного файлу, які контролер зберіг у PHP-змінних. Код для цього наведено в статті «Завантаження файлів у контролері».
Модель#
Моделі в адміністративній частині модулям потрібні нечасто. Проте якщо модуль використовує власну таблицю в базі даних або спеціальний запит для отримання даних певного формату, вам може знадобитися файл моделі. Наприклад, ви пишете модуль лічильника відвідувачів, де кожен відвідувач зберігається в таблиці з IP-адресою та кількістю відвідувань. Тоді можна створити модель із методом, що описує й створює цю додаткову таблицю в базі даних. Файл моделі розміщують у теці admin/model/module; його можна назвати my_module.php, так само як контролер і мовний файл.
Функціональність модуля на вітрині#
Вітринна частина модуля побудована за тим самим принципом, що й адміністративна. Вміст файлів значною мірою залежить від того, що має робити модуль. Модуль може використовувати будь-які наявні моделі ocStore, тож не потрібно писати власні запити до бази даних, якщо такий запит уже існує. Наприклад, модель catalog/product містить багато корисних запитів для отримання товарів. Краще користуватися цими методами, ніж винаходити велосипед.
Ключова відмінність вітринної частини полягає в тому, що файл представлення розміщується в теці catalog/view/theme/<назва_теми>/template/module. Через підтримку тем ця структура тек значно глибша, ніж для представлення в адмінпанелі: магазин може мати багато різних тем оформлення вітрини, але лише один шаблон адмінпанелі.
У вітринній частині модуля доступні збережені налаштування — як через об’єкт config контролера, так і через змінну $setting, яка передається в метод index() контролера модуля. На основі цих налаштувань можна керувати відображенням модуля на вітрині.