On the MyBuilder.com Tech blog Edd Mann has a post sharing some advice about dealing with newlines and Unicode characters in both Javascript and PHP functionality.

We were recently sent a tweet in-regard to a text-area client/server-side length validation not correlating. After some detective work we were able to find two issues that could have caused this to occur. In this post I wish to discuss our findings, and how we resolved each issue.

The first issue they found was newline characters that didn't seem to be there by normal ACSII standards in text-area inputs. They were showing as a single character on the client where it was two on the server, later discovered to be a defined standard in the HTML 5 spec. The second Unicode-related issue was with characters outside of the basic multilingual plane and how Javascript measures its length. The post then explains their solutions to each of the two issues, doing some string replacement and using a different function to get the length of a string.

Brian Moon points out a (sometimes annoying) habit of PHP when it comes to newlines - it drops them after the closing tag.

Have you ever noticed that PHP eats the newlines after a closing PHP tag? Not sure what I mean? There is lots on Google about it. [...] So, why does PHP do this? Well, you have to go back 11 years. PHP 3 was emerging. I was just starting to use it for Phorum at the time. There were two reasons.

The first reason was the it, at least in the minds of the developers of the language, "removed all traces of PHP" from the script without any training newlines to show for it. The second case was a bit more valid - because lots of editors at the time required newlines at the end of every line of code. This caused loads of trouble tracking down things like the infamous "Headers already sent" issues (pre-output buffering).

CodeIgniter fans might want to take note of this tip from Tiffany Brown concerning "disallowed key character" error messages.

After 6 hours of massive anxiety, stress, near tears, one pound on my desk, and some hair pulling, I tracked down the source of a nagging Disallowed Key Character error that I received while using CodeIgniter: an extra line break.

She eventually figured out that the newline and carriage return characters are not allowed as a part of the framework. Unfortunately, it was a random newline after a controller's code that did it for her.

Anyone noticing some "quirkiness" happening when they use the eZ Mail component in their scripts and bounce the messages off of a Qmail server, might want to check out this helpful hint from Tobias Schlitt on how he solved it.

While working with the eZ Mail component, for sending some emails comfortably, I noticed some issue with my Qmail installation. With some email accounts that received the emails, the headers were broken and had double line break characters, so the complete email was broken. That (weirdly) happened only with some servers (e.g. Gmail), while my own server handeled the emails gracefully.

He discovers that the issue lies on Qmail's side, where the sendmail wrapper for it looks for a "\n" instead of a "\r\n" line PHP sends at the end of a line. Thankfully, it's an easy fix with the eZ Mail component: [php] [/php] Check out this page for more information on this functionality.

Anyone noticing some "quirkiness" happening when they use the eZ Mail component in their scripts and bounce the messages off of a Qmail server, might want to check out this helpful hint from Tobias Schlitt on how he solved it.

While working with the eZ Mail component, for sending some emails comfortably, I noticed some issue with my Qmail installation. With some email accounts that received the emails, the headers were broken and had double line break characters, so the complete email was broken. That (weirdly) happened only with some servers (e.g. Gmail), while my own server handeled the emails gracefully.

He discovers that the issue lies on Qmail's side, where the sendmail wrapper for it looks for a "\n" instead of a "\r\n" line PHP sends at the end of a line. Thankfully, it's an easy fix with the eZ Mail component: [php] [/php] Check out this page for more information on this functionality.

In her latest post, Nola shares a testing class that she has created based on the Test::Simple method.

I'm writing a PHP class for a user, and then think.. oh gee, how do I know if this works?? oh I'll write a Test::Simple for PHP. Yes, I know there exists one already that uses the power of Perl to test PHP files, but I didn't have time to figure out how to set that up and probably won't be able to use perl anyways on the production system. I can't stand to have global variables, so I made a class. Uber simple. There's probably better ways to do it (I can imagine something much more elegant in PHP 5). But, what do you expect on a whim and 40 minutes...

her code runs a simple check to see if the end of the line being checked (passed in). It's a pretty basic testing framework, but has potential if it was made to accept "test plugins". Of course, there's other options out there too when it comes to testing in PHP...

In her latest post, Nola shares a testing class that she has created based on the Test::Simple method.

I'm writing a PHP class for a user, and then think.. oh gee, how do I know if this works?? oh I'll write a Test::Simple for PHP. Yes, I know there exists one already that uses the power of Perl to test PHP files, but I didn't have time to figure out how to set that up and probably won't be able to use perl anyways on the production system. I can't stand to have global variables, so I made a class. Uber simple. There's probably better ways to do it (I can imagine something much more elegant in PHP 5). But, what do you expect on a whim and 40 minutes...

her code runs a simple check to see if the end of the line being checked (passed in). It's a pretty basic testing framework, but has potential if it was made to accept "test plugins". Of course, there's other options out there too when it comes to testing in PHP...