New to the community? Start here

[Forminator Pro] Forminator removes HTML from success message

I created a form with an inline message after form submission.
The inline message allows simple HTML markup (bold, ul, … ) – however, upon saving that markup is lost and the message is saved in plain text.

I’ve checked the workflow: The form submits the HTML code correctly. When I check the DB right after updating the form, I can see a plain-text version of my message there. So the HTML markup is lost while saving the form.

Problem seems to be in “forminator/admin/classes/class-admin-ajax.php” in function “save_builder”. In line 460 the function “forminator_sanitize_field()” removes the HTML tags from my message.

Mon, 7 Sep 2020 12:21:34
More Forminator Pro discussions
Forminator Pro
  • Daniel F. Blanco
    • Flash Drive

    Hi Philipp,

    I hope you are doing good! I was trying to reproduce that on my test site but the inline message is saved properly and even displayed in the front-end after submission.

    Could you please create a staging site (clone) so that we can have an in-depth look at the issue? I might need to escalate this but I want to try a few things first.

    Best,
    Dani

    • Philipp
      • The Bug Hunter

      Sure, I’ve created a staging environment for you to look at and enabled Support Access via the WPMU DEV Dashboard plugin. The staging URL is https://divimode.staging.wpmudev.host/

      Steps to reproduce:

      – Edit the form “No HTML in Inline Message”
      – Open the section “Behavior”
      – Format the “After submission” message (make something bold, add a line break)
      – Update the form and reload the page
      – When you check the “Behavior” section again, you see the plain text message.

      Let me know if you need more details. Thanks :slight_smile: Philipp

  • Daniel F. Blanco
    • Flash Drive

    And Philipp,
    Once you create the staging site please use this form to send us the login details:

    https://wpmudev.com/contact/#i-have-a-different-question

    Using this template:

    ‘Subject: “Attn: DANIEL FRAGA BLANCO”

    – Admin login ( if Multisite please provide Super Admin details ):
    Login URL:
    Admin Username:
    Admin Password:

    – FTP credentials
    Hostname:
    Username:
    Password:
    Port:

    And the URL to the relevant form.’

    Keep in mind the subject line as it ensures that it gets assigned to me.

    Best,
    Dani

  • Daniel F. Blanco
    • Flash Drive

    Hi Philipp,

    Thanks. I was reviewing your form and I am now able to reproduce your issue. I’ve tried to create a new different form and there the inline message keeps formatting as expected.

    I have make sure it wasn’t plugin or them conflict so I am escalating this to our Second Line Support team so that they can have a look and get back to us.

    Best,
    Dani

  • Philipp
    • The Bug Hunter

    I notice that the issue is not limited to the “After submission” message, but also strips HTML from all email notifications upon saving. I cannot format any email.

    → The problems are limited to “Registration” and “Login” forms!

    I’ve had another look and I can confirm that the problem is caused by calling forminator_sanitize_field() That function uses sanitize_text_field() on the input value and that function strips all HTML tags from the input value.

    Fix 1: It appears that you have had a similar issue before and introduced the wp filter “forminator_builder_data_settings_before_saving” which overwrites one of the incorrectly escaped settings with a properly escaped value. I think the function change_form_settings() in abstract class Forminator_User needs to be extended to handle all fields that can contain HTML code.

    Fix 2: Also, in class-admin-ajax.php, in line 489 the plugin restores the unescaped email body for notifications. However, that logic only works for regular email notifications, not for “register-user” notifications.

    I have made some small code changes to verify those two cases – the changes are attached as screenshots. After applying both changes the settings are correctly saved on my site.

    Fix 1:
    [attachments are only viewable by logged-in members]

    Fix 2:
    [attachments are only viewable by logged-in members]

  • Panos
    • SLS

    Hey hey Philipp Stracker ! Nice to see you around!

    In class-admin-ajax.php it checks for specific settings after forminator_sanitize_field() is called and the markup should be re-added there, eg in this part:

    		if ( isset( $form_data['settings']['thankyou-message'] ) ) {
			$settings['thankyou-message'] = $form_data['settings']['thankyou-message'];
		}

    so markup should be stored in settings in db.

    I had a look on that specific form and the settings seem a bit weird. For instance the bold text that you have on email-thankyou-message should be on thankyou-message key. And that thankyou-message is completely missing when submitting the form. Could this form have been exported from an older Forminator version and imported in a later version?

    I have also asked the devs to have a look as I’m not sure why the settings are like this. I’ll let you know once I have a reply :slight_smile:

    Kind regards!

    • Philipp
      • The Bug Hunter

      Hi Panos , nice to hear from you :wink:

      That form is 3 days old and I’ve created it on the site where I have the problems. Also, in the past days, I’ve created several forms for testing, on all local, stage, and live websites.

      To be sure, I’ve now completely deleted Forminator and re-installed it on the staging site. Then I created the brand-new form “New Registration (Sep-08)” and tested this again, but still get the same results.

      https://www.screencast.com/users/Philipp-Stracker/folders/Snagit/media/f6e8355f-6abd-402d-be93-c69066f886a9/embed

      I can see the code that restores the “thankyou-message” in class-admin-ajax.php but that “thankyou-message” is not used by the user registration template. If you check the front-user-registration.php file you will find the function change_thankyou_message( … ) which overwrites the “thankyou-message” the “manual-thankyou-message” value.

      I think that’s a very specific issue related to user registration forms (and maybe also login forms).

  • Panos
    • SLS

    Then there’s something going on but haven’t spotted it yet. I’m not sure if it’s supposed to switch settings like that or what triggers this switch. I just created a new registration form on your staging site and it does get saved fine.

    I’m trying to spot something in the form settings or fields but haven’t managed yet. I’ll have another look and if I don’t find anything I’ll wait for a reply from the Forminator devs and will keep you updated :slight_smile:

  • Philipp
    • The Bug Hunter

    I think we’re getting close

    I’ve had a look at your newly created form and it also saves as expected for me.
    When checking your forms settings I found the difference between my test-form and yours:

    I use the setting “User Account Activation: Manual” and “Activation Email: None”

    → The problem is definitely caused by the “User Activation Method” flag. The “default” method works as expected, but the “Email” and “Manual” methods cause the behavior described in my previous posts.

    [attachments are only viewable by logged-in members]

  • Panos
    • SLS

    I just heard back from devs and that switch is indeed expected. So the issue is what you initially mentioned, about sanitization. I believe you have already patched this so I’ll just confirm that this will be fixed on next release :slight_smile:

    It was nice talking to you Philipp!

  • Support @ MSD
    • WPMU DEV Initiate

    Hey guys, this problem isnt limited to certain form types for success messages.

    i have the same issue where our Custom HTML for Success message is sanitizing. ripping out everything and wrapping in just the text in a P Tag. now for us, its either, we have a plugin conflict – or – it was the 1.14 update.

    i have a dev with 1.13.5 – and its working just fine. and we are getting ready to push our Production live , doing final testing… when we hit this wall… and that’s with the 1.14 update from the 24th.

  • Panos
    • SLS

    Hi Support @ MSD ,

    We didn’t have any similar reports as far as I know and I can’t replicate this issue in a few test sites where tried this out with version 1.14. I’m not ruling out plugin conflict, that is always a very possible case in most of the issues. Only way is to try replicating this by deactivating the other plugins. An easy way to do so on a Production site is by using plugins like
    https://wordpress.org/plugins/check-conflicts/
    or
    https://wordpress.org/plugins/health-check/

    Both allow you to have specific plugins/themes active for current user without affecting other users/visitors on your site.

    Something else that could interfere is if you have any custom code that is using Forminator’s filters or any filter that would affect the output of that field. So I would also suggest to remove any custom code temporarily to see if that makes any difference.

    This thread is about a different issue though, if none of the above suggestions work please open a new thread or visit our chat agents to have a closer look on your issue.

    Kind regards!

  • Panos
    • SLS

    I just realised I misread your question. Apologies for that. I could replicate that and this will be fixed on next release.

    Until next release is out you can try replacing file:
    wp-content/plugins/forminator/library/abstracts/abstract-class-user.php
    with the one attached here.

    I would strongly recommend to first try replace this on a testing/staging site before doing so in you production site.

    Kind regards!

  • Support @ MSD
    • WPMU DEV Initiate

    getting closer – you got the H3s

    Original Code – Client Inputted / Needed ——————————————>

    <h3>Thanks for your request.</h3>
<p>Here's what you can expect now.</p>
<div class="container">
<div class="col">
<div class="steps"><b>Step 1</b>
<p>Submit your request via form on this site.</p>
</div>
</div>
<div class="col">
<div class="steps"><b>Step 2</b>
<p>Receive an email in 1 business day with an estimated timeline.</p>
</div>
</div>
<div class="col">
<div class="steps"><b>Step 3</b>
<p>We’ll email you the deliverables that you requested.</p>
</div>
</div>
</div>

    VERSES the Code After Input with the New PHP Doc you sent —————->

    <p>Thanks for your request.</p>
<p>Here's what you can expect now.</p>
<p>Step 1</p>
<p>Submit your request via form on this site.</p>
<p>Step 2</p>
<p>Receive an email in 1 business day with an estimated timeline.</p>
<p>Step 3</p>
<p>We’ll email you the deliverables that you requested.</p>
  • Support @ MSD
    • WPMU DEV Initiate

    i updated the tags – on the new file

    				$allowed_html = array(
					'a'      => array(
						'href'  => true,
						'title' => true,
						'target' => true,
					),
					'br'     => array(),
					'em'     => array(),
					'strong' => array(),
					'div' => array(
						'class' => true,
					),
					'img' => array(
							'src' => true,
					),
					'p'      => array(
						'style' => true,
					),
					'ul'     => array(),
					'ol'     => array(),
					'li'     => array(),
					'h3'     => array(),
					'b'     => array(),
				);

    got it working

  • Panos
    • SLS

    Thanks for sharing this Support @ MSD ,

    However I don’t think that this will be included in following release, so your change for the h3 tag will be removed upon next update. It will support by default all tags in the wysiwyg editor in the behavior page which doesn’t include any h tags. In following release though there should be a new filter added that you can use to edit the allowed html tags there.

    You can use the following snippet for the h3 tag:

    add_filter( 'forminator_change_form_allowed_html', function( $allowed_html ){
	$allowed_html[ 'h3' ] = array();
	return $allowed_html;
} );

    You can add the above snippet in a mu-plugin, if you are not familiar with mu-plugins you can read about them here :
    https://wpmudev.com/docs/using-wordpress/installing-wordpress-plugins/#installing-mu-plugins

    If you prefer you can add this in you theme’s functions.php instead, however make sure that you use a child theme so you don’t lose your changes upon theme updates.

    So having that change made on current version should allow you to keep them for current version, and when updated to next version, that filter should still keep h3 tag as an allowed tag.

    Kind regards!