printing the value on the web page is not the right thing to do as there could be possible operations before saving the value to the database but if you setup form's notification, have you checked if it works with form's email notifications?
That is simply to test the content of the field as it's capturing it raw from the post. I'm very aware of the email notification feature, but it's too limited for what we need to implement. I simply need the form to be capturing the data as HTML so I can process it and apply it to the emails. I don't want to store it and I need to take the content of the form and pass it to a custom email function as it needs to be applied to a template and then sent out through a custom API integration.
The first test I did with an image was to just put it in the body and try to send it, and nothing came through. That's when I went to look at the field capture. At no point in this process is printing it to the page the intended solution, it's simply to try and see what it's doing.
If your fields work this way for other purposes, fine I guess, but it's not documented anywhere and there is no way of knowing this. At the end of the day it's a WYSIWYG field that appears to not be doing what you'd expect it to do, so you can surely understand the confusion!
I just want a field that can allow the user to visually input their content, including images, and then capture that as HTML for further processing. Please correct me if I'm wrong, but that is the definition of a WYSIWYG field. I'd use an alternative like bootstrap, but it I doubt it would capture the field through your API when the form is submitted, and the whole point is to use Toolset if possible for its simplicitiy.
I'm not sure of the exact context, but on my own test site I used the cred_save_data hook to process the submitted form content, which includes a Types wysiwyg field and a generic wysiwyg field.
The $_POST object includes both fields, and both include markup (e.g. strong and em tags), and in this example below from a test I just submitted, where I included an inline image in the field, it also includes the img tag pointing to the image.
Array
(
[wpcf-whizzer] => A types <strong>wysiwyg</strong> field with <em>text</em> content.
Split over multiple lines.
[whizzy] => A <strong>generic</strong> wysiwyg field with simple <em>text</em> content.
But the text is split over multiple lines.
And there is an image:
<img class=\"alignnone size-medium wp-image-12\" src=\"<em><u>hidden link</u></em>\" alt=\"\" width=\"214\" height=\"300\" />
[form_submit_1] => Submit
[_cred_cred_wpnonce_cred_form_6_1] => d637fd9c26
[_cred_cred_prefix_post_id] => 15
[_cred_cred_prefix_cred_container_id] => 7
[_cred_cred_prefix_form_id] => 6
[_cred_cred_prefix_form_count] => 1
)
The text includes newlines, not p or br tags.
I believe that's how pre-Gutenberg post content was stored, and that's why the WordPress function wpautop exists.
You should be able to extract the field value from the $_POST object into a variable, and then pass that variable through the wpautop function, which will convert line breaks into markup with p and br tags.
You can then do whatever you need with that re-formatted string.
Thanks for weighing in on this. I did ask Minesh if autop was a factor back in my first post but we seem to have gotten sidetracked and that question was never answered.
I haven't had time to test this properly yet, but it does look like the wpautop() function might be the solution here as in my initial trials of it, it does seem to provide the correctly <p>'d results. I don't know about the images yet, that one did seem weird to me, but I think the issue I saw may have been due to nl2br() being used.
If you could bare with me a few more days I'll get a proper answer and resolution to this thread so we can be absolutely sure it fits the requirements.
