Using &sendAsText and getting anyway

I’m using &sendAsText=`1` to send text only messages. However, new lines show up as html code
in the messages.

Shouldn’t using that attribute preventing \n from being converted to
?

Well, after looking into it, I consider this to be a bug. In line 289, the new lines are converted into
’s:



That’s necessary in order to display the message in the thankyou page correctly. But for sending the message as text only, those
have to be removed.

So I think before sending the form a test is needed if sendAsText is set, and then converting the
in the message body back to new lines. This code, inserted at line after line 414 is doing this:



I think this should be fixed. Confirmed?

I’m new to this forum so I may not quite get the style here. Yet honestly, the lack of response in this case irritates me a bit, because it leaves me uncertain if in case of an upgrade, I have to check if that issue is fixed or not in eForm.

As a community, I hope we can work together to improve things. That’s why when I find a bug, I usually report it back, and some feedback would be appreciated then. Sure I can maintain my own version, and in case of special needs I’m used to do that. However, If I’m getting any html in the output of the attribute sendAsText, then I consider this to be a bug and not a special need. Am I reporting it in the wrong place? Is there an official bug tracker somewhere for eForm? If so, please let me know.

Look at the top of the forums at the "Bugs & Support" link. We do have a dedicated tracker for this stuff in fact.

Please have a bit of patience with us as we’re about to release another version of MODx. With that said though, improvements to eForm are certainly appreciated.

Quote from: rthrash at Feb 20, 2007, 10:44 PM

Please have a bit of patience with us as we’re about to release another version of MODx. With that said though, improvements to eForm are certainly appreciated.

... I’m patient by my very nature - if you don’t get that quickly, I will ...

[running to the keyboard and typing frantically] I get the picture, I GET THE PICTURE Ok!

I had seen your post but it slipped my mind (so much does nowadays). This will be remedied in the next versions although in a slightly different way.

Line 289 (in your version) will be replaced with


and when the time comes to populate the &thankyou template (and sendAsText is set) any fields set to ’html’ will have their newlines replaced with
then.

This seems like more work but I find it more logical and clearer for those who might want to doe something with values in the events.

WOW! SUPERFAST REACTION!

Thanks Jelle ...

As for your solution, my sense of logic seems to work a bit differently. I wouldn’t expect the sendAsText attribute to have any effect other than on the format of the mail. Though I admit I may not understand fully what others possibly want to do with the values, I see some danger of inconsistency when setting that attribute is affecting other functions. If it’s implemented on replacing the
just in the message body before the mail is sent and not touching anything else, I can safely turn the setting on or off without having to worry about anything else, since the processing before sending the mail is exactly the same for all cases. Just my two cents ...

Yes, there’s something to be said for that as well. Either way, I’ll revisit this issue in the next major version (which will be a while in coming as I’m occupied with other things then coding for a while) and come up with a clear and solid solution,

As it is it’s not all that logic to set a field type to html if the aim is merely to format the thankyou page. (setting the type to html is the only time nl’s are translated to
). Instead for textareas nl’s should always be translated to
when displayed in the browser, regardless if it’s type is considered html or a mere string...