Разработка кастомных модулей PrestaShop
Вы ведёте магазин на PrestaShop 8 и столкнулись с ограничениями стандартного функционала: нужно вывести кастомные поля в заказе, интегрировать CRM или изменить процесс оформления. Готовые модули либо перегружены, либо не подходят архитектурно — приходится править ядро, что ломается при каждом обновлении. Мы проектируем модуль с нуля под вашу логику: PSR-4 автозагрузка, Symfony DI и миграции БД — стек, который не требует костылей и легко поддерживается. За 5 лет мы реализовали более 30 кастомных модулей для PrestaShop, и каждый проходит тесты с покрытием 80%+. Например, недавно мы разработали модуль для интеграции с CRM, который обрабатывает 10 000 заказов в день без падения производительности. Или модуль кастомного checkout, который сократил время оформления на 30%. Свяжитесь с нами для оценки вашего проекта — мы подготовим ТЗ за 1 день.
Как правильно структурировать модуль 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 выполняет их последовательно.
Что входит в разработку модуля
При заказе модуля мы предоставляем:
- Архитектуру и ТЗ (бесплатно)
- Главный класс с install/uninstall
- Регистрацию хуков и их реализацию
- Symfony DI сервисы и контроллеры
- Миграции БД на каждый релиз
- Тесты (unit + integration)
- Локализацию на 2 языка
- Документацию по настройке
- Деплой на ваш сервер или marketplace
Подробнее о хуках можно почитать в официальной документации PrestaShop.
Сроки разработки
| Тип модуля | Пример | Сроки |
|---|---|---|
| Простой | Хуки + конфигурация | 2–4 дня |
| Интеграция с API | Платёжная система, CRM | 5–10 дней |
| Кастомные сущности | CRUD в back-office | 7–14 дней |
| Сложный | Кастомный checkout | 3–6 недель |
Чтобы получить точную оценку вашего проекта, свяжитесь с нами. Мы подготовим коммерческое предложение в течение 1 дня.