PrestaShop 9: What Changed Under the Hood and How to Prepare Your Modules

PrestaShop 9 is the biggest architectural leap since the 1.7 series. Under the hood, the platform moved to Symfony 6.4 LTS, replaced legacy ObjectModel patterns with Doctrine ORM for core entities, and introduced a proper API Platform-powered REST API. If you maintain modules, these changes matter — and preparing now saves you a painful scramble later.

The Symfony 6.4 Shift

PrestaShop 9 ships with Symfony 6.4, which means several things for module developers:

• Service definitions must use the new autowiring conventions — the old services.yml approach still works but is deprecated
• Controller annotations are replaced by PHP 8 attributes — #[Route] instead of @Route
• Event subscribers use the #[AsEventListener] attribute for auto-registration
• The minimum PHP requirement is now 8.1, with 8.2+ recommended

The good news is that most hooks and the module system itself remain backwards-compatible. Your hookDisplayHeader() still works. But if your module registers Symfony services, admin controllers, or CQRS commands — review them carefully.

Doctrine ORM Replaces ObjectModel for Core

This is the change that catches most developers off guard. Core entities like Product, Category, and Customer are now managed via Doctrine. What this means in practice:

• Direct SQL queries against core tables still work, but the ORM layer may not see your changes immediately
• The Db::getInstance() approach is still functional for your own module tables
• If you use CQRS handlers that interact with core entities, switch to the Doctrine repository pattern
• Legacy ObjectModel subclasses for core entities are marked as deprecated

API Platform: Real REST at Last

PrestaShop 9 exposes a proper REST API built on API Platform. This replaces the aging webservice that has been around since PrestaShop 1.5. Key improvements:

• JSON:API-compliant responses with proper pagination and filtering
• OAuth 2.0 authentication with scoped access tokens
• OpenAPI documentation auto-generated from entity metadata
• Custom API resources can be added by modules using standard API Platform annotations

Migration Checklist for Module Developers

1. Test on PHP 8.1+ — remove any PHP 7.x compatibility code
2. Check your Symfony services — ensure service definitions are compatible with Symfony 6.4
3. Review CQRS handlers — switch core entity access to Doctrine repositories
4. Update admin controllers — if using Symfony controllers, migrate annotations to attributes
5. Test database operations — verify that direct SQL on core tables still behaves as expected alongside the ORM
6. Add ps_versions_compliancy — set the min/max version in your module descriptor to indicate PS9 support

What Stays the Same

Not everything is changing. The hook system, Smarty templates for front-office, the module descriptor format, and the overall directory structure remain consistent. PrestaShop's backwards-compatibility promise means most well-written modules will work with minimal adjustments.

The key takeaway: test early, update your service definitions, and lean into Doctrine where it makes sense. PrestaShop 9 is a better foundation for the long term — and modules that embrace the new patterns will be easier to maintain going forward.