Browser: Chrome 110 OS: macOS / Windows / Linux / etc. URL: Link to a page that illustrates this issue Video: Short screen recording that illustrates this issue (free tool: jam.dev)
In the enclosed html you can find an attribute data-text which is target of a component called “Bitmal_Header” (see *-Component_Field)
the expected result is that the data-text is populated with the value that the web designer wants (see, as for instance, *-Component_Editor where I try to populate it with “TEST_RESULT”).
I did something similar without the use of the component in *-NO_Component_Editor by populating it with “TEST_NO_COMPONENT”.
Loading the page the results shows that Bricks seemed to have failed to populate the data-text of the div corresponding to the component, but worked as predicted with the div that wasn’t implemented as a component (check *-Component_Inspect). The bug was easily replicable with a simple component with default classes and a single attribute field to be replaced, inficating that there is no inference on the custom class I am defining or the script I am applying to the classes thereof.
Can you help me in understanding what I am doing wrongly?
hi there!
I realized that the first media in my original post is the wrong file and, conversely, the *-NO_Component_Editor image is missing: here it is
We do have a similar report for data attributes in the components. In the image you posted, I can see that in the component, the attribute value is “HEADER”, where it should be “TEST_RESULT”.
From this, I’m concluding that you had “HEADER” as an attribute value, before you connected a property to it. If yes, can you try to disconnect a property, remove a “HEADER” value - so that it’s empty, and then connect it back. Does it work then?
ciao Matej,
first of all sorry for the delayed reply → it indeed works as expected (check the page for the div of class .bitmap_text). I can work with it. thanks for the help.
However there are still odd behaviours that are probably not the intended ones
if a data-* is given the value 0, then instad of being loaded as data-*:“0” is simply ignored (if you test it in Chrome it should be the case as I could replicate it multiple times)
while non-0 valued variables like {post_title} works perfectly fine in popupating the attribute, user defined attributes like {–my_var} or var(–my_var) … are simply rendered as pure text: data-*:“var(–my_var)”
I’m glad to hear that it’s working correctly now. Untill we fix it, you will have to work this way.
I was also able to replicate this issue, and I’ve added it to our internal bug tracker. Sadly, I don’t have a workaround for this Maybe if you add a space before or after, depends what you need.
About this one: These are CSS variables, and they will not be populated inside the attributes. You can use dynamic data though. So, unless I don’t understand something, this is not a bug.
ciao Matej
just to be more specific about the data-*:“0”
“These are CSS variables, and they will not be populated inside the attributes.”
yet if I set a container property to anything but 0, then, if that property is linked to any data-* attribute, then it gets populate: as for instance I could read in the html code data-* :“100vh”, but I cannot possibly read data-* :“0” because when a component property is passed the value 0 then is ignored while writing the html file.
I also noticed more behaviors that are related to the behavior I documented in the OP
More generally (and with further usage of the component editor) the component editor doesn’t simply update its instances under certain circumstances. I found 2.
Let me drive you through my testings:
I turn a div and its children (that was already built in my page) into a component using the contextual menu: for some reason the component is initialized in a seemingly random past state of the input div and not in the most recent
therefore I understand that the only way to create a component is inside the editor itself (as turning an already built element/s of my website into components behaves randomly).
so i start to build the component itself into the editor from scratch and, indeed, they get updated as predicted
unless I declare the first property. After that moment, any new property or style modification I apply to the component do not apply to the instances (like if the property declaration is freezing the editing capability of the component… much like if I would use a section template if you know what I mean)
unfortunately this is not reflected in what the editor UI is showing (as it correctly visualize and keeps track of my edits) and can only be derived by loading the html page
Hmm, I did not observe this behaviour. I’ve created many components the way you described → style them, then convert them to the component.
Is there a reliable way, that we can reproduce this?
Can you record a video wtih voice about this. As simple as possible, so I can try to replicate it?
ciao Matej: I was thinking about the same → I will try to put together a screen recording for you… because is also true that it does not reflect consistently what I also had experienced with components… but I do have an example that I can try to rebuild from scratch for you
Maybe if you add a space before or after, depends what you need.