PrestaShop сейчас проходит этап, когда изменения затрагивают не отдельные функции, а сам способ, как система устроена и как с ней работают разработчики и интеграции.
Дорожная карта показывает переход от классической монолитной системы к более разделённой архитектуре, где ядро становится стабильным источником данных и бизнес-логики, а расширения и внешние системы получают больше свободы через интерфейсы API.
Текущее состояние платформы
PrestaShop 9 — это переходный релиз, в котором основная работа была направлена не на добавление возможностей, а на обновление технической базы.
Что изменилось на уровне системы:
- обновлённый стек (Symfony 6.4, современные версии PHP)
- переработанный административный интерфейс
- развитие административного API
- обновлённая тема витрины
- приведение структуры к более модульному виду
Зачем это сделано
Старая архитектура ограничивала развитие в трёх направлениях:
- сложность интеграций с внешними системами
- зависимость логики от внутренней структуры базы данных
- трудности в масштабировании и разделении компонентов
Обновление базы решает не “удобство”, а проблему долговременной поддержки и расширяемости.
Доступность интерфейсов (EAA)
В дорожной карте присутствует приведение интерфейса к требованиям европейского законодательства по доступности.
Что это означает технически
Это требования, чтобы интерфейс мог работать в разных сценариях взаимодействия:
- управление без мыши
- корректная работа с программами чтения экрана
- правильная структура HTML-разметки
- достаточная читаемость интерфейса (контраст, масштабирование)
Важно понимать
Это не отдельный модуль и не настройка.
Это ограничение на то, как должен быть построен интерфейс, чтобы он соответствовал юридическим требованиям в ЕС.
Для разработчиков это означает необходимость:
- соблюдать структуру компонентов
- избегать нестандартных элементов управления
- учитывать доступность при создании тем и модулей
Изменения в оформлении заказа
В дорожной карте отдельно выделено упрощение процесса оформления заказа.
Суть изменений
Процесс покупки постепенно сводится к единому последовательному экрану, где:
- ввод данных клиента
- выбор доставки
- выбор оплаты
объединены в одну логическую цепочку.
Причина изменений
Текущая модель с множеством шагов увеличивает вероятность того, что пользователь не завершит оформление заказа.
Изменение направлено на уменьшение количества переходов и перезагрузок состояния корзины.
Расширяемые поля сущностей
Одно из ключевых архитектурных изменений — возможность добавлять дополнительные поля к основным объектам системы.
Что это значит
Теперь можно расширять:
- товары
- заказы
- клиентов
без изменения структуры базы данных.
Как это работает концептуально
Ранее любое новое поле требовало:
- изменения базы
- правки кода
- обновления модулей
Теперь появляется слой, который позволяет хранить дополнительные данные отдельно от основной структуры.
Практический смысл
Это уменьшает зависимость разработчиков от внутренней схемы данных и снижает риск конфликтов при обновлениях.
API как основной способ взаимодействия
В дорожной карте усиливается роль API как основного способа работы с системой.
Что это означает
Большая часть операций с данными может выполняться через стандартизированные интерфейсы:
- получение данных о товарах
- управление заказами
- работа с клиентами
- интеграция внешних сервисов
Изменение подхода
Раньше значительная часть логики была связана с внутренними механизмами системы.
Теперь логика постепенно становится доступной через формализованный слой запросов.
Практическое значение
Это упрощает интеграции с:
- мобильными приложениями
- внешними системами учёта
- сервисами доставки и оплаты
Модель организаций и пользователей
В дорожной карте появляется разделение между:
- организацией
- пользователями внутри организации
- ролями и правами доступа
Что это означает
Одна установка системы может обслуживать:
- несколько сотрудников
- разные уровни доступа
- разделение ответственности
Причина появления
Это подготовка системы к сценариям, где магазином управляет не один человек, а группа пользователей с разными ролями.
Подготовка к автоматизации через внешние системы
Отдельное направление связано с подготовкой системы к интеграции с внешними автоматизированными инструментами.
Что развивается
- стандартизированные интерфейсы управления
- возможность описывать действия через структурированные вызовы
- разделение операций на безопасные и изменяющие данные
Суть изменения
Система становится пригодной для управления не только человеком, но и внешними процессами, включая автоматизированные сценарии.
Общая логика развития платформы
Если убрать детали, направление развития можно описать так:
1. Упрощение ядра
Снижение зависимости от внутренних связей и упрощение структуры.
2. Вынос взаимодействия наружу
Основной способ работы — через API.
3. Расширяемость без изменения базы
Дополнительные данные хранятся отдельно от основной схемы.
4. Поддержка сложных организационных структур
Разделение ролей и прав внутри одной системы.
PrestaShop постепенно перестраивается из системы, где основная логика жёстко связана с ядром и базой данных, в систему, где ядро выполняет роль стабильного слоя данных и правил, а вся интеграционная и пользовательская логика выносится наружу через формализованные интерфейсы.
Это делает платформу более предсказуемой для интеграций и снижает зависимость от внутренних изменений при обновлениях.
