Pods: API for WYSIWYG field never renders 'P' tags even if explicitly whitelisted

[JordanFAVRE]

Describe the bug
Whatever settings I have, only the CLEditor will save/render the <p> tags in the API output of the field.

To Reproduce
Steps to reproduce the behavior:
Have a Visual Editor editor field and save it

Expected behavior
Have a setting to preserve <p> in the source of the code and have them render in the API output

Screenshots
If applicable, add screenshots to help explain your problem.

Pods Version

Latest

WordPress Environment

4.9.8

[jimtrue]

@JordanFAVRE Did you check the Additional Options for your field? Specifically 'Enable wpautop' and Allowed HTML Tags?

[JordanFAVRE]

Yes I did. Tinymce removes <p> on save

[jimtrue]

@JordanFAVRE I notice you didn't include your Debug Details (as per the bug template). Did you check for conflicts? The above specific items work out of the box for me, if I only stay in the 'text' editor portion of TinyMCE. If I flip back and forth any <p>'s are automatically stripped by TinyMCE (ie, just like it does in WordPress's editor).

[jimtrue]

@JordanFAVRE Added a screenshot. That is what you're talking about, right? I have them in the 'text/html' editor and they stay after 'save' _unless_ I flip over to Visual which automatically strips out any manually input <p> and replaces them with double carriage return.

[JordanFAVRE]

Yes this exactly what this ticket is about.

• CLEditor preserves P and allows for visual editing.
• TinyMCE forces me to use Text mode, and clients can not be expected to understand/know/remember this.

It is possible indeed to use this work around (we did for a while), it is however not what one would expect to experience based on the fact the admin UI shows exactly the same set of available options for both types of editors.

[jimtrue]

The regular editor (which is TinyMCE) on a regular page always does exactly what I demonstrated above. It doesn't preserve

and it won't when you flip back and forth between Visual/Text, because that's not how the WordPress Editor works.

If you want to preserve exact HTML, use the Command Line Editor (or code field).

[benfavre]

This is how TinyMCE works, yes. Still, that is not what the admin UI suggests is possible when allowing for a whitelist of html tags including <p>.
You keep indicating work arounds, thanks, but the issue still holds imo.

[sc0ttkclark]

Given how outdated CLEditor is, it's already on our short list for deprecating as an available option. I don't think we should spend time dealing with the problem here but instead deal with it in whatever we replace it with (if we add a future option for alternative editor).

[benfavre]

Are we not instanciating TinyMCE with our own params ? Can we not make the behavior of it consistant with the available field options and preserve <p> tags.
Optionaly we could allow for the configuration of the API field output to be filtered by wp_autop and add the <p> tags back in ? Right now there is no way for me to get my content out to another site with the appropriate tags unless I use a code field or I have to extend my API manually to add a filter.

[sc0ttkclark]

CLEditor: https://github.com/pods-framework/pods/blob/2.x/ui/fields/cleditor.php
TinyMCE: https://github.com/pods-framework/pods/blob/2.x/ui/fields/tinymce.php

[benfavre]

Ok thanks.
When considering what is necessary to modify TinyMCE to preserve markup (e.g.: https://wordpress.stackexchange.com/questions/214588/tinymce-editor-is-breaking-my-beautiful-html)

I would like to suggest allowing for custom code filters for the API field output. Haven't found an issue suggesting this. Should we open an NFR ?

[sc0ttkclark]

PR that adds a filter would be perfectly acceptable here, that sounds like the best step here.

[latheeshvmv]

Has this been fixed?

tag does not shows up