I don’t when it started, but recently my PHP forms that call the mail() function have stopped working. Upon closer inspection of the Freeway output, I notice that valid email addresses in the PHP block are encoded into HTML number codes, presumably to provide some level of spam protection.
[Please note that in this example I have replaced all of the semicolons with colons so that you can see what I am seeing; otherwise freewaytalk converts them back to ASCII.]
My problem is that the email is not sent, although a month or so ago it worked with no problem, and nothing in the page has been changed.
When I edit the Freeway output to replace the HTML number codes with the actual text and upload to my server, the mail is sent perfectly. But it seems that this “conversion” is causing the problem, or that during the execution of the PHP code it isn’t being converted back into ASCII text.
I don’t know if I am explaining this very clearly - has anyone else had this problem or found a solution? Thanks for any help you may be able to provide.
When I edit the Freeway output to replace the HTML number codes with the actual text and upload to my server, the mail is sent perfectly. But it seems that this “conversion” is causing the problem, or that during the execution of the PHP code it isn’t being converted back into ASCII text.
There’s a preference in the Document Setup to “mask” e-mail addresses in Freeway 5. The quickest thing is to just turn that off.
The reason the PHP Feedback Form action is unaffected by this is because the e-mail addresses never go anywhere near the page source. They are all contained in the -go.php file the action creates and links the form to. I think the suggestion (sorry but I can’t recall who mentioned it) that the application skips encoding email addresses inside non-HTML code blocks (PHP, ASP, etc) is a good one.
Regards,
Tim.
On 10 Jun 2008, at 17:14, DeltaDave wrote:
And what is the slow way?
There is also Tim’s PHP Feedback Form action which doesn’t appear to be affected by this?