This edition of the Core Weekly report highlights changes in PrestaShop’s core codebase from Monday 27th of June to Sunday 3rd of July 2022.

General messages

Dear developers,

Multiple new applications have been submitted to join the team: marsaldev for committer position and PrestaEdit for maintainer position. This is great news!

In the meantime, the QA team is still going through the 8.0.0 alpha functional campaign which aims to evaluate how much work would be needed before being able to deliver an 8.0.0 alpha build.

Also the next session of the public PrestaShop demo from the maintainers team will happen this week, on Wednesday, July 6, 2022 at 4pm CEST!

A quick update about PrestaShop’s GitHub issues and pull requests:

• 51 new issues have been created in the project repositories;
• 31 issues have been closed, including 7 fixed issues on the core;
• 98 pull requests have been opened in the project repositories;
• 79 pull requests have been closed, including 68 merged pull requests.

Code changes in the ‘develop’ branch

Back office

• #28842: Remove Addons reference in the Carriers Listing, by @Progi1984
• #28824: Fix the download link of the invoice search. Thank you @okom3pom
• #28477: Adjust footer on V2 product page. Thank you @Amoifr

Front office

• #28811: Add random to Validate Class and Test. Thank you @okom3pom

Tests

• #28902: Fix nightly develop 21-06-2022 - Update default carrier and check it in FO . Thank you @nesrineabdmouleh

Code changes in the ‘8.0.x’ branch

Back office

• #28817: Fix notices in email translation. Thank you @okom3pom
• #28802: Fix notice admin search controller. Thank you @okom3pom

Tests

• #28918: Functional tests - Refactoring of ‘Check header links on FO’ test. Thank you @nesrineabdmouleh
• #28884: Fix errors on nightly 8.0.x . Thank you @nesrineabdmouleh
• #28866: Fix nightly 8.0.x - Add pre-condition to clear cache in ‘Check footer links FO’ test. Thank you @nesrineabdmouleh
• #28828: Functional tests - Add new test ‘Edit personal information’ in FO. Thank you @nesrineabdmouleh
• #28815: Functional tests - Add new test ‘Create account on FO’. Thank you @nesrineabdmouleh
• #28809: Functional tests - Add new test ‘Logout from FO’. Thank you @nesrineabdmouleh
• #28717: Functional tests - Add new test “Customers > Outstanding page” Help card - View order - View Invoice, by @khouloudbelguith

Code changes in the ‘1.7.8.x’ branch

Back office

• #28821: Handle fallback when currency has empty display names, by @jolelievre
• #28392: Fix back-office translations when multishop and multiple languages. Thank you @MeKeyCool

Front office

• #27841: [Multistore] - Product on category page display out of stock flag instead of availlable on order. Thank you @Rizzen59

Code changes in modules, themes & tools

Available quantities statistics module

• #23: Use Organization Build Release Github Action, by @atomiix

Registrations statistics modules

• #17: Use Organization Build Release Github Action, by @atomiix

Product details statistics module

• #32: Use Organization Build Release Github Action, by @atomiix

Data mining for statistics module

• #27: Use Organization Build Release Github Action, by @atomiix

Catalog evaluation statistics module

• #24: Use Organization Build Release Github Action, by @atomiix

Catalog statistics module

• #26: Use Organization Build Release Github Action, by @atomiix

Best suppliers statistics module

• #15: Use Organization Build Release Github Action, by @atomiix

Best manufacturers statistics module

• #15: Use Organization Build Release Github Action, by @atomiix

GDPR module

• #176: Use Organization Build Release Github Action, by @atomiix
• #154: Avoid warning open_basedir restriction (using fetch instead of display). Thank you @PrestaEdit

Social Follow module

• #35: Use Organization Build Release Github Action, by @atomiix

New Products module

• #14: Use Organization Build Release Github Action, by @atomiix

Links list module

• #150: Use Organization Build Release Github Action, by @atomiix

Email subscription module

• #90: Use Organization Build Release Github Action, by @atomiix

Customer data privacy block module

• #39: Use Organization Build Release Github Action, by @atomiix

Customer “Sign in” link module

• #45: Use Organization Build Release Github Action, by @atomiix

Customer account links module

• #40: Use Organization Build Release Github Action, by @atomiix

Cross-selling module

• #37: Use Organization Build Release Github Action, by @atomiix

Contact informations module

• #48: Use Organization Build Release Github Action, by @atomiix

Check payment module

• #58: Use Organization Build Release Github Action, by @atomiix

Category tree links module

• #58: Use Organization Build Release Github Action, by @atomiix

Products in the same category module

• #32: Use Organization Build Release Github Action, by @atomiix

Best sellers module

• #22: Use Organization Build Release Github Action, by @atomiix

Banner module

• #46: Use Organization Build Release Github Action, by @atomiix

Google Sitemap module

• #153: Use Organization Build Release Github Action, by @atomiix

Simple HTML table display module

• #30: Use Organization Build Release Github Action, by @atomiix

NVD3 Charts module

• #21: Use Organization Build Release Github Action, by @atomiix

