Digital Product Passport on PrestaShop 1.7.x

Platform facts

Where to store passport data

ObjectModel with a custom table works here exactly as it does on 8.x and 9.x — the pattern has been stable across all three lines. The $definition conventions, the _lang tables and the multishop pivot tables are unchanged.

This is genuinely good news for an upgrade path: the storage layer is the part that ports cleanly. If you must start passport data collection on 1.7 before you can upgrade, put it in a properly defined ObjectModel with its own table, and it will move to 8.x or 9.x with little more than a compatibility check.

What will not port is the admin interface. Plan for that to be rewritten.

Editing passport data in the back office

1.7 has the legacy product page and controllers/admin/AdminProductsController.php. The displayAdminProducts*Step* hooks work, as does displayAdminProductsExtra.

actionProductFormBuilderModifier — the forward-compatible route on 8.1 and later — does not exist here, because the Symfony product form arrived in 8.1. So there is no way to write back-office code on 1.7 that will survive a move to 9.x. Any admin UI you build now is throwaway.

That asymmetry is the practical argument for upgrading before building: the data model ports, the admin UI does not, and on 1.7 you have no option to write the portable version.

Showing the passport on the storefront

displayProductExtraContent is available and behaves identically to 8.x and 9.x — it must return an array of ProductExtraContent objects. The class has been at src/Core/Product/ProductExtraContent.php since the 1.7 line.

The official example module for this hook declares compatibility from 1.7.0 through 9.99.99, which is a fair summary of how stable this part of the API has been.

displayProductAdditionalInfo, displayAfterProductThumbs and the other product page hooks are all present. Note that hook aliases do not yet emit deprecation notices on this line — so a module that works quietly here may start warning on 8.x.

The public passport URL

The ModuleFrontController pattern and the moduleRoutes hook both work as described for 8.x and 9.x. This part of the API has not changed across any of the three lines.

One caution: on 1.7 you can expose a loose PHP file in the module directory and hit it directly. PrestaShop 9 forbids this. If you build a passport endpoint that way now, it will break on upgrade — use a proper front controller even though this version does not force you to.

Version-specific gotchas

The upgrade is two jumps, not one

1.7 → 8.x brings PHP 7.2.5, Symfony 4.4 and Twig 3, drops non-public services from the container, changes template syntax, moves translations, and extracts the classic theme to a Composer package.

8.x → 9.x is the bigger jump: PHP 8.1 floor, Symfony 4.4 → 6.4 (every breaking change from ten Symfony releases at once), the product page rewrite, $this->get() removed from Symfony controllers, trans() no longer escaping, and the removal of Guzzle, SwiftMailer and TacticianBundle from core. Advanced Stock Management, multi-address delivery and high-DPI images were also removed outright.

The autoupgrade module handles the mechanics; the module compatibility work is the part that takes time.

If you genuinely cannot upgrade yet

Collect the data anyway, in an ObjectModel with a proper schema. Data collection is the long pole in any passport project and it is platform-independent. Do not build an elaborate admin UI you will throw away — a minimal editing screen, or even a CSV-driven import via actionProductSave, is the rational investment on a platform you are leaving.

Questions

Sources

• PrestaShop developer documentation
• PrestaShop example modules on GitHub
• displayProductExtraContent — hook reference
• PrestaShop 1.7.8 entering extended support (Jan 2023)
• PrestaShop 1.7 system requirements
• Autoupgrade module