PrestaShop 9 Compatibility: All Our Modules Are Ready

PrestaShop 9 Is Here. Is Your Module Stack Ready?

PrestaShop 9 landed with the most significant architectural overhaul since the platform first adopted Symfony back in version 1.7. I have been preparing our modules for this release since the early alpha builds, and in that process I learned exactly what breaks, what silently degrades, and what store owners need to check before they even think about clicking "Upgrade."

This is not a changelog summary. This is the practical guide I wish I had when I first opened a PrestaShop 9 beta and watched half the third-party modules in my test store throw 500 errors. Whether you are a store owner evaluating your module stack, a freelance developer preparing a client migration, or an agency managing dozens of PrestaShop installations, this guide walks you through the full compatibility audit process.

What Actually Changed in PrestaShop 9 (And Why It Breaks Things)

Before you can audit your modules, you need to understand what PrestaShop 9 changed at the architectural level. These are not cosmetic updates. They are foundational shifts that touch every module interacting with the back office, the database layer, or the front-end theme.

Symfony 6.4: The Big One

PrestaShop jumped from Symfony 4.4 to Symfony 6.4. That is not an incremental update. It is a leap across two major Symfony versions, each of which introduced its own set of deprecations and removals. For module developers, the most critical consequence is how controllers work.

In Symfony 4.4, you could use $this->get('service_name') inside controllers to grab any service from the container. In Symfony 6.4, controllers must be defined as services with proper dependency injection. The old FrameworkBundleAdminController still works in PrestaShop 9, but it is officially deprecated and will be removed in PrestaShop 10. Any module that extends this class is living on borrowed time.

What this means for you: if a module's admin pages work today on PrestaShop 9 but use the legacy controller pattern, they could stop working entirely on PrestaShop 10. You want modules that have already migrated to PrestaShopAdminController with constructor injection.

Removed Libraries You Probably Depend On

PrestaShop 9 removed several libraries from its core that modules previously used for free:

• Guzzle HTTP client was replaced by Symfony's HTTP client. Any module making external API calls through Guzzle will throw a "class not found" fatal error unless it bundles its own copy.
• SwiftMailer was replaced by Symfony Mailer. Modules that send emails directly (order notifications, alerts, reports) need to use the new mailer interface.
• Tactician command bus was replaced by Symfony Messenger. Modules using CQRS patterns with Tactician need a full rewrite of their command/query handling.

The sneaky part: these failures do not always show up immediately. A module might install and display its configuration page perfectly, but crash the moment it tries to send an HTTP request or dispatch a command. You will not catch this in a quick "does it install?" test.

33 Hooks Were Removed

PrestaShop 9 removed 33 hooks. That is not a typo. Thirty-three integration points that modules previously relied on simply no longer exist. The removals fall into three categories:

• Legacy product page hooks (the entire old product editing interface was removed, taking all its hooks with it): actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before, and actionAdminSortAfter/Before
• Login controller hooks (now handled by Symfony security): actionAdminLoginControllerBefore, actionAdminLoginControllerLoginBefore/After, actionAdminLoginControllerForgotBefore/After, and actionAdminLoginControllerResetBefore/After
• Layout hooks that were tied to the old AdminController lifecycle (initHeader, initContent, initFooter, display) are effectively dead because PrestaShop 9 handles layout through Twig components

If a module registers any of these hooks, it will not crash, but the hook simply never fires. The module silently loses functionality. This is arguably worse than a crash because you might not notice for weeks that a feature stopped working.

PHP 8.1 Minimum, PHP 8.4 Recommended

PrestaShop 9 requires PHP 8.1 at minimum. This eliminates stores still running PHP 7.4 or 8.0. More importantly, it means modules must handle PHP 8.1+ features and stricter type checking. Functions that previously returned mixed types now need explicit return type declarations. Nullable parameters need the ? prefix or union types. The days of loose PHP typing are over.

I test all our modules against PHP 8.1, 8.2, 8.3, and 8.4 specifically because each minor PHP version introduces new deprecation notices that can fill your logs and, in strict error reporting environments, cause visible warnings to customers.

Advanced Stock Management: Gone

The entire Advanced Stock Management system was removed from PrestaShop 9. This includes supply orders, warehouses, and the old stock management interface. If any of your modules interact with warehouse data, supply order hooks, or the advanced stock management API, they will break. This removal also affects database tables, so modules querying stock-related tables directly will get SQL errors.

