PrestaShop is currently going through a phase where changes affect not individual features, but the internal structure of the system and how developers and external integrations interact with it.
The roadmap shows a transition from a classic monolithic system to a more separated architecture, where the core becomes a stable layer responsible for data and business rules, while extensions and external systems interact through standardized interfaces.
Current state of the platform
PrestaShop 9 is a transitional release where the main focus was not on adding functionality, but on updating the technical foundation of the system.
Key changes:
- updated stack (Symfony 6.4, modern PHP versions)
- redesigned back-office interface
- expanded administrative API
- updated front-office theme structure
- gradual move toward modular architecture
Why this was done
The previous architecture created limitations in three main areas:
- difficulty integrating with external systems
- strong coupling between logic and database structure
- complexity in scaling and maintaining the system
The update is not about convenience, but about long-term maintainability and extensibility.
Accessibility (EAA)
The roadmap includes compliance with European accessibility requirements.
What this means technically
It requires the interface to support different usage scenarios, including:
- operation without a mouse (keyboard-only navigation)
- compatibility with screen readers
- proper HTML structure for semantic interpretation
- sufficient readability (contrast, scaling)
Important clarification
This is not a feature or a module.
It is a set of constraints defining how the interface must be built to comply with EU legal requirements.
For developers, this means:
- following strict UI structure rules
- avoiding non-standard interface elements
- considering accessibility in themes and modules
Checkout process changes
The roadmap includes simplification of the order checkout flow.
Core idea
The ordering process is gradually being unified into a single sequential flow where:
- customer details
- delivery selection
- payment selection
are handled in one continuous process.
Reason behind this
The current multi-step process increases the chance of users abandoning the checkout before completion.
The goal is to reduce navigation steps and state transitions.
Extendable entity properties
One of the key architectural changes is the ability to add additional fields to core entities.
What this means
It becomes possible to extend:
- products
- orders
- customers
without modifying the database schema.
How it works conceptually
Previously, adding a new field required:
- database structure changes
- code modifications
- module updates
Now there is an abstraction layer that allows storing extra data separately from the core schema.
Practical impact
This reduces dependency on internal database structure and lowers the risk of conflicts during upgrades.
API as the main interaction layer
The roadmap strengthens the role of API as the primary way to interact with the system.
What this means
Most operations can be performed through standardized endpoints:
- retrieving product data
- managing orders
- handling customers
- integrating external services
Shift in approach
Earlier, much of the logic was tied directly to internal mechanisms.
Now, logic is gradually exposed through a formal interaction layer.
Practical impact
This simplifies integration with:
- mobile applications
- external ERP systems
- logistics and payment services
Organization and user model
The roadmap introduces separation between:
- organization
- users inside the organization
- roles and permissions
What this means
A single installation can support:
- multiple users
- different access levels
- distributed responsibilities
Reason for this change
This prepares the system for scenarios where store management is handled by teams rather than a single administrator.
Preparation for external automation systems
Another direction focuses on making the system compatible with external automated processes.
What is being developed
- standardized control interfaces
- structured action execution model
- separation between safe and destructive operations
Core idea
The system is being designed so that it can be operated not only by humans, but also by external automated workflows.
Overall development logic
In simplified terms, the direction of development is:
1. Simplification of the core
Reducing internal coupling and making the structure cleaner.
2. Moving interaction outward
External systems interact through APIs instead of internal logic.
3. Schema-independent extensibility
Additional data is stored outside the core database structure.
4. Support for organizational structures
Multi-user roles and permissions inside a single system.
PrestaShop is gradually evolving from a system where logic is tightly bound to its core and database into a system where the core acts as a stable engine for data and rules, while most interaction and customization is moved outward through standardized interfaces.
This makes the platform more predictable for integrations and reduces dependency on internal changes during updates.
