mail() fail

I was recently called upon to troubleshoot the mail script powering a website’s contact form, which for some reason unbeknownst to anyone was failing silently. It should’ve been an easy fix, but the more I dug into it, the more confused I became, and resorted to dumping variables to see if I could figure out what exactly was going wrong. The server was setup properly – I whipped up a quick test script, and it had no problems sending. Nothing was obviously wrong with the script itself… or so I thought.

Pick a standard, any standard

I’ll be honest, when I started to code I fell into the style of formatting that made most sense to me. As time went on and I’ve come to do more and more work with other people’s code and specifically Magento, I’m leaning more and more toward following the Zend Framework Coding Standard, for a number of very good reasons – mostly, that a great deal of thought that I don’t particularly fancy expending has gone into rationalizing the choices behind it, and it’s easier to point to an authoritative external standard than to codify and formalize my own. And really, who needs yet another standard?

Peripheral benefits

I’ll spare you the gory details of the Zend standard in favour of focusing on the relevant part:

When declaring indexed arrays with the Array function, a trailing space must be added after each comma delimiter to improve readability

Because I do this, it’s second nature to me to add trailing spaces after all comma-separated items. Because the originator of the script I was editing didn’t, it took me far longer than it should to notice that the variable $to passed to the mail() function contained two comma-separated email addresses without a trailing space, which mail() parsed internally as one malformed email address rather than two valid ones, thus:

38

mail($to, $subject, $headers);

becomes

38

mail("address1@example.com,address2@example.com", $subject, $headers);

Quite aside from making their code more readable, if more people followed the Zend standard it would eliminate little niggling problems like this.

One more reason

If you absolutely need another reason why it would be a good idea, try this one which you may have encountered in the wild when initiating a session after including classes:

Warning: session_start() [function.session-start]: Cannot send session cache limiter – headers already sent (output started at myfile.php:2)

which is usually caused by an included file ending thus:

76
77

?>
«

The culprit is marked with « above – the empty line that is treated as output by PHP. A word from our friends at Zend:

For files that contain only PHP code, the closing tag (“?>”) is never permitted. It is not required by PHP, and omitting it´ prevents the accidental injection of trailing white space into the response.