Context Singleton Deprecation

The Context singleton that every PrestaShop developer knows and loves (or tolerates) is being phased out. PrestaShop 9 introduced dedicated context services: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext, and others. Modules that use Context::getContext() still work, but modules built on modern practices should be transitioning to these dedicated services.

Translation Function No Longer Escapes HTML

This is a subtle but dangerous change. The trans() function in PrestaShop 9 no longer automatically escapes HTML entities. In previous versions, passing user input through trans() provided a layer of XSS protection almost by accident. In PrestaShop 9, modules must explicitly use htmlspecialchars() on any dynamic content passed to translations. Modules that do not update this are potentially introducing security vulnerabilities.

Hummingbird Theme and Bootstrap 5

PrestaShop 9 ships with the Hummingbird theme as default, built on Bootstrap 5. PrestaShop 9.1 further upgraded to Bootstrap 5.3.3. For any module rendering front-end templates, this means:

• Bootstrap 4 class names no longer work (e.g., .no-gutters becomes .g-0, .custom-checkbox becomes .form-check)
• Data attributes are namespaced (data-toggle becomes data-bs-toggle)
• jQuery is officially deprecated in Hummingbird and will be removed in the next major theme version. Modules relying on jQuery for front-end functionality need a migration path to vanilla JavaScript
• CSS selectors based on PrestaShop-specific classes are being replaced with data-ps-* data attributes

How to Audit Your Installed Modules: A Step-by-Step Process

Now that you understand what changed, here is the systematic process I use to evaluate module compatibility. You do not need to be a developer to follow most of these steps.

Step 1: Inventory Your Modules

Go to your PrestaShop back office, navigate to Modules > Module Manager, and export or screenshot your complete list of installed modules. For each module, note:

• Module name and current version
• Vendor/developer name
• Last update date
• Whether it is a free module, a paid module from PrestaShop Addons, or a third-party module

Categorize each module by how critical it is to your business. A payment gateway module is critical. A social sharing widget is nice-to-have. This prioritization determines your upgrade timeline.

Step 2: Check Vendor Compatibility Statements

For each module vendor, look for an explicit PrestaShop 9 compatibility statement. Here is what to look for and what the red flags are:

Green flags:

• Vendor has a blog post or changelog entry specifically mentioning PrestaShop 9.0 and 9.1 compatibility
• Module version was updated after PrestaShop 9's release date
• Vendor mentions testing against Symfony 6.4 and PHP 8.1+
• Backward compatibility with PrestaShop 8.x is maintained (shows they understand multi-version support)

Red flags:

• No mention of PrestaShop 9 anywhere on the vendor's site
• Last module update was before PrestaShop 9 alpha releases
• Vendor's other modules have not been updated either (suggests abandoned product line)
• Module description mentions "PrestaShop 1.7 compatible" without any 8.x or 9.x reference

Step 3: Inspect Module Code for Known Problem Patterns

If you have basic PHP knowledge, or your developer does, open the module files and search for these specific patterns that are guaranteed to cause problems on PrestaShop 9:

