Page Builder polutes the frontend HTML markup with attributes that are only needed for the adminhtml area

[ericmorand]

Preconditions (*)

1. Magento 2.3.5 EE

Steps to reproduce (*)

1. Create a new page
2. From the page builder, add a text inside the first available row
3. Save the page
4. Head to the newly created page from the front-office

Expected result (*)

1. The HTML markup is free from "data-" attributes that are not needed to theme the website.

Actual result (*)

1. The HTML markup is populed by "data-" attributes that are needed for the back-office to function properly: data-element, data-appearance and data-content-type.

Why is it happening and why this is a flaw

This is happening because the back-office parse the front-office HTML markup to construct the UI of the Page Builder. It means that those data- attributes need to be present in the rendered HTML markup for the back-office to function. Removing these attributes from master.html template for example makes the back-office crash.

This is a design flaw. It forces the front-office markup to contain some informations that are not needed by neither the front-office content layer not the front-office style layer. Those informations should not be there since they serve no purpose. They can even be detrimental in case the front-office has styling for those attributes because they are used on some templates that are part of a custom Magento theme. Basically, they force the theme providers to consider that these 3 data- attributes are reserved to the system and should not be used to provide styling and/or behavior.

I believer that it needs to be fixed ASAP. Until then, the Page Builder is basically unusable for professionals that want reliability and have full control on the HTML markup of the front-office they provide to their customers.

[m2-assistant[bot]]

Hi @ericmorand. Thank you for your report. To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

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

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

  :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues 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.

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

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

[mrtuvn]

@davemacaulay can you give some comments on this

[ericmorand]

@mrtuvn it would also be very helpful if we could have a workaround. I know that this issue won't be solved anytime soon - it probably requires a huge refactoring of the way Page Builder works - but I think there may be a way to avoid the issue. I'm thinking about some sort of filtering before the HTML markup is sent to the renderer. This way, the HTML markup would remain "poluted" in the database (ensuring that it works with the back-office) but would be cleaned before rendered as part of the page.

I'm investigating this point on my own project. But if someone has an idea to point me in the right direction, I'd be very glad. :)

[mrtuvn]

From frontend view i don't like PB sometimes when i need to copy/paste data around in backend. Hard to edit/modify content like before. In some case if no specific class will be hard to styling child content inside PB components. From frontend some extra divs generated by code can take you extra time to figure some issues around . Other hand i love PB in the way make user easier to build their contents without need knowledge html

[m2-assistant[bot]]

Hi @ericmorand. Thank you for your report. To help us process this issue please make sure that you provided sufficient information.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[omiroshnichenko]

Hi @ericmorand. Thanks for your contribution. So, we are using data- attributes not only in admin, but we also rely on them on the storefront to initiate widgets and transfer configuration for these widgets. If you have some alternative way of how these could be done - I am fully open to any ideas. Thanks again.

[nige-one]

We actually use the data-attributes also in the PWA/React component context, since there is no way to get CMS content other then the regular cmsPage or cmsBlocks queries. Using HTML for holding data does not seem ideal but at least it's XML, isn't it.

[0m3r]

Do I understand correctly that it is about these wrappers?

<div data-content-type="html" data-appearance="default" data-element="main">
...

It appears after cms page save in Magento 2.4.3. ()

It's problem for me also because it breaks my custom data-content-type (s) for my PWA-studio package.

<div data-content-type="html" data-appearance="default" data-element="main">
&lt;div &gt;   
{{widget type="S\Slider\Block\Slider" identifier="_home"}}   &lt;/div&gt;
</div>

where the widget has its own data-content-type="easyslider" for example but it is not

so now after saving the page I must directly remove the wrapper.