PrestaShop/docs

Notable changes for PrestaShop 9

kpodemski opened this issue · 5 comments

kpodemski commented

P1. Changes in translations

  • documented

Following PrestaShop/PrestaShop#30415 the function trans() does NOT escape anymore strings. In v8 you could pass parameters like htmspecialcharacters or addslashes to trans() to perform additionnal escape, but it’s been removed. It also affects the l function in Smarty: same thing.

P2. Some of the controllers are now using Presenters

  • documented

Example: PrestaShop/PrestaShop#32652
Other than that, also Category, Manufacturer, Supplier, etc.

P3. Every symfony controller of modules should be declared with autowire: true and autoconfigure: true Symfony 5.4 imposes controllers to be defined as services, we handled some retro compatibility to avoid this as long as the controller extends FrameworkBundleAdminController This controller is deprecated though and should stop being used as it will be removed in future versions

  • documented

PR that allows PrestaShop/PrestaShop#32450

P4. Drop ssl encryption support for mail sending. The remaining choices are tls encryption or no encryption

  • documented

When we were migrating Swift mailer to Symfony Mailer, we noticed that ssl support was not an option in ESMTP transport class:
https://github.com/symfony/mailer/blob/6.2/Transport/Smtp/EsmtpTransport.php#L35
vs
https://github.com/swiftmailer/swiftmailer/blob/master/lib/classes/Swift/SmtpTransport.php#L33

Also SSL is an old and outdated encryption type. For security reasons, it will not be allowed anymore.

P5. Removing some unused symfony librairies

  • documented

As it's recommended, we have replaced the symfony/symfony library (which is a bundle of symfony librairies) by every single symfony librairy. See here

This allowed us to remove unused symfony librairies. See here

It's a BC break and that means that every module which needs the removed librairies should declare them on their own.

thomasnares commented

My proposition for this one is to create a hidden notable-changes-v9 page on v8 branch for the moment,
then gradually add content in it,

And when the release of v9 willl be almost ready, we create the new v9 branch in docs from v8. This will avoid us many double backports if we create a v9 branch right now, no ?

  • 👍1
M0rgan01 commented

I will add that we are migrating the League Tactician library to Symfony messenger in v9, an update of the cqrs.md file is to be expected

matks commented

Use env variables to enable/disable feature flags PrestaShop/PrestaShop#32923

kpodemski commented

Symfony Layout

From @jolelievre:

All the back office pages share a common layout, composed of a few elements:

  • the <head> element that includes all the CSS and JS (among other things)
  • the side navigation menu
  • the header of the page which is itself composed of
    • quick accesses
    • search form
    • notifications center
    • employee dropdown
    • the multistore header (when multistore is enabled)
  • the page toolbar (which includes breadcrumb and top action buttons)
  • the footer (which only contains a displayBackOfficeFooter display hook)

Until PrestaShop 8.1 all these common elements were handled by legacy code, so even on migrated page there was always a background legacy controller based on AdminController in charge of building the layout data and rendering it. Once the layout as rendered the central content of Symfony pages was included in the middle of it. It means no page was completely free of the legacy controllers which would ultimately block the end of migration where they are meant to disappear completely.

In PrestaShop 9.0 all this layout part is now fully handled by Symfony, we use Twig components to render each element independently. The code is, therefore, easier to understand, a component class is responsible for fetching/building the data while the actual rendering is based on Twig. See our Layout components for more details.

In legacy pages the same principle is used, Symfony is now in charge of rendering all the layout, and we use some Legacy layout components that follow the same architecture but render different twig templates to fit with the old default theme (that is based on old bootstrap and includes old legacy helpers like form and lists).

So what changes for my module pages?

Theoretically nothing! We refactored this layout with maximum backward compatibility in mind, the HTML layout itself had minimum changes (in both migrated and legacy pages), we tried to keep the same hooks in both the PHP code and the twig templates. We even introduce a fake legacy controller in migrated pages that has no logic but is kept mostly as a DTO to contain things like CSS files and JS files because that's where most modules add their content.

Now there may be some parts missed or forgotten which is why we need the help of the community to test this new version and provide feedback for modules that would not work as expected because of this new feature.

  • 👍1
jolelievre commented

This PR introduces a general l;ist of all breaking changes #1822

Some more detailed pages ill follow for more in depth details about major changes