Search for $this->get( in admin controllers — This is the legacy Symfony 4.4 service access pattern. It works on PrestaShop 9 but is deprecated. Modules using this have not been modernized.

Search for use GuzzleHttp — If the module imports Guzzle but does not include it in its own vendor directory, it will break on PrestaShop 9 where Guzzle was removed from core.

Search for Swift_ or SwiftMailer — Same situation. SwiftMailer was removed from core.

Search for Tools::displayPrice — This was deprecated. Modules should use the Locale service for price formatting.

Search for data-toggle= in .tpl files — Bootstrap 4 data attributes. These should be data-bs-toggle= for Hummingbird compatibility.

Search for $.ajax or $(document) in .js files — jQuery usage. Still works on Classic theme but will break on Hummingbird when jQuery is removed.

Step 4: Set Up a Staging Environment

Never test module compatibility on your live store. Here is the minimum staging setup:

1. Clone your production database to a separate database (or use your hosting provider's staging feature)
2. Install PrestaShop 9 fresh or use the upgrade module on your cloned installation
3. Install your modules one at a time, checking the error log after each installation. The order matters: install payment and shipping modules first, then SEO modules, then cosmetic modules
4. Test each module's core functionality, not just "does the configuration page load." Place a test order. Run a product import. Generate a sitemap. Whatever the module actually does in production

Pro tip: Check your PHP error log (/var/log/php_errors.log or your hosting's error log) after each module installation. Many compatibility issues show up as PHP deprecation notices or warnings rather than outright crashes. Today's warning is tomorrow's fatal error.

Step 5: Test Front-End Rendering on Both Themes

If you are using PrestaShop 9 with the new Hummingbird theme, test every module that outputs anything on the front end. Pay special attention to:

• Checkout page modifications (payment module forms, carrier selection, address validation)
• Product page widgets (reviews, wishlists, size guides, custom fields)
• Header and footer hooks (mega menus, search bars, cart previews)
• Category page filters and sorting

If you are staying on the Classic theme, your front-end compatibility risk is lower, but Bootstrap 5 changes can still affect modules that inject their own CSS.

What to Ask Your Module Vendors

When you contact a module vendor about PrestaShop 9 compatibility, do not just ask "is it compatible?" That question gets you a yes/no answer that might be wrong. Instead, ask these specific questions:

1. "Has the module been tested on PrestaShop 9.0 AND 9.1?" — Version 9.1 introduced additional breaking changes (Bootstrap 5.3.3, jQuery deprecation, new hook changes). Testing only on 9.0 is not enough.
2. "Does the module still support PrestaShop 8.x with the same ZIP file?" — If the vendor requires a separate version for PrestaShop 9, that is a maintenance burden for you. A well-built module handles version detection internally.
3. "Have you migrated away from deprecated Symfony 4.4 patterns?" — If the vendor does not understand this question, that tells you something about their technical depth.
4. "Does the module use jQuery on the front end?" — If yes, ask about their migration timeline to vanilla JavaScript before Hummingbird drops jQuery support.
5. "What is your PHP version testing range?" — You want to hear 8.1 through 8.4, not just "PHP 8."

The Upgrade Decision Framework

Based on my experience upgrading test environments and helping store owners evaluate their readiness, here is a practical framework for deciding when to upgrade:

Upgrade now if:

• All your modules have confirmed PrestaShop 9 compatibility from their vendors
• You are running PHP 8.1+ already
• You have a staging environment where you have tested the full upgrade path
• Your theme is either Classic, Hummingbird, or a child theme of either

Wait 3-6 months if:

• One or two non-critical modules lack compatibility confirmation
• Your theme is a heavily customized third-party theme (theme vendors often lag behind on major version support)
• You rely on Advanced Stock Management (you need to find replacement workflows first)

Do not upgrade yet if:

• Critical modules (payment, shipping, ERP integration) have no PrestaShop 9 compatibility statement
• You are running PHP 7.4 or 8.0 (you need a PHP upgrade first, which is its own project)
• Your module vendor has been silent for over a year (the module may be abandoned)

How We Prepared Our Modules (A Real-World Case Study)

At mypresta.rocks, I started testing against PrestaShop 9 alpha builds months before the stable release. Here is what the process actually looked like, because I think it is instructive for understanding what "compatible" really means.

Phase 1: Automated Compatibility Scanning

I ran static analysis across every module looking for the patterns I described above: legacy controller usage, removed library imports, deprecated function calls, Bootstrap 4 classes in templates, and jQuery usage in JavaScript files. This produced a prioritized list of required changes.

Phase 2: Symfony 6.4 Migration

Every admin controller was reviewed for service container access patterns. Where modules used $this->get(), we migrated to constructor injection. Where modules extended the deprecated base controller, we updated the parent class. This was the most time-consuming phase because it touches the core architecture of every admin-facing module.

Phase 3: Hook Audit

We cross-referenced every hook registration in every module against the list of 33 removed hooks. Where modules used removed hooks, we either migrated to replacement hooks or implemented version-conditional hook registration that automatically uses the correct hook for the detected PrestaShop version.

Phase 4: Multi-Version Testing

Every module was tested on PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0, and 9.1. On each version, we tested with PHP 8.1, 8.2, 8.3, and 8.4. A single module ZIP works across all these combinations because the module detects the PrestaShop version at runtime and adapts its behavior accordingly.

This is what "backward compatible" actually means in practice. It is not two separate builds. It is one codebase that handles version differences internally.

Phase 5: Front-End Theme Testing

Every module with front-end output was tested on Classic theme and Hummingbird theme. Bootstrap class names, data attributes, and JavaScript were verified on both. Where template differences were required, we used PrestaShop's built-in version detection to load the appropriate template.

The result: all mypresta.rocks modules are fully compatible with PrestaShop 9.0 and 9.1, while maintaining backward compatibility with PrestaShop 1.7.6+ and all 8.x versions. No separate downloads, no special installation steps, no "PrestaShop 9 edition" pricing.

Common Post-Upgrade Issues and How to Fix Them

Even with compatible modules, you might encounter these issues after upgrading to PrestaShop 9:

White Screen / 500 Error After Module Installation

Usually caused by a missing Composer dependency. Check your PHP error log for "Class not found" errors. The fix is either updating the module (if the vendor has a new version) or manually adding the missing library to the module's vendor directory.

Admin Pages Load But Features Are Missing

This is the silent hook removal problem. The module installed successfully, but its hooks no longer fire on PrestaShop 9. Check the module's hook registrations against the list of removed hooks. Contact the vendor for an updated version that uses the replacement hooks.

Front-End Styling Broken on Hummingbird

Bootstrap 4 to 5 class name changes. The module works on Classic but looks broken on Hummingbird. This requires template updates from the module vendor. As a temporary workaround, you can switch to the Classic theme while waiting for the vendor to update.

JavaScript Errors in Browser Console

Often caused by jQuery dependency in a Hummingbird environment. Check the browser developer console (F12) for "$ is not defined" or "jQuery is not defined" errors. The long-term fix is vanilla JavaScript, but in the short term, you can include jQuery manually in your theme's assets.

Email Notifications Stopped Working

If a module sends emails through SwiftMailer directly instead of PrestaShop's mail function, it will break on PrestaShop 9 where SwiftMailer was replaced by Symfony Mailer. Contact the vendor for an update.

PrestaShop 9.1: Additional Changes to Watch

PrestaShop 9.1 introduced its own set of changes on top of 9.0. If you are upgrading directly to 9.1 (recommended, as it is the latest stable), be aware of these additional compatibility factors:

• Theme::getDefaultTheme() no longer returns the hardcoded "classic" string. Modules that assumed the default theme is Classic need updating.
• The displaySearch hook was removed from Hummingbird because it caused conflicts on 404 pages. Modules hooking into displaySearch for front-end search customization need to use alternative hooks.
• D3 and NVD3 charting libraries were updated to newer versions. Dashboard widgets using these libraries may render incorrectly.
• JavaScript selectors migrated to data-ps-* convention, replacing class-based selectors. Modules using querySelector with PrestaShop-specific class names may stop targeting the correct elements.

Your Pre-Upgrade Checklist

Print this out, stick it on your wall, and do not upgrade until every item is checked:

1. Inventory all installed modules with vendor names and current versions
2. Check each vendor's website for PrestaShop 9 compatibility statements
3. Update all modules to their latest versions (even before upgrading PrestaShop)
4. Set up a staging environment with a copy of your production database
5. Install PrestaShop 9.1 on staging
6. Install modules one by one, checking error logs after each
7. Test core functionality of every module (not just "does the config page load")
8. Test front-end rendering on your active theme
9. Run a complete test order through checkout
10. Check PHP error logs for deprecation warnings
11. Verify email sending from all modules that send notifications
12. Back up everything: database, files, and configuration
13. Schedule the upgrade during low-traffic hours
14. Keep your PrestaShop 8.x backup available for at least 30 days after upgrade

Final Thoughts

PrestaShop 9 is a significant improvement. Symfony 6.4 brings better performance, modern PHP practices, and a more maintainable architecture. The Hummingbird theme is faster and more accessible than Classic. The new admin API opens possibilities that were not available before.

But none of that matters if your modules break during the upgrade. Take the time to audit properly. Use a staging environment. Hold your vendors accountable for explicit compatibility statements, not vague "should work" responses.

If you are looking for modules that have been rigorously tested across PrestaShop 1.7.6 through 9.1, take a look at the mypresta.rocks module catalog. Every module ships as a single ZIP that works across all supported versions, and PrestaShop 9 compatibility is included with every license, not sold as a separate upgrade.

Have questions about your specific upgrade scenario? Reach out to us and I will help you evaluate your module stack.

Related Articles

• PrestaShop 9.1 Is Coming: Hummingbird 2.0, Multi-Carrier Shipping, and Why Now Is the Time to Upgrade
• Our Blog Is Live: PrestaShop Guides, Tips & Industry Insights
• Introducing Sales Revolution: Automated Flash Deals for PrestaShop