Як працює OCMOD і коли магазину потрібен свій модуль

OCMOD — механізм, яким в OpenCart змінюють поведінку системи, не редагуючи файли ядра. Розуміння того, як він працює, пояснює більшість дивних ситуацій із модулями.

Ідея

Замість правити файл напряму, модифікація описує: знайди в такому файлі такий фрагмент і зроби з ним таке — заміни, встав перед ним або після. Система бере оригінальні файли, застосовує всі описані зміни й складає результат окремо. Виконується саме цей результат, а не оригінал.

Звідси випливає головна практична річ: файл, який ви редагуєте, і файл, який виконується — різні. Ви правите контролер, оновлюєте сторінку, нічого не змінюється — бо магазин виконує згенеровану копію. Потрібне оновлення списку модифікацій.

Чому модифікації «тихо не працюють»

Модифікація шукає точний фрагмент коду. Якщо в новій версії магазину цей фрагмент виглядає інакше — збігу немає, зміна не застосовується. Помилки при цьому може не бути взагалі: модуль ніби встановлений, а ефекту немає.

Друга причина — конфлікт. Дві модифікації змінюють той самий фрагмент: перша спрацювала, друга вже не знаходить оригінальний текст.

Важлива відмінність між версіями

У різних гілках механізм поводиться по-різному, і це джерело плутанини. Найголовніше: в OpenCart 4.0 механізму OCMOD немає взагалі, у 4.1 його повернули в іншому вигляді. Модифікація, написана під третю гілку, у четвертій не запрацює.

Є й тонкощі всередині гілок — наприклад, поведінка при помилці застосування. У старших версіях невдала модифікація може обірвати обробку решти, і тоді перестають працювати модулі, які ви взагалі не чіпали.

Коли потрібен свій модуль, а коли ні

Перед розробкою варто перевірити три речі: чи немає потрібного в налаштуваннях, чи не закриває задачу готове рішення, і чи можна обійтись подією замість модифікації.

Події — акуратніший механізм: вони не змінюють код, а підключаються до визначених точок. Якщо задачу можна вирішити подією, це майже завжди краще: оновлення магазину такий код не ламає.

Що зазвичай роблять модулями

Щоб було зрозуміліше, які задачі взагалі закриваються розробкою:

• Обмін даними. Вивантаження замовлень в облікову систему, підтягування залишків і цін від постачальника, синхронізація з CRM.
• Доставка й оплата. Підключення служби або платіжного сервісу, якого немає в стандартному наборі, з розрахунком вартості та відстеженням.
• Власна логіка цін. Знижки за умовами, які не описуються штатними правилами: за обсягом, за групою клієнтів, за комбінацією товарів.
• Додаткові дані. Свої поля в товарі, замовленні чи профілі клієнта — і їх виведення там, де потрібно.
• Автоматизація рутини. Те, що менеджер робить руками щодня: статуси, сповіщення, вивантаження звітів.

Ознаки якісно зробленого модуля

• Не редагує файли ядра — використовує події або акуратну модифікацію.
• Модифікація не «падає мовчки»: при невдалому застосуванні це видно.
• Не ламає інші модулі: пошук написаний так, щоб зачіпати мінімальний фрагмент.
• Переживає оновлення магазину в межах гілки.
• Немає прихованих перевірок ліцензії й звернень до чужих серверів.

Практичні правила

• Після будь-якої зміни модифікацій — оновлювати згенеровані файли, інакше зміни не діють.
• Не видаляти теку зі згенерованими файлами вручну: це не кеш, і без неї магазин перестане працювати.
• Перед оновленням версії — переглянути список модифікацій: саме вони найчастіше й ламаються.
• Перед встановленням чужого модуля — робити копію бази: відкотити зміни буває складніше, ніж здається.

Якщо потрібна конкретна доробка — це послуга розробки модуля. Коли модулі конфліктують між собою або перестали працювати після оновлення — виправлення помилок. Перед переходом на нову версію корисно прочитати про те, що ламається при міграції.