[Resolved] Generic WYSIWYG Field Not Saving Formatting

[Author]

Posts

[Dave]

Tell us what you are trying to do?
Use the generic WYSIWYG field to capture HTML formatted text that can then be passed to other functions and output into an HTML template such as an email.

Basically, I've got a form setup to capture WYSIWYG information, here is the field from the form:

<label for="%%FORM_ID%%_email_message" class='required'>[cred_i18n name='email-message-label']Message Content:[/cred_i18n]</label>
  [cred_generic_field type='wysiwyg' field='email-message']
  {
  "required":1,
  "default":""
  }
  [/cred_generic_field]

But when I read the $_POST array, the field has submitted as plain text so any output of the field is simple a plain string, no HTML.

I've seen other posts mention surrounding the field with the [autop] tag, but that I think is for output and it just causes the field to not load in this instance anyways.

I'm sure I'm doing something wrong, but your documentation doesn't clarify if anything special needs to be done to get the WYSIWYG field working for HTML output so I don't know what. Could someone please clarify how you get HTML formatted data from the generic WYSIWYG field please.

[Minesh]

Hello. Thank you for contacting the Toolset support.

Can you enable the required tags you want to allow the users to save with your form field and check if that helps to resolve your issue:
- https://toolset.com/course-lesson/selecting-allowed-tags-in-front-end-forms/

[Dave]

Sorry, I should have mentioned in the OP, but all the tags are turned on already so I could test exactly that as shown in screenshot 126.

If you look at screenshot 127 you can see the paragraph formatted text in the 'email-message' generic field I provided above. Printing, echoing, dumping or loading the content via variable into other places, regardless, the $_POST entry in any capacity always gives unformatted results as shown in screenshot 128.

This is the specific bit of code used to generate the results in screenshot 128, but any method I've tried has the same result.

print 'Message Content = <br /><br />';
print_r( $_POST['email-message'] );

[Minesh]

Here is a sandbox site and you can auto-login to it using the following link:
- hidden link

Can you setup the form with generic field as you have and check if you able to reproduce the issue.

Please share all required details to see the issue.

[Dave]

I've rebuilt a stripped-back version for you, but it uses the exact same form and layouts etc and I can confirm it behaves in exactly the same way.

I've made the page the home page so it'll load straight up for you, and you just click on the 'Email' button that's visible in the lower right area once it loads, you can't miss it. From there, a form will pop up and you just need to fill the form in, all dropdowns have one option in them, so you need to just select something, the Parent dropdown should be a Select2, but it isn't working for some reason on this site and I haven't bothered to debug it.

Once you submit the form the code will catch it and print out the WYSIWYG field and die so that it just halts with the output, and you can see it is exactly the same.

Just to confirm, I have also turned on all the tags in the Settings as you mentioned in your first reply, so the behaviour seems to be consistent.

[Minesh]

I'm not sure what formatting is missing but with the same for you setup.

I've added the following HTML to the "Message Content" field in "Text" mode of this field:

<div>

<h1> First Heading </h1> 
<ul>
	<li>This is the text 1</li>
         <li>This is the text 2</li>
<li>This is the text 3</li>
<li>This is the text 4</li>
<li>This is the text 5</li>

</ul>


</div>

When I click on submit button of the form I can see the following. Please check the following screenshot: hidden link

Can you please send me with what text and format I should test?

[Dave]

The "Text" mode of the field isn't in question, that indeed does work fine IF you enter the HTML tags.

But the whole point of a WYSISYG field is that you can type anything into the 'Visual' mode and it converts that to HTML by adding the tags. This is what I demonstrated in screenshot 127, so apologies if that wasn't clear. Given the use case I've described, it didn't cross my mind to clarify.

So if you look at my screenshots, I have put paragraph formatted text into the 'Visual' editor, and it stores it as a string, completely ignoring the WYSIWYG functionality. This is the issue I'm having.

I've done some more testing and it seems really random what works and what doesn't. Making any text bold works, this is carried over to the output, but underlining is stripped out / ignored like paragraphs, and the link URL field that loads when you try to make something a link is inactive but there's no disabled status on the input tag.

[Dave]

Hi Minesh, just checking to see if there was any updates on this please.

[Minesh]

I created another sandbox.

You can auto-login to site using the following link:
- hidden link

