Bricks Version: 1.5 RC
Browser: Chrome 103.0.5060.134
OS: macOS 12.4
Dynamic fields from MB type WYSIWYG Editor enclose the text with unwanted paragraphs
As stored in MB:
<p>Some Text</p>
Adding such dynamic fields with a Rich Text element enclose this data in additional paragraphs like:
<p></p>
<p>Some Text</p>
<p></p>
and create whitespace at the output.
Hello @BerntK
Thank you for your report.
In order to get a proper output using the Bricks Rich Text element, you would need to set the field to Save data in the raw format.
Or, place the DD tag inside a Basic text element.
Hi @luistinygod
I tried save in raw format - same problem - output enclosed in <p></p>
Basic text field is OK as workaround.
some text in MB custom field:
<p><strong>Some strong text</strong><br />second line text<br />third line text</p>
gets this output:
<div class="brxe-text">
<p></p>
<p><strong>Some strong text</strong><br>second line text<br>third line text</p>
<p></p>
</div>
After switching the field to output as raw, you need to resave the post where you are using this field. If this is a problem, because you have multiple posts, I suggest you use the Basic text element in Bricks to output this field.
Thank you, that worked. But only after the post has been saved again.
This bug still exists of 1.7beta.
Seems like similar issue with ACF was fixed but Meta Box no - using basic text element
EDIT - this is only happening when setting the Basic Text HTML element to a p tag. If you use the Rich Text element you get an unnecessary div wrapper.
Frontend Output Showing 3 p tags for just the 1 p tag in the backend WYSIWYG field
From the MetaBox WYSIWYG Text tab
It does not make sense to use a basic text field, change its tag to a paragraph and insert content from a WYSIWYG custom field (which itself contains paragraphs). This would result in nested paragraph tags.
So imho it’s perfectly fine to have a div wrapper (either a basic or a rich text element) which then contains the content of the WYSIWYG custom field. And in both cases it works as expected (see Meta Box WYSIWYG – Bricks).
If you really want to output the “raw value” you can use a code block and check “Render without wrapper” (see screenshot attached).
Thats a fair comment and specific to the above usecase and when you have a few paragraphs or different content. I do need to change the fields about a bit.
Just checked a few other fields and this is also happening for textarea with both single/multiple paragraphs. Here it does not make sense to add a div wrapper as you can only add text which should output multiple paragraphs.
Not sure what you mean regarding the textarea field to be honest. Can you explain or show an example of what exactly you mean?
custom field of type textarea
3 elements, first 2 are basic text, 3rd is rich text all querying the mb custom field of type textarea as above and the field only has 1 paragraph - but has option for more as its a textarea field.
1 - this is fine as the basic-text tag has not been changed so remains as a div hence the div wrapper.
2 - basic-text is set as paragraph, as there is 1 paragraph in the field this produces another p tag wrapper.
3 - rich text gives a div wrapper
Hey Dan,
The problem is this one SOLVED: Basic text element adds 2 extra paragraph.
We’ve just re-uploaded 1.7 beta containing the fix mentioned above, so you can test it again (see the screenshot from my test): Bricks – Account
This is probably what Andre has already described above. If you use <p> as a wrapper, the <p> is opened and automatically closed by the browser with the next <p>.
Quote from the specs:
Paragraphs are block-level elements, and notably will automatically close if another block-level element is parsed before the closing
</p>tag. See “Tag omission” below.
Long story short: From our point of view, there are three cases in which the Basic Text Element should output tags:
you write them in manually:
<p>This is <span class="test">my custom HTML</span> text.</p>
The source is a WYSIWYG dynamic data field.
The source is a dynamic data field that provides you with a UI setting to add formatting (such as ACF does for the textarea)
Best regards,
timmse
I noticed this says solved but I have recently run into the same problem. While adding it in a text field does work, the text field has a div element surrounding it, which means each heading will have a div around it. Is there a workaround for this?
Hi Jason,
Which text element do you use? Basic text or rich text? Which Dynamic Data Provider and which type of dynamic data field do you use?
With the basic text element, you can set the HTML tag to whatever you like:
If you always want to have an h-tag, set the tag to custom and enter the desired h-tag.
