Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Issue] Introduce separate BlockByIdentifier class to get Layout Block based on CMS Block Identifier #28309

Closed
4 tasks
ghost opened this issue May 20, 2020 · 2 comments · Fixed by #28147
Closed
4 tasks

[Issue] Introduce separate BlockByIdentifier class to get Layout Block based on CMS Block Identifier #28309

ghost opened this issue May 20, 2020 · 2 comments · Fixed by #28147
Assignees
@lbajsarowicz
Labels
Component: Cms Fixed in 2.4.x The issue has been fixed in 2.4-develop branch Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Priority: P3 May be fixed according to the position in the backlog. Progress: done Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S3 Affects non-critical data or functionality and does not force users to employ a workaround.
Projects
Low Priority Backlog

Comments

@ghost
Copy link

ghost commented May 20, 2020 •
edited by engcom-Alfa
Loading

This issue is automatically created based on existing pull request: #28147: Introduce separate BlockByIdentifier class to get Layout Block based on CMS Block Identifier

Preconditions: (*)

The existing class is anti-pattern:

  1. Uses \Magento\Framework\Model\AbstractModel::load to load Model
  2. If block_id is identifier, the getIdentities method returns same identity whatever the Scope is (return [\Magento\Cms\Model\Block::CACHE_TAG . '_' . $this->getBlockId()];), which is painful when you use the same identifier for multiple per-store CMS blocks.

Why can't we fix the original Block? Some of developers might have used:

        <referenceContainer name="page.top">
            <block class="Magento\Cms\Block\Block" name="header.info" after="navigation.sections">
                <arguments>
                    <argument name="block_id" xsi:type="string">666</argument>
                </arguments>
            </block>
        </referenceContainer>

That is why we keep old Block backwards-compatible and introducing new one that can be used explicitly:

        <referenceContainer name="page.top">
            <block class="Magento\Cms\Block\BlockByIdentifier" name="header.info" after="navigation.sections">
                <arguments>
                    <argument name="identifier" xsi:type="string">header-info</argument>
                </arguments>
            </block>
        </referenceContainer>

Related Pull Requests

Fixed Issues (if relevant)

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

Steps to reproduce (*)

Actual Result (*)

Expected Result (*)

  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)
@ghost ghost added Component: Cms Severity: S3 Affects non-critical data or functionality and does not force users to employ a workaround. labels May 20, 2020
@lbajsarowicz lbajsarowicz mentioned this issue May 20, 2020
Merged
5 tasks
@ghost ghost assigned lbajsarowicz May 20, 2020
@ghost ghost added this to PR In Progress in Community Backlog May 20, 2020
@magento-engcom-team magento-engcom-team added the Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed label May 20, 2020
@engcom-Alfa engcom-Alfa added the Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it label Jul 30, 2020
@ghost ghost added the Priority: P3 May be fixed according to the position in the backlog. label Aug 17, 2020
@magento-engcom-team magento-engcom-team added Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed and removed Issue: Format is not valid Gate 1 Failed. Automatic verification of issue format is failed labels Aug 18, 2020
@engcom-Alfa engcom-Alfa added Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch labels Aug 18, 2020
@ghost ghost removed the Triage: Dev.Experience Issue related to Developer Experience and needs help with Triage to Confirm or Reject it label Aug 18, 2020
@magento-engcom-team magento-engcom-team added the Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development label Aug 18, 2020
@magento-engcom-team
Copy link
Contributor

✅ Confirmed by @engcom-Alfa
Thank you for verifying the issue. Based on the provided information internal tickets MC-36814 were created

Issue Available: @engcom-Alfa, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

@ghost ghost moved this from PR In Progress to Ready for Dev in Community Backlog Aug 18, 2020
@m2-assistant m2-assistant bot mentioned this issue Aug 26, 2020
Closed
5 tasks
@ghost ghost moved this from Ready for Dev to PR In Progress in Community Backlog Aug 26, 2020
@sidolov sidolov added this to Ready for Development in Low Priority Backlog Sep 24, 2020
@m2-community-project m2-community-project bot moved this from Ready for Development to Pull Request In Progress in Low Priority Backlog Sep 24, 2020
@m2-community-project m2-community-project bot added Progress: PR Created Indicates that Pull Request has been created to fix issue and removed Progress: PR in progress labels Sep 24, 2020
@gabrieldagama gabrieldagama added the Fixed in 2.4.x The issue has been fixed in 2.4-develop branch label Nov 9, 2020
@gabrieldagama
Copy link
Contributor

Hi @m2-backlog[bot]. Thank you for your report.
The issue has been fixed in #28147 by @lbajsarowicz in 2.4-develop branch
Related commit(s):

The fix will be available with the upcoming 2.4.2 release.

@m2-community-project m2-community-project bot moved this from Pull Request In Progress to Done in Low Priority Backlog Nov 9, 2020
@m2-community-project m2-community-project bot moved this from Done to Pull Request In Progress in Low Priority Backlog Nov 9, 2020
@m2-community-project m2-community-project bot removed this from PR In Progress in Community Backlog Nov 9, 2020
@m2-community-project m2-community-project bot added Progress: PR in progress Progress: done and removed Progress: PR Created Indicates that Pull Request has been created to fix issue labels Nov 9, 2020
@m2-community-project m2-community-project bot moved this from Pull Request In Progress to Done in Low Priority Backlog Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lbajsarowicz lbajsarowicz

Labels
Component: Cms Fixed in 2.4.x The issue has been fixed in 2.4-develop branch Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Priority: P3 May be fixed according to the position in the backlog. Progress: done Reproduced on 2.4.x The issue has been reproduced on latest 2.4-develop branch Severity: S3 Affects non-critical data or functionality and does not force users to employ a workaround.
Projects
Low Priority Backlog
  
Done
Milestone
No milestone
4 participants
@lbajsarowicz @gabrieldagama @magento-engcom-team @engcom-Alfa