Added custom post type "Book" and custom field "Book Description".

Then created a form where I've added "Book Description" field as well as generic field "email message".

Page where form is added:
- hidden link

This is the form:
- hidden link

Added the following hook to "Custom Code" section:
=> hidden link

add_action('cred_before_save_data', 'func_test_generic_wysiwyg_field',10,1);
function func_test_generic_wysiwyg_field($form_data) {
   
    if ($form_data['id']==18) {
      echo "<pre>";
      print 'Message custom field  = <br /><br />';
      print_r( $_POST['email-message'] );
      
      print 'Message generic field = <br /><br />';
      print_r( $_POST['email-message'] );
      
        print_r($_POST);
        exit;
    }
}

I can see both the fields displayed how the text added with paragraphs.

If you are using popup and add the form to that popup that affects the output its weird and you should try to actually save the value and check the field output. Do you see it working?

[Dave]

I've just been going over what you've suggested, and I'm afraid it doesn't address the core issue of missing paragraph formatting.

I had to tweek your code as your were outputting the same field twice, and I assumed the point was to output the custom field and then the generic field. So the code is now this:

add_action('cred_before_save_data', 'func_test_generic_wysiwyg_field',10,1);
function func_test_generic_wysiwyg_field($form_data) {
   
    if ($form_data['id']==18) {
      //echo "<pre>";
      print 'Book Description custom field  = <br /><br />';
      print_r( $_POST['wpcf-book-description'] );
      print '<br /><br />';
      
      print 'Email Message generic field = <br /><br />';
      print_r( $_POST['email-message'] );
      print '<br /><br />';
      
        print_r($_POST);
        exit;
    }
}

I've entered test information on different lines with different formatting, as shown in screenshot 132.

With your code it kinda looks ok, see screenshot 133. But this is all the <pre> tag pretending it's formatted properly, when in fact it's just forcing the output to be styled in the generic <pre> way, something like this probably:

pre {
  display: block;
  font-family: monospace;
  white-space: pre;
  margin: 1em 0;
}

If I remove the <pre> tag, then we can see the issue remains (see screenshot 134).

If I copy the preformatted text in from another editor, such as Google Docs for example, it maintains all of the formatting except the paragraphs. So I'm not sure why that didn't work before, but it seems consistent.

You can even check the Text editor when pasted text is used and see the paragraph formatting is missing (screenshot 135).

If I try creating the formatted fields in the editor (the Book Description field in screenshot 136) then it lays it out ok, but doesn't retain the paragraph formatting; and if I try to force them in manually (the email message field in screenshot 136) it doesn't process them. You can see the outcome in screenshot 137.

None of this seems to make sense as the WYSIWYG editor is set to paragraph and is showing it in the select field in the top left and the editor status in the bottom left. So how is this intended to be used?

All of this seems absolutely consistent with my main site, so I don't think the modal is the issue here, but even if that is a factor, this is all happening on your sandbox site. I need this field to capture fully formatted text for use in emails, so I can't rely on trying to dupe the output with the <pre> tag or loosing the formatting as the end user won't have a clue how to work with it. There must be a reason the fields are stripping out the <p> tags, but other parts of WordPress don't. Does this have anything to do with an implementation of wp_autop()?

[Dave]

Just to add to the inconsistencies in function, I've just stumbled across another issue cred fields seem to be having with <p> tags that may or may not be related, but I thought I'd add it in here just in case.

On another form I have a textarea custom field and it collects and stores paragraph formatting correctly, and even renders it with the paragraphs intact (Screenshot 140), and is controlled by this standard code:

<div class="form-group">
  <label for="%%FORM_ID%%_child-staff-notes">[cred_i18n name='child-staff-notes-label']Staff Notes[/cred_i18n]</label>
  [cred_field field='child-staff-notes' force_type='field' class='form-control' output='bootstrap']
</div>

However, if I try using this as a default setting for a generic textarea field, then it outputs the <p> tags, not rendering them, although the exact same field output renders properly by itself and in an editable div (screenshot 143). It uses this code:

<div class="form-group">
    <label for="%%FORM_ID%%_child-staff-notes">[cred_i18n name='child-staff-notes-label']Notes[/cred_i18n]</label>
    <div contenteditable="true">[types field='child-staff-notes' item='@child-token.parent'][/types]</div>
    [cred_generic_field type='textarea' field='tct-notes']
    {
    "required":0,
    "default":"[types field='child-staff-notes' item='@child-token.parent'][/types]"
    }
    [/cred_generic_field]
  </div>

I can't be sure, but this feels like another part of the same problem, so I'd be grateful for further help with this.

[Minesh]

I've added few email log plugins that shows email log:
- hidden link
- hidden link

I've adjusted the code as given under:

add_action('cred_before_save_data', 'func_test_generic_wysiwyg_field',10,1);
function func_test_generic_wysiwyg_field($form_data) {
   
    if ($form_data['id']==18) {
      //echo "<pre>";
      print 'Book Description custom field  = <br /><br />';
      print_r( $_POST['wpcf-book-description'] );
      print '<br /><br />';
      
      print 'Email Message generic field = <br /><br />';
      print_r( $_POST['email-message'] );
      print '<br /><br />';
      
        print_r($_POST);
      
   $book_desc = nl2br( $_POST['wpcf-book-description'] );
   $email_message = nl2br( $_POST['email-message'] );
      
$from = get_option('admin_email');

//// you can change $to email value if required. 
$to = 'minesh.s@onthegosystems.com';   
$subject = 'The subject';
$body =   $book_desc."<hr /><hr />".$email_message;
$headers = 'From: '. $email . "\r\n" .
    'Reply-To: ' . $email . "\r\n";
      
//$headers .= "MIME-Version: 1.0\r\n";
//$headers .= "Content-Type: text/html; charset=ISO-8859-1\r\n";
$headers = array('MIME-Version: 1.0','Content-Type: text/html; charset=ISO-8859-1',"From: My Site Name <$from>");

$sent = wp_mail( $to, $subject, $body, $headers );
    
if($sent) {
   echo "<br /> <br /> email sent sucessfully.";
}
else  {
  //message wasn't sent       
}
      
      
      
        exit;
    }
}

Now, when you submit the form with email log you will see new items added and when you check the email log HTML output it does display the correct output for email body.
- hidden link

[Dave]

This is definitely a lot closer, the nlbr function definitely simulates paragraphs pretty well, and this may well be enough for now.

With my previous example of input from the previous post, what it outputs is:

One<br />
<br />
<strong>Two</strong><br />
<br />
<span style=\"text-decoration: underline;\">Three</span><br />
<br />
<em>Four</em><hr /><hr />One<br />
<br />
<strong>Two</strong><br />
<br />
<span style=\"text-decoration: underline;\">Three</span><br />
<br />
<em>Four</em>

But I've got to point out that this still isn't addressing the fact the fields are not correctly storing paragraph formatting, and the fact that you've offered two, admittedly functional, workarounds makes me want to ask why the actual issue hasn't been addressed. Is there something wrong with the way these fields are implemented by Toolset that is preventing this?

For now I can (and have been) using the nlbr function to sidestep the issue, but I'd still like the paragraph formatting that these fields are supposed to offer. Do you know why it isn't working and these workarounds are needed?

[Minesh]

It seems for email message, as we use the email header: Content-Type: text/html;

We have to run an addon operation for email body text and to add the line break we have to use the function nl2br.

With the code added to "Custom Code" section, for testing purpose I've change the following line of code:

   $book_desc =  $_POST['wpcf-book-description'];
   $email_message = nl2br( $_POST['email-message'] );

As you can see and you know that "book-description" is normal WYSIWYG filed (with which the format works) and "email-message" field is generic WYSIWYG field(which which you claim the format does not works).

So, as you can see we are passing the normal value without converting to nl2br for the field "book-description" (with which the format works) but when we see the "book-description" text in email body the format does not works.

If we apply nl2br to both fields "book-description" and "email-message" then I can see the it works as expected in the email body. I suggest you should use nl2br where applicable for your email message body.

[Dave]

As I said, the nl2br() work around is barely ok, it does format the text roughly correctly, but this is still avoiding answering my question as to why these fields work this way in the first place. This is not the correct behaviour for a WYSIWGY field!

I've also found that they do not handle images properly either. I've tried this on my dev site and again on your sandbox and the results are identical. When you try to include an image in the fields with the add media button, then it adds extra quotes and slashes to the URL, making it unusable (see screenshot 144).

What is going on with the formatting in these WYSIWGY fields?!