per PSR2 recommendation, ElseIf should be used instead of else-if

[sankalpshekhar]

Description (*)

This per updates usage of ELSE-IF to ElseIf, per PSR2 recommendation.

Fixed Issues (if relevant)

1. magento/magento2#<issue_number>: Issue title

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 @sankalpshekhar. 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.3-develop instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

[dmytro-ch]

Hi @sankalpshekhar,
thank you for your contribution!
Could you please check and resolve the static test failures?

[orlangur]

Thanks @sankalpshekhar, we don't need a manual PR for such change though as all such occurrences will be fixed automatically.

[m2-assistant]

Hi @sankalpshekhar, 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.

[sankalpshekhar]

@orlangur Could you help on the steps laid out for this to be fixed automatically?

From what I see the last commit on these files, the oldest being almost a year old and they haven't been fixed yet.

[orlangur]

@sankalpshekhar phpcbf will be applied all over the code base. Coding standard is being finalized currently.

[sankalpshekhar]

@orlangur I see that the standards are still being finalized, including versioning. Do we have a release date on when this would be applied to the framework?

[orlangur]

@sankalpshekhar I believe we can do it during June and target 2.3.3 release, here is a corresponding issue: #8612 (comment)

[hostep]

@orlangur: can we attempt to put this code standard changes in as few commits as possible, even maybe dedicate a separate release for this? I don't want to go figuring out again what actually changed in the code besides the code standards changes. Having a dedicated release number for only code standards applying would make it more clear and will help a lot with upgrading shops to a newer version where we can then easily see the more "significant" changes in the codebase (and ignore the code standard changes).

[orlangur]

@hostep thanks, will keep this in mind. I remember such approach used only once for copyright year update, probably makes sense if we will update PHPDocs massively.

UPD:

With every update of Magento, I go through all changed files manually to see what has changed in between them. Especially the frontend files (phtml, html, js, xml, ...) as they tend to not be backwards compatible

Wow, this is really awkward use case, people usually rely on automation these days. I don't think it justifies a separate release, ignoring minimalistic amount of CS-related commit should be sufficient (and this is much better than hundreds of manual fixes in different commits being contributed currently).

[hostep]

people usually rely on automation these days

If you know of such an automation tool, feel free to share. The best one we found this far is just detecting changes, but not applying those changes automatically, this is https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper

Sorry for going completely off topic here :)

[orlangur]

@hostep no-no, I meant it's quite strange to look into diffs, just write enough automated tests and run them whenever you upgrade :)

[hostep]

Magento tends to fix security related issues in phtml files by introducing escape functions for example. I'm not sure if tests can catch these changes in overwritten phtml files in a custom theme? Since the output will be exactly the same if no weird data was passed. While your custom theme then might contain vulnerable code which was fixed in core Magento.