HTML stripped from confirmation email

Thanks for this report.

Can you clarify “HTML tags are stripped when the settings are saved”. Where are you seeing that?

We use standard p, br and a tags in the textarea where we can change the text for the confirmation email (SpeakOut! > settings > confirmation emails) I change the serialized data directly in the options table. However, this is not a solution. Any changes in the settings would overwrite this.

OK, this is sorted out in 1.8.2 – there was a strip_tags() command that I have tweaked to allow certain tags which makes the HTML work.

Appreciate the report.

Awesome, thank you! Allow me to be greedy! Today, people are used to high quality HTML emails. A simple HTML email is better than plain text. However, it would be much more elegant, if we could add CSS and complex HTML. Could you tweak the strip_tags command so that even tables and CSS would be accepted? At least tables and inline css styles should be possible. That’s enough for acceptable HTML emails.

Hi 123host
Thanks for your support and bug fixing. We will contribute a little something.
Project coordinator for MKJ2

• This reply was modified 6 years, 9 months ago by tomtodd.

I have allowed the <span> tag so styling is supported e.g. <span style=”color:#FF0000;”>

Have also enabled the <table> <tr> and <td> tags.

But…this is only a “please confirm your email address” message. How complex does it need to be?

Thanks for the donation! A rare treat, much appreciated.

Thanks for the support! No need for a complex email, but a pretty one. ?? These days, users expect large buttons and stuff. Would you mind posting the mod here? So we wouldn’t have to wait for the update.

Sure, it was quite simple

change /wp-content/plugins/speakout/includes/class.settings.php – line 142

$this->confirm_message = strip_tags( nl2br( stripslashes( $_POST['confirm_message'] )),'<em><strong><hr><span><br /><table><tr><td>' );

We convert textarea /r/n to <br /> and then strip all tags except em, strong, hr, span, br, table, tr and td.

change /wp-content/plugins/speakout/includes/settings.view.php – line 198

<textarea name="confirm_message" id="confirm_message" cols="80" rows="6"><?php echo str_replace("<br />", "",$the_settings->confirm_message); ?></textarea>

This stops the <br /> being displayed in the text area otherwise it keeps adding additional br tags each time it is saved.

The line numbers may not be perfect as they are my updated files, but it should be close.

Thanks a lot. Almost there. I added the <a> and <p> tags. The textarea line breaks were not converted to <br />. Inline styles are working, too. Nice! The <a> tag is quite important, in my humble opinion. Is there a reason not to include the <p> tag? Anybody who can write HTML will probably know how to use is.

Yes, I intentionally have not allowed <a> tags to minimise the possibility of phishing attacks where a malicious URL is hidden behind a link. This will force URLS to be displayed openly.

You can always enable it yourself by adding <a> to the edit above for /wp-content/plugins/speakout/includes/class.settings.php

I get your point. However, you wouldn’t believe how, say, unexperienced users are. To manually copy a link and paste it in the browser is without any doubt some challenge for many. I have customers who asked me: What is an URL? Where should I put it?

Overwriting core files is always a bad idea, since it is not update-safe. A hook would be the way to go.

Don’t get me wrong: I appreciate your effort and support and thank you very much for sharing this plugin with us. These are just some ideas for improvements (from the user’s point of view).

Yes and Yes.

But these days, isn’t something like https://example.com in an email converted into an active link?

Usually it is. But you can’t depend on it. I use Thunderbird, and the confirmation link was not converted to a clickable link. Don’t know why, but it wasn’t. Furthermore, the line breaks were not converted to proper HTML line breaks. The result was something like this:

Hello, Thank you for signing our petition. Please confirm your email: https://example.com/?dkspeakoutconfirm=242f2b489c908b9f&lang=

By the way, suddenly WordPress stopped sending the confirmation emails. I couldn’t figure out why. Then I found that due to an autofill mistake a text was saved instead of a proper email (settings > confirmation emails > sender email). If you don’t fill in a fully valid email address, it won’t send any email at all. Might be a good idea to add a warning and save youself some trouble. ??

• This reply was modified 6 years, 9 months ago by mkj2.
• This reply was modified 6 years, 9 months ago by mkj2.

I have just released version 1.8.2 which includes all the HTML fixes hopefully. And your German fix.

Let me know how the confirmation email goes. Looks good to me, but I am not an end user.