Dashboard Products module

• #42: Use Organization Build Release Github Action, by @atomiix

Dashboard Goals module

• #29: Use Organization Build Release Github Action, by @atomiix

Contact Form module

• #62: Use org build and release workflow, by @atomiix

Distribution API

• #15: Adding new ci cd for production to be tested. Thank you @djodjo3

Docker internal images

• #38: Fix PS version for nightly docker image, by @sowbiba

Customer reassurance block module

• #416: Bump @babel/core from 7.18.5 to 7.18.6. Built by @dependabot[bot]
• #415: Bump sass-loader from 13.0.1 to 13.0.2. Built by @dependabot[bot]
• #414: Bump sass-loader from 13.0.0 to 13.0.1. Built by @dependabot[bot]

Faceted search module

• #677: Bump @babel/preset-env from 7.18.2 to 7.18.6. Built by @dependabot[bot]
• #676: Bump @babel/cli from 7.17.10 to 7.18.6. Built by @dependabot[bot]
• #674: Bump @babel/core from 7.18.5 to 7.18.6. Built by @dependabot[bot]
• #673: Bump @babel/node from 7.18.5 to 7.18.6. Built by @dependabot[bot]
• #672: Bump sass-loader from 13.0.1 to 13.0.2. Built by @dependabot[bot]
• #671: Bump sass-loader from 13.0.0 to 13.0.1. Built by @dependabot[bot]

Changes in developer documentation sources

• #1400: Update broken link. Thank you @Sasni
• #1399: Update broken link. Thank you @Sasni
• #1398: Remove extraCarrier note, as it’s deprecated since 1.7.0 and not used. Thank you @PrestaEdit

Classic theme

• #38: Fix npm 8 compatibility, by @NeOMakinG

Docker images

• #308: Add PHP 8.1, by @atomiix

Auto Upgrade module

• #492: Fix state of dev branch following hotfix of 1.7.8.6, by @matks

Example modules

• #97: Bump eventsource from 1.0.7 to 1.1.1 in /example_module_mailtheme. Built by @dependabot[bot]

PrestaShop on Docker

• #22: Add image for PHP 8.0 and delete support for PHP 7.1, by @boubkerbribri

Image slider module

• #75: Add RTL sample images. Thank you @mparvazi

Thank you to the contributors whose pull requests were merged since the last Core Weekly Report: @atomiix, @nesrineabdmouleh, @djodjo3, @sowbiba, @dependabot[bot], @Progi1984, @Sasni, @PrestaEdit, @NeOMakinG, @okom3pom, @jolelievre, @matks, @khouloudbelguith, @boubkerbribri, @Amoifr, @mparvazi, @MeKeyCool, @Rizzen59!

Thank you to the contributors whose PRs haven’t been merged yet! And of course, a big thank you to all those who contribute with issues and comments on GitHub!

If you want to contribute to PrestaShop with code, please read these pages first:

• Contributing code to PrestaShop
• Coding standards

…and if you do not know how to fix an issue but wish to report it, please read this: How to use GitHub to report an issue. Thank you!

Happy contributin’ everyone!

Friendly reminder, that the public PrestaShop demo from the maintainers team will happen next week, on Wednesday, July 6, 2022 at 4pm CEST!

We expect to share with you project news and present 2 very interesting topics:

• New password policy by @matks
• New product page by @jolelievre and @MatShir

In addition, @eshraw will present you the new initiative from the Product Team, “Product discovery for v8.1 and above”.

Join us on YouTube!

The session will be kept in record on YouTube, so that even if you can’t attend to the live stream, you will still be able to catch up later.

See you then!

The post The State of Laravel Survey 2022 appeared first on Laravel News.

Join the Laravel Newsletter to get Laravel articles like this directly in your inbox.

In December 2015, a groundbreaking change in PrestaShop was announced: the introduction of the Symfony framework into the CMS. The goal was to gradually replace PrestaShop’s custom framework with Symfony, and switch its templating system from Smarty to Twig. This project was known as “The Symfony migration”. Looking back, we realize that referring to this project as a “migration” wasn’t really accurate at all.

Currently, migrating one page to Symfony involves several steps:

• Analyze the page’s features and its business logic, then specify any unclear or ambiguous behavior
• Create a new Symfony controller, identify the different “actions” and set them up (routing, access control…)
• Reimplement the page’s original behavior using modern components (Grid, Symfony forms, Twig, CQRS…)
• Implement any feature required in order to reproduce the original behavior using the new components (Twig layouts, form theme, js…)
• Implement adapters for any legacy component used in the original controller (as required by the architecture rules established in 2015)
• Fix old bugs discovered while reimplementing the old features, or reimagine the existing features to improve them
• Add automated tests
• Remove the old controller and rerouting it to the new controller

That’s a lot of steps, right?

To us, this shows that the migration process isn’t really just about changing the underlying framework or a few components. It’s much more than that: it’s a full-on refactoring.

At the time of writing, over 90 back office pages have been refactored using the process above. It’s a thorough process and we are proud of how it has contributed to increasing PrestaShop’s overall software quality in the recent years. However, it has its downsides.

Migrating a page this way is slow and requires a major effort. It basically amounts to building the page again – a better version of it. With several dozen modified files, refactoring a typical page takes several weeks of development, and months of review and refinement. There are still 50 pages left to migrate in the back office. That’s years’ worth of work!

In the meantime, PrestaShop’s architecture has become heterogeneous. Although the pages migrated to Symfony benefit from all the modern concepts built over the years, a third of the back office pages remain largely identical to what they were in PrestaShop 1.6 – not to mention the whole front office and the Web service API.

This means developers have to deal with some parts of the software working in a certain way and others working completely differently. As mentioned in previous articles, this is problematic: having more than one way of performing the same action carries a higher risk of bugs, lower performance, increased maintenance work, and a steeper learning curve for people new to the platform.

Moreover, every bit of the legacy framework must be preserved until the migration has been fully completed. Even if in a few years only a single page that few people use was left to migrate, everything it relies on, Dispatcher, ObjectModel, Smarty, Helpers… the entire legacy stack must remain in place, alive and maintained.

Of course, in time, the migration will be finished, we will be able to remove any remaining legacy components, and reduce the platform’s complexity. But as the saying goes, “in the long-term, we will all be dead”. PrestaShop’s attractiveness as a platform is at risk if we don’t accelerate the migration.

We need a better strategy. How can we accelerate the transition to Symfony, increase the platform’s homogeneity, and phase out legacy components faster?

Thinking outside the box

Let’s analyze our current strategy. Migrating a page takes a list of known steps. Currently, we perform all those steps on a single page, then move on to the next page, and so on.

What if we focused on delivering a single step at a time, progressively across all pages?

Take the controller part, for example. At its root, a Symfony controller takes a Request and provides a Response, that’s all. How the request is processed in order to build that response has no impact on the nature of the controller. Who says a Symfony controller must use Twig? Or Grid? Or Symfony forms, for that matter? Theoretically, it should be possible to take the content of the legacy controller and paste it into a Symfony controller. As long as the original code is rearranged into actions, and we get a response, it doesn’t matter if the output is built using Smarty helpers: HTML is HTML.

Following that logic, we could say that the first step to migrating a controller is “transforming” it into a Symfony controller. Strictly speaking, this requires minimal changes to the original code. It might not be pretty, but it provides all the benefits of a full-fledged Symfony controller (routing, kernel events, debug features, translator, container, etc) – for a very low price.

Migrating a page using this “shortcut” should take fewer modifications compared to the traditional way. This means less developer effort (making it easier for contributors to participate), less effort to review and, hopefully, less effort to verify. If we did this to all remaining controllers, we could have 100% of the back office running on Symfony controllers much sooner than if we performed all the refactoring steps to each of them as we do now. This would allow us to phase out Dispatcher, Link, AdminController, and other legacy components much faster.

Now, rest assured, this wouldn’t mean abandoning Twig, Grid, Symfony forms, and CQRS – quite the opposite. Once all controllers had been running on Symfony, we could start the second step: removing Smarty in favor of Twig. If we managed to make HelperList and HelperForm work using Twig, we could easily phase out Smarty. This would simply require refactoring the helpers (in which case we wouldn’t need to change any of the controllers), or creating new components that follow the same signature as the old helpers (which would require minimal changes to the controllers). Again, this could be applied everywhere, allowing us to phase out Smarty, the legacy back office theme, and the legacy layout that wraps Symfony Twig pages.

After that, we could go on to phase out HelperLists in favor of Grids, then HelperForms in favor of Symfony forms and CQRS. And then, the migration of the back office would be complete.

We call this approach “horizontal migration”, because it focuses on replacing one layer of legacy components with its modern equivalent across all pages before moving on to the next layer. In contrast, we call our current approach “vertical migration”, because it focuses on migrating all layers of a page at once. The end result is the same: full migration to Symfony. It’s the path to get there that changes.

What’s next?

We think the horizontal approach provides two major benefits compared to our current approach:

• A quicker reduction of the system’s overall complexity, because legacy components can be sunset as soon as they are no longer needed, instead of having to wait until the whole migration has been completed.
• A gentler learning curve for PrestaShop developers not familiar with Symfony, who will be able to use HelperList and HelperForm in Symfony controllers.

The main downside of the horizontal approach is that lists and forms need to be migrated twice: once with helpers, then again using the newer components. However, we think its benefits are worth the effort.

The horizontal approach has been recently approved by maintainers, and the first example of a listing page migrated using HelperList has been merged. This means that this should be the main approach to migration from now on.

The vertical approach is not completely abandoned, though: it might still be used in pages where the horizontal approach would not make tactical sense, either because the page is too simple to benefit from the advantages of horizontal migration, or because it requires extensive refactoring (for example, the product page).

Tell us what you think!

The horizontal migration is an idea we are actively experimenting with, but our understanding of its impact is limited by our knowledge of PrestaShop’s ecosystem. If you have any questions, ideas or suggestions about this subject, please share them in the comments below, or come chat with us on Slack.