Migrating a PrestaShop 8 store to 9: what actually breaks

Symfony jumps from 4.4 to 6.4 and FrameworkBundleAdminController disappears. An inventory of what breaks, module by module, and of what doesn't move.

What actually breaks

Between PrestaShop 8 and 9, it is not PrestaShop that moves, it is Symfony underneath: from 4.4 to 6.4. Two major versions apart, and everything touching admin controllers takes note.

The class that disappears

The main breaking point fits in one name: FrameworkBundleAdminController. It was the base class of every admin controller in a module. It is deprecated in 9, due for removal in 10, and above all it carried a shortcut that no longer exists: $this->get(), which let you grab any service on the fly. Symfony 6.4 removed it.

Its replacement is called PrestaShopAdminController, and it imposes a different discipline: the controller becomes a declared service, its dependencies arrive through the constructor, and occasional services go through getSubscribedServices(). It is cleaner. It is also a rewrite, not a rename.

Annotations become attributes

@AdminSecurity and friends become native PHP attributes. The change is mechanical, but it touches every method of every controller.

Dependencies dropped from the core

PrestaShop 9 has done some housekeeping. If your module relied on one of these because it happened to be there, it no longer is:

• Guzzle, replaced by Symfony's HTTP client
• SwiftMailer, replaced by Symfony Mailer
• Tactician, replaced by Symfony Messenger
• several Symfony components the core no longer pulls in: Inflector, Workflow, Uid, Notifier…

Nothing stops you from declaring them yourself in the module's composer.json. But you want to see it coming rather than discover it on a live store.

The legacy context

Context::$cookie is no longer where you keep your data. The Symfony session takes over. And new contextual services — EmployeeContext, ShopContext, CurrencyContext, LanguageContext — are gradually replacing the old global context.

What does not move

Here is the good news, and it is instructive: a module with no Symfony controller has almost nothing to fear. A module built on classic hooks, with its templates and its configuration, goes through 1.7, 8 and 9 without a rewrite.

I have the proof in my own modules. The one filtering spam out of the contact form covers 1.7.6 to 9.x, and that is no feat: it simply has no admin controller. The ones that do all need the same work.

How to go about it

Take stock first. One command is enough to know what you are facing: search for FrameworkBundleAdminController across your modules. Every hit is a controller to rework, every module with no hit is a module that will go through on its own.

Then, do not go looking for the single codebase that would work everywhere. That is the subject of another post, but the conclusion fits in one sentence: two branches cost less than a compatibility layer.