- Category: Dev News
The post Add Comments to Correlate User Code with SQL Queries in Laravel appeared first on Laravel News.
- Category: Dev News
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.
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
- #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
- #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
- #28817: Fix notices in email translation. Thank you @okom3pom
- #28802: Fix notice admin search controller. Thank you @okom3pom
- #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
- #28821: Handle fallback when currency has empty display names, by @jolelievre
- #28392: Fix back-office translations when multishop and multiple languages. Thank you @MeKeyCool
- #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
Registrations statistics modules
Product details statistics module
Data mining for statistics module
Catalog evaluation statistics module
Catalog statistics module
Best suppliers statistics module
Best manufacturers statistics 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
New Products module
Links list module
Email subscription module
Customer data privacy block module
Customer “Sign in” link module
Customer account links module
Contact informations module
Check payment module
Category tree links module
Products in the same category module
Best sellers module
Google Sitemap module
Simple HTML table display module
NVD3 Charts module
Dashboard Products module
Dashboard Goals module
Contact Form module
Docker internal images
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
Auto Upgrade module
PrestaShop on Docker
Image slider module
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:
…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!
- Category: Dev News
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:
In addition, @eshraw will present you the new initiative from the Product Team, “Product discovery for v8.1 and above”.
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!
- Category: Dev News
- Category: Dev News
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
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.
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.