'Addres:' and 'E-mail:' are supposed to start on a new line, but they don't. If the fields Company en Telephone are filled in then Address and E-mail start on a new line.
I tried to send my message with the PHP mail() funtion to see what output it would generate and here everything was the way it was supposed to be.
Can somebody explain me what's going wrong and how I can fix it?
There's a syntax error in your call to send() above (a lone quote).
That's not causing this though. I'll have to have a closer look, but have you run this with full error reporting on? Does those variables exist all the time even if they are not filled in? If not, they'll be generating notices and choking the script.
If that's not the issue, change \n to \r\n for now and see if it helps. I'm not sure what could cause that issue though.
name,
Thank you for registering your product with Lum.
Registration details:
=====================
Name: name
Company: Address: address1
address2
postcode city
country
Telephone: E-mail: email
Product: product
Serial: serial
Dealer: dealer
Purchase date: purchase_date
Kind regards,
Lum.
It doesn't matter if I use \n or \r\n. But now I did some further tests and I it seems that a simple space character just before a double quote is causing the problem.
Test 1 (no space before closing double quote)
Thanks for the clarification. I'll have a look but if you can work around it for a week or two there's a new version coming out. Otherwise, if there's an obvious bug I'll fix it in subversion and make a quick last minute release of version 2.
/**
* Converts lone LF characters to CRLF
* @param string input
* @return string converted output
*/
public function LFtoCRLF($string)
{
return preg_replace("@(?:(?<!\r)\n)|(?:\r(?!\n))@", "\r\n", $string);
}
/**
* Prevents premature <CRLF>.<CRLF> strings
* Converts any lone LF characters to CRLF
* @param string input
* @return string escaped output
*/
public function makeSafe($string)
{
return str_replace("\r\n.", "\r\n..", $this->LFtoCRLF($string));
}
Those two method are the only bits which would modify your data that way, unless of course QP encoding has a bug (I've not been informed of one) and your code happens to use it (you may not be aware of it if it does). If anybody can see an issue with the above do say so
If it's a QP encoding problem $confirm->addPart($Message, "text/plain", "8bit"); would help.
If you were using NativeMail there are some modifications made against the data so if you let me know which connector you use I can rule that out.
Shenz wrote:Are there other possibilities I can try? Or do I just have to wait for the new version of Swiftmailer to see if that one will work correctly?
Sorry I've decided not to make any more updates to version 2 right now unless they are critical. v3 is sitting in a branch of svn due to very shortly hit the trunk. I'm just tying up some loose ends then I need to document it, convert to PHP4 and release the first rc.
We're only looking at around about a week now. I'm working on this every day and taking time out during quiet patches at work to get this completed. Hopefully the rc will be stable and just become 3.0.0 since the test coverage is very solid.
I basically just need to tie in the complete (updated) API for plugins and write some smoke tests before doing docs and a translation to PHP4.