Bricks Rich Text Element and WYSIWYG Metabox Field gets wrapped in p tag

Bugs
1

I have some rich text in a rich text element and the last line is a WYSIWYG metabox field. The data from this field contains more rich text.

The problem is that if the variable for this WYSIWYG Metabox Field is on a new line in the rich text element of bricks, it automatically wraps all the content in a p tag.

Can Bricks add some logic to prevent this type of behavour?

I realize that in some cases the metabox field needs to be wrapped in a p tag (like for a text metabox field) but this is not always the case.

2

Then you just do not create a new line?

Or you can manually wrap it in another tag like span. I think it would not add p tag if it detects a tag.

Anyway, this is a strange use case. Better to separate them into different elements instead of putting a rich text in another rich text.

3

Then you just do not create a new line?

Your not understanding the problem. The WYSIWYG Editor Bricks uses automatically wraps anything in p tags if it is on a new line and doesn’t have any tags currently wrapping it. This means my dynamic field that inserts rich content (that contains headings and paragraphs) itself all gets wrapped in a p tag breaking the HTML structure.

Better to separate them into different elements instead of putting a rich text in another rich text.

Its not a rich text in another rich text… its extended the original rich text with a dynamic field. If I put it in another one then each will be wrapped in their own div which is not ideal from a HTML structure point of view.

4

I understand the problem very well… That is why I said do not create a new line. Not sure what would happen but you can try this if the WYSIWYG has its own p tag:

This is a paragraph in the rich text.</p>[dynamic data]

And a rich text elements works the same as metabox WYSIWYG fields, which is why I said a rich text in another rich text.

5

For multiple elements, I don’t think it would be too bad if you change the tag from div to span for the html structure to avoid some compatibility issues.

6

You should use the basic text element which will not wrap everything in p tag. The basic element actually needs to be set to p tag which some people forget.

For dynamic content the basic text element is mostly your best option, but of course don’t set it to p then but use standard div option.

I believe there is also a raw output option in metabox for the wysiwyg editor, but then you loose all other markup which is probably not what you want. If text need to flow than wrap the rich text element and basic text in a block or div or something.

7

Thanks for all the suggestions but they are all just workarounds and do not fix the core issue which is to stop the Bricks rich text Editor (which is TinyMCE) wrapping what it thinks are new blocks in p tags. It’s too bad you cannot force the TinyMCE to show the p tags in the Text tab (at least I could not find a way) so we can just edit them as we see fit… anyways

@timmse

After a bit of research I see what needs to be implemented when the TinyMCE editor is initialized

tinyMCE.init({
    ...
    forced_root_block : false
});

This will stop the wrapping of the p tags and use br tag instead (or shift-enter for a p tag). While not pretty it would allow all situations to work.

Now I totally understand in most cases people (including myself) are fine with using p tags to wrap blocks so maybe wherever the editor is used in Bricks a switch right by the TinyMCE editor could allow people to disable the forced root block when needed on that particular TinyMCE editor in the bricks panel.

Also, I do have a workaround already in place which fixes my issue and I also already have the raw option enabled for that field in metabox. In reality though this issue should be addressed properly in Bricks. Workarounds can be messy and are not easily maintainable.

8

@frozenwind Yup that is what I do in this case. Sorry I misinterpret your answer. But in my case it is after a heading so it actually a bit cleaner (since TinyMCE doesn’t remove these tags in the text view).

<h2>This is a Heading.</h2>[dynamic data]

I did just test your way and I was surprised it worked as I know TinyMCE cleans up the p tags and I thought it would mess it up if the dynamic data followed a p tag (and not a heading tag as in my case). It does clean it up (and removes the p tags I put in) but it does still work, at least initially. The problem is that if you go back and edit some of the text it messes things up and assumes the dynamic data is in its own block which it then wraps in a p tag.

In a comment above I suggested a possible solution to fix this issue (having a switch where we can disable force root block for the current TinyMCE editor (not a global setting but set per editor)