Override for WYSIWYG behaviour to add paragraph tags

(Douglas (@finnatic at @waikato)) #1

We have some assets with a metadata schema applied where we have metadata WYSIWYG fields.

 

With the old editor, text could be added to that field and we could rely on there being nothing added by Matrix.

 

With the new viper editor, text added to the field appears to be getting wrapped in a paragraph text e.g. where we have "<span>text we don't want wrapped in a p tag</span>" we instead now get "<p><span>text we don't want wrapped in a p tag</span></p>"

 

Is there anyway to configure a metadata WYSIWYG field or the editor to adjust this behaviour?

(Bart Banda) #2

I don't think so, the WYSIWYG has a rule that everything needs to be in block elements I think. Could you maybe add a class to those <p> tags and style it with CSS to make it appear inline or potentially run JS over them? Why do they need to be in <span> tags only and not <p>?

(Douglas (@finnatic at @waikato)) #3
"I don't think so, the WYSIWYG has a rule that everything needs to be in block elements I think."
 
IIRC that's a change from the old editor, such that functionality developed with the old editor now has issues which weren't immediately apparent from the change documentation.
 
We use listings a lot, and when we're outputting metadata fields which didn't have paragraph element tags wrapped around them before that can cause problems for the markup and css styling due to the DOM change from adding the paragraph element.
 
"Could you maybe add a class to those <p> tags and style it with CSS to make it appear inline or potentially run JS over them? Why do they need to be in <span> tags only and not <p>?"
 
We've found a class that remedies the problem that sparked this post initially, but I think we may have to consider metadata schema changes in other places.  I'm thinking that there are going to be situations where we need to consider carefully between raw html / WYSIWYG in content and the relevant metadata types.
 
Can I ask is the Editor behaviour configurable or documented?  Documentation would be useful in communicating things like 'don't put <script>...</script> in a WYSIWYG as the editor will just remove the code.' - the manuals at the moment just say:
 
"You can use the Source Editor to modify the HTML code of your content. Once you are satisfied with your work, click the Apply Changes button to return to the Edit+ Editor WYSIWYG Content Container ."
 
however that does not say anything about the markup being modified following the 'apply changes' button being clicked.
(Bart Banda) #4

 

IIRC that's a change from the old editor, such that functionality developed with the old editor now has issues which weren't immediately apparent from the change documentation.

 

Sounds like this is actually a bug with the old WYSIWYG editor. I think the main reason of the WYSIWYG editor is to put all text in block level HTML elements for HTML validation and accessibility reason, so we might have to look into fixing it for the classic WYSIWYG. 

 

If you are just wanting to have text in <span> tags (as in, inline and not in block), then maybe just a simple text area would suffice? Unless you are using things like <a> tags in that content.

 

Alternatively, you could always use a keyword modifier when you print that metadata field on the front end to replace <p> tags with nothing? Something like %asset_metadata_wysiwyg^replace:<p>:^replace:<\/p>:%  ?

(Greg Sherwood) #5

The Viper WYSIWYG editor has a config option to tell each instance of it what you want the top level tags to be. By default, it uses P tags, but you can also have it use DIVs or SPANs instead, or even no tags so it wont wrap text in anything.

 

Matrix would need a config option (presumably for WYSIWYG metadata fields) to allow you to set this per instance.

(Andrew Harris) #6

This (a localised config option) would be very nice if it could be done.

 

We have semantic HTML structures in our templates using HTML5 tags which the WYSIWYG insists on 'breaking' with unwanted P tags.

(Douglas (@finnatic at @waikato)) #7
"Sounds like this is actually a bug with the old WYSIWYG editor."
 
Squiz would be best placed to determine that - but I know we took advantage of the content not being wrapped in additional tags, and woowoowoo's organisation sounds like it has too, so making a change to the old editor might impact numerous installs of Matrix.
 
Bart's keyword modifier works nicely in the situation that prompted this post and may work elsewhere.  Something where you could configure the output from Viper  in a similar way to how you can currently adjust the presentation for a matrix div would be nice if possible.
(Douglas (@finnatic at @waikato)) #8

Squiz map 9890 - https://squizmap.squiz.net/matrix/9890 - created to spur development of some configuration options.