Розробка кастомних модулів PrestaShop
Ви ведете магазин на PrestaShop 8 і зіткнулися з обмеженнями стандартного функціоналу: потрібно вивести кастомні поля в замовленні, інтегрувати CRM або змінити процес оформлення. Готові модулі або перевантажені, або не підходять архітектурно — доводиться правити ядро, що ламається при кожному оновленні. Ми проєктуємо модуль з нуля під вашу логіку: PSR-4 автозавантаження, Symfony DI та міграції БД — стек, який не потребує костилів і легко підтримується. За 5 років ми реалізували більше 30 кастомних модулів для PrestaShop, і кожен проходить тести з покриттям 80%+. Наприклад, нещодавно ми розробили модуль для інтеграції з CRM, який обробляє 10 000 замовлень на день без падіння продуктивності. Або модуль кастомного checkout, який скоротив час оформлення на 30%. Зв'яжіться з нами для оцінки вашого проєкту — ми підготуємо ТЗ за 1 день. Вартість розробки модуля під ключ — від 500€, залежно від складності.
Правильна структура модуля PrestaShop
Правильна структура модуля — запорука його підтримуваності. Ось мінімальний набір файлів і папок, який ми використовуємо в кожному проєкті. Кожен файл має свою роль: головний клас визначає реєстрацію хуків, контролери обробляють зовнішні запити, а PSR-4 класи містять бізнес-логіку. Ми дотримуємося цих правил у всіх проєктах.
| Елемент | Обов'язково | Опис |
|---|---|---|
mymodule.php |
Так | Головний клас, спадкоємець Module |
config.xml |
Ні | Метадані для автоматичного встановлення |
logo.png |
Так | Іконка 32x32 px |
controllers/front/ |
За потреби | FrontController для зовнішніх запитів |
src/ |
Для складних модулів | PSR-4 класи: Entity, Repository, Service |
views/templates/hook/ |
Для display-хуків | TPL-шаблони з Smarty |
translations/ |
Для багатомовності | Переклади модуля |
upgrade/ |
Для версіонування | SQL-міграції при оновленнях |
Ми використовуємо PSR-4 автозавантаження через composer.json, що зменшує час завантаження на 20% порівняно з застарілими autoload і дозволяє підключати сторонні бібліотеки.
Етапи розробки модуля PrestaShop
- Аналіз вимог: визначаємо, які хуки потрібні (action або display), які таблиці знадобляться, чи потрібен Symfony DI.
- Проєктування структури: створюємо головний клас, підключаємо PSR-4, налаштовуємо
composer.json. - Реалізація install/uninstall: реєструємо хуки, створюємо таблиці, додаємо конфігураційні параметри.
- Написання хуків: action-хуки для логіки, display-хуки для виведення HTML. Використовуємо Twig або Smarty.
- Підключення Symfony DI: через
config/services.ymlвизначаємо сервіси з автовайрингом — це в 5 разів спрощує підтримку порівняно зі статичними викликами. - Тестування: пишемо unit-тести для сервісів та інтеграційні для хуків. Зазвичай покриваємо 80% коду.
- Міграції: для кожного оновлення додаємо upgrade-скрипт з ALTER TABLE та міграцією даних.
- Документація та деплой: описуємо налаштування, встановлюємо модуль на цільовий сервер або в marketplace.
Головний клас і його життєвий цикл
<?php declare(strict_types=1); use PrestaShop\PrestaShop\Adapter\SymfonyContainer; if (!defined('_PS_VERSION_')) { exit; } class MyModule extends Module { public function __construct() { $this->name = 'mymodule'; $this->tab = 'other'; $this->version = '1.2.0'; $this->author = 'Company Name'; $this->need_instance = 0; $this->bootstrap = true; $this->ps_versions_compliancy = ['min' => '8.0.0', 'max' => _PS_VERSION_]; parent::__construct(); $this->displayName = $this->trans('My Module', [], 'Modules.Mymodule.Admin'); $this->description = $this->trans('Module description', [], 'Modules.Mymodule.Admin'); } public function install(): bool { return parent::install() && $this->installDb() && $this->registerHook('actionOrderStatusPostUpdate') && $this->registerHook('displayCustomerAccount') && $this->registerHook('displayHeader'); } public function uninstall(): bool { return parent::uninstall() && $this->uninstallDb(); } private function installDb(): bool { $sql = 'CREATE TABLE IF NOT EXISTS `' . _DB_PREFIX_ . 'mymodule_data` ( `id_mymodule` INT UNSIGNED NOT NULL AUTO_INCREMENT, `id_order` INT UNSIGNED NOT NULL, `payload` TEXT, `status` TINYINT(1) NOT NULL DEFAULT 0, `date_add` DATETIME NOT NULL, PRIMARY KEY (`id_mymodule`), KEY `id_order` (`id_order`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;'; return Db::getInstance()->execute($sql); } } В install() реєструються хуки та створюються таблиці. В uninstall() — їх видалення. Не забувайте про ps_versions_compliancy — модуль не встановиться на непідтримувану версію.
Хуки PrestaShop для інтеграції із зовнішніми API
Хуки поділяються на два типи: action (змінюють дані/виконують дії) та display (повертають HTML). Для інтеграції з API критичні action-хуки, наприклад actionOrderStatusPostUpdate. Він спрацьовує при зміні статусу замовлення — ідеальний момент для відправлення даних в CRM або 1С.
Для інтеграції із зовнішніми системами використовуйте action-хуки — вони не блокують відображення сторінки (офіційна документація PrestaShop).
// Display hook — повертає HTML рядок public function hookDisplayCustomerAccount(array $params): string { $customerId = (int) $this->context->customer->id; $data = $this->getCustomerData($customerId); if (empty($data)) { return ''; } $this->smarty->assign([ 'mymodule_data' => $data, 'moduleUrl' => $this->context->link->getModuleLink('mymodule', 'account'), ]); return $this->display(__FILE__, 'views/templates/hook/customer_account.tpl'); } // Action hook — модифікує дані або виконує side-effect public function hookActionOrderStatusPostUpdate(array $params): void { /** @var Order $order */ $order = $params['order']; $newStatus = $params['newOrderStatus']; if ((int) $newStatus->id === (int) Configuration::get('PS_OS_PAYMENT')) { $this->notifyExternalSystem($order); } } Ми часто використовуємо action-хуки для відправлення даних в CRM, 1С або платіжні шлюзи. Display-хуки — для виведення віджетів в особистому кабінеті.
Чому Symfony DI — обов'язковий інструмент для сучасного модуля?
PrestaShop 8 дозволяє використовувати Symfony DI через config/services.yml. Це в 5 разів спрощує підтримку порівняно зі статичними викликами. Сервіси автоматично підключаються, репозиторії отримують з'єднання з БД, логери — файловий лог.
# modules/mymodule/config/services.yml services: _defaults: autowire: true autoconfigure: true public: true MyModule\Repository\OrderDataRepository: arguments: $connection: '@doctrine.dbal.default_connection' MyModule\Service\ExternalApiService: arguments: $apiKey: '%env(MYMODULE_API_KEY)%' $logger: '@logger' Приклад Symfony-контролера back-office:
// src/Controller/Admin/OrderDataController.php namespace MyModule\Controller\Admin; use PrestaShopBundle\Controller\Admin\FrameworkBundleAdminController; use Symfony\Component\HttpFoundation\JsonResponse; use MyModule\Repository\OrderDataRepository; class OrderDataController extends FrameworkBundleAdminController { public function __construct( private readonly OrderDataRepository $repository ) {} public function indexAction(int $orderId): JsonResponse { $data = $this->repository->findByOrderId($orderId); return $this->json([ 'success' => true, 'data' => $data, ]); } } Такий контролер наслідує всю інфраструктуру PrestaShop: кеш, логування, перевірки прав.
Як виконувати міграції схеми БД?
При оновленні модуля ми використовуємо upgrade-скрипти. Це безпечніше прямих ALTER TABLE в установочному методі.
// modules/mymodule/upgrade/upgrade-1.2.0.php function upgrade_module_1_2_0(Module $module): bool { $result = Db::getInstance()->execute( 'ALTER TABLE `' . _DB_PREFIX_ . 'mymodule_data` ADD COLUMN `external_id` VARCHAR(128) NULL AFTER `id_order`, ADD INDEX `external_id` (`external_id`)' ); if ($result) { // Міграція даних Db::getInstance()->execute( 'UPDATE `' . _DB_PREFIX_ . 'mymodule_data` SET `status` = 1 WHERE `status` = 0 AND `date_add` < NOW()' ); } return (bool) $result; } Кожен upgrade-файл відповідає версії. PrestaShop виконує їх послідовно.
Що входить в розробку модуля під ключ
При замовленні модуля під ключ ми надаємо:
- Безкоштовний аналіз та ТЗ (економія до 200€)
- Головний клас з install/uninstall
- Реєстрацію хуків та їх реалізацію
- Symfony DI сервіси та контролери
- Міграції БД на кожен реліз
- Тести (unit + integration) з покриттям 80%+
- Локалізацію на 2 мови
- Документацію з налаштування
- Деплой на ваш сервер або marketplace
- Гарантія на код 6 місяців
Детальніше про хуки можна почитати в офіційній документації PrestaShop.
Терміни та вартість розробки
| Тип модуля | Приклад | Терміни | Вартість |
|---|---|---|---|
| Простий | Хуки + конфігурація | 2–4 дні | від 500€ |
| Інтеграція з API | Платіжна система, CRM | 5–10 днів | від 1 500€ |
| Кастомні сутності | CRUD в back-office | 7–14 днів | від 3 000€ |
| Складний | Кастомний checkout | 3–6 тижнів | від 8 000€ |
Щоб отримати точну оцінку вашого проєкту, зв'яжіться з нами. Ми підготуємо комерційну пропозицію протягом 1 дня безкоштовно.
Ми — команда з 5+ роками досвіду розробки модулів PrestaShop, реалізували понад 30 проєктів для клієнтів з Європи та США.







