avoid using deprecated escape* methods from AbstractBlock

[sergeynezbritskiy]

Description (*)

Related Pull Requests

Fixed Issues (if relevant)

1. Fixes magento/magento2#<issue_number>

Manual testing scenarios (*)

1. ...
2. ...

Questions or comments

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @sergeynezbritskiy. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento give me test instance - deploy test instance based on PR changes
• @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE,
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here

ℹ️ Please run only needed test builds instead of all when developing. Please run all test builds before sending your PR for review.

For more details, please, review the Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of Pull Requests happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[sergeynezbritskiy]

@magento run all tests

[hostep]

Nice, great job, thanks!
But please target the 2.5-develop branch instead. Reasoning is explained in this sort-of duplicated PR: #30639

[ihor-sviziev]

Hi @sergeynezbritskiy,
Could you re-target your PR to the 2.5-develop branch?

[sergeynezbritskiy]

@magento run functional tests

[ihor-sviziev]

@magento run Functional Tests B2B, Functional Tests CE

[gabrieldagama]

Hi @sergeynezbritskiy, thanks for working on this track! We've discussed this during the Public Community Triage meeting and we believe this can be delivered to 2.4-develop instead since it's risk seems quite small.

Therefore, the amount of files on this PR makes it hard to review, so we would like to recommend the breakdown of this PR into several pull requests, the idea would be split it per module.

Hope that makes sense, thanks!

[hostep]

@gabrieldagama: I strongly disagree, please see my comments on #30639 (comment)

Please think about end users with custom themes who are required to review all changes which Magento adds to the blank theme files and take them over to their own customisations.
Changes should be few and cleanup should not be part of a minor release (2.4.2, 2.4.3, ...). Please only allow many changes in major versions (2.5.0). People expect that updates to a minor release are not going to be expensive (time and money-wise). Major releases can contain many changes and can be expensive but minor releases really can not.

It's really unfortunate that these changes weren't applied in Magento 2.4.0 when the escaper made its appearance, but that's no excuse for now rolling these out in a minor release because it was forgotten.

I'm available on Slack to chat about this should this still not be clear that this is a bad idea.

[gabrieldagama]

Hi @hostep, thanks for highlighting your concern.

Usually, we decide on which version something should be delivered based on backward compatibility, not on the number of changes, mostly because that is relative to how long that development cycle is and how much contribution/work is being done during that time.

Such changes have a small risk of breaking a custom theme, and I believe we are not removing the escapeJs method from AbstractBlock, so in this case, it is not mandatory for the custom theme to update all its template files, you would still be able to upgrade to next patch version without having a big cost of updating all the files.

However, I do understand your concern, having that many files to be reviewed would be hard and time-consuming (as this PR, that is why we recommended to split it into multiple PRs, per module). I will bring this up for the team once more and we can further discuss it.

From my personal point of view, I don't see any problem to 'postpone' such changes to 2.5 instead.

Cc: @sidolov @sivaschenko @sdzhepa

[hostep]

Thanks for considering this @gabrieldagama

Just to explain a bit more, when we compare a frontend file of an old magento version with a new version and if it contains a lot of these changes like used in this PR, it's hard to find other changes which could actually be important, because there is a lot of noise.

The exact same problem happened with Magento 2.3.3 where this gigantic change got accepted: 8698a69. All these changes are only cleanup but made it a lot more complex to figure out which other changes next to these were included in the frontend files.

Therefore, big cleanups in frontend files should only happen while working on a new major version in my opinion. Every new major version has a chance to cleanup or apply new coding standards to the entire code base (we recently had a discussion about this on Slack in the #coding-standard channel btw, see screenshot below).
However, we should really try to avoid doing these sort of things in minor versions, it costs too much time and is very frustrating to deal with when you want to perform a "simple" minor version bump as an end user.

If it is already hard to review these many changes for you guys, image that a lot of your end users also have to go through this review phase and it's not only this change but a bunch of other changes all combined which makes this much harder for us then for you.

Also, there are some reason why we try to apply all changes from core files to our custom themes:

• reducing of technical debt, the more our custom theme is up2date with core files, to less chances of some unexpected bugs which could appear one day + we benefit from new features which got included
• being able to easily compare our custom theme with the core theme of Magento to figure out what changes we made, this helps a lot with debugging stuff, the less they differ, the better, so we try to apply all changes in the core to our custom theme on every single Magento upgrade

---

[sergeynezbritskiy]

Hi @gabrieldagama I've split this PR onto smaller ones, one module - one PR.
Here is the list of related PRs (due to the discussion under this PR, I've changed target branch to 2.5-develop):

#31662, #31663, #31664, #31665, #31666, #31667, #31668, #31669, #31670, #31671, #31672, #31673, #31674, #31675, #31676, #31677, #31678, #31679, #31680, #31681, #31682, #31683, #31684, #31685, #31686, #31687, #31688, #31689, #31690, #31691, #31692, #31693, #31694, #31695, #31696, #31697, #31698, #31699, #31700, #31701, #31702, #31703, #31704, #31705, #31706, #31707, #31708, #31709, #31710, #31711, #31712, #31713, #31714, #31715, #31716, #31717, #31718, #31719, #31720, #31721, #31722, #31723, #31724, #31725, #31726, #31727, #31728, #31729, #31730, #31731, #31732, #31733

Hence this PR can be closed

[m2-assistant]

Hi @sergeynezbritskiy, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.

[sivaschenko]

@hostep @ihor-sviziev we don't see enough risk of these changes to postpone them to 2.5.

The only BIC risks that I can see is extended or plaginized escape methods of blocks in extensions or customization.

Do you agree that is very unlikely and we should target these PRs to 2.4-develop branch?

[hostep]

Hi @sivaschenko, this is not about BIC, please see reasoning above...

[sivaschenko]

@hostep I see, that's about time to review the changes of patch release. Makes sense, thanks for bringing up this point.

[hostep]

Exactly. Magento should try to reduce the number of changes in between minor versions (especially for frontend related files) so these minor updates are as easy as possible and people are encouraged to perform them. Cleanup like suggested here or new coding styles should preferably only be applied to the entire codebase just before a new major version is released. Until a new major version is then released, no cleanup or new coding styles should be allowed, so we only see see significant changes and no unnecessary noise in between minor versions as they will make it easier to deal with as an end-user.

I completely understand that switching to this escaper in phtml files is recommended and make the codebase cleaner and more consistent, but that should have been done by the magento core-devs when they released this feature in 2.4.0, and they didn't. It's a bit annoying this happened, hopefully this sort of thing can be avoided in the future 🙂