I have been working a lot with PHP lately. Today I had an unmerciful time with cookies. I was almost done with a script when cookie trouble led me to go back and tear the whole script apart. It turns out that my problem lie in an imperfect understanding of how cookies work. First, you should know that they can not be created after any output. This is well known, however there is more to it. I made up the following test script to illustrate the possibilities.

//Just set a cookie.
setcookie(‘test1cook’, ‘testval1′, time()+3600);

//Set a cookie and set it again.
setcookie(‘test2cook’, ‘testval2′, time()+3600);
//setcookie(‘test2cook’, ‘testval2redux’ time()+3600); will throw a parse error.

//Set a cookie unset it, and reset.
setcookie(‘test3cook’, ‘testval3′, time()+3600);
setcookie(‘test3cook’, ‘testval3′, time()-3600);
setcookie(‘test3cook’, ‘testval3reset’, time()+3600);

//Set a cookie and use the unset function.
setcookie(‘test4cook’, ‘testval4′, time()+3600);
unset($_COOKIE['test4cook']);

//Set a cookie and attempt to change its contents.
setcookie(‘test5cook’, ‘testval5′, time()+3600);
$_COOKIE['test5cook'] = ‘tesval5_overwritten’;

//Print before setting a cookie.
print ” “;
setcookie(‘test6cook’, ‘testval6′, time()+3600);

Run this script and then run the following directly after:

print ‘<br />test1cook = ‘;
print $_COOKIE['test1cook'];
print ‘<br />test2cook = ‘;
print $_COOKIE['test2cook'];
print ‘<br />test3cook = ‘;
print $_COOKIE['test3cook'];
print ‘<br />test4cook = ‘;
print $_COOKIE['test4cook'];
print ‘<br />test5cook = ‘;
print $_COOKIE['test5cook'];
print ‘<br />test6cook = ‘;
print $_COOKIE['test6cook'];

The results will look something like this on your browser:

test1cook = testval1
test2cook = testval2
test3cook = testval3reset
test4cook = testval4
test5cook = testval5
test6cook =

As you can see in number 2, directly reseting the cookie does not change it in fact it throws an error. It must first be unset as in number three. Simply using the “unset()” function does nothing as illustrated in number 4. Rewriting the cookie variable also does nothing. And, of course, outputing anything before a cookie is made will result in no cookie.

Now the results here deserve another looksee. Because if a subsequent script runs some of these lines there will be some changed results:

//Set a cookie and set it again.
setcookie(‘test2cook’, ‘testval2′, time()+3600);

//Set a cookie and use the unset function.
unset($_COOKIE['test4cook']);

//Set a cookie and attempt to change its contents.
$_COOKIE['test5cook'] = ‘tesval5_overwritten’;

With the same print statements as above run concurrently, note these results:

test1cook = testval1
test2cook = testval2
test3cook = testval3reset
test4cook =
test5cook = tesval5_overwritten
test6cook =

Notice that now there is no error on number 2.  On number 4 the cookie is shown as unset, and number five is overwritten where it was not in the first go round, because the cookie is not available in the same run in which it is created.

Interestingly enough, another running of the print statement nets the following.

test1cook = testval1
test2cook = testval2
test3cook = testval3reset
test4cook = testval4
test5cook = testval5
test6cook =

This shows that the changes to the cookie array in 4 and 5 were only within the script. They did not effect the information stored on the browser, which can only be changed by first destroying the cookie and then recreating it.

Yes, I knew you wanted to read about another development on the PHP mail function front. So here it is: you can use the “from” header on some servers and not on others. Some mailservers will reject an email with a “from” header (with out of state plates) out of hand, on the possibility it is spam. Others will allow you to send a message with it.

Why do I need to include the “From” header in a mail message? As previously explained, I am developing a universal contact module that can be included on any website. Not all that complicated…you would think. But as my dear old granddad used to say between spits of tobacco, “It’s always sumpin’.”

I wanted to make it easy to respond to messages sent by the contact form, so I included the “From” and “reply to” headers. It worked fine on one server, and I thought, great, now I will just start installing this module on all my sites. The first one liked the “From” module, so did the second, but when I hit a different server, it did not like it.

As it turns out, you don’t really need the ”From” header in the email to allow a one click response form to show up on your email program. So, I have simply removed it. The “reply to” still works fine.

Lately I have come to the notion that I can modularize my PHP and inject it like a serum into some of my older websites to update and upgrade their performance and useability. In pursuit of this goal, I rewrote a mail utility to make it universal, a kind of plugin. Simply FTP some files to the server, install a link and wham.

I put the utility on Drywall How To Manual. It works great…now. There was only one tiny problem. When I rewrote the utility, I changed the $message variable to look something like this:

$message = “Name: $cname \n Email: $cemail \n Ref Page: $ref_url \n Message: $cmessage \n”;

It feeds the following:

$mail_success = mail($email, $subject, $message);

Do you see anything wrong with it? Neither did I. It took me an hour of testing and breaking down those lines of code to find out what the problem was.  I will give you a hint if you haven’t already got an inkling from the title of this post. The problem is in the new line character.

Yes, you can have a new line character in the variable of the mail function in PHP. Only thing is you cannot have it at the end JUST BEFORE the quote mark.

The funny thing is that this does not throw an error. In fact, the email is simply not sent, but the function returns “true”, indicating the message was sent.

To test to make sure that the “backslant n” was not a general no no in PHP I tried a little test which looked like this:

//test in variable:
$test = “test \n”;
$test2 = “test2 \n”;
print “test = $test”;
print “test2 = $test2″;
print “test3″;
print “\n”;

//test in function:
$length = strlen($test);
print “length = $length”;

The results make me believe this is a little bug in the mail() function:

test = test
test2 = test2
test3
length = 6

Interesting development. No matter how long you are in the game, you always are learning something.

It is easy to fall prey to simple errors when writing PHP. Usually when a script spits out an error it is because there is no semicolon or a quote mark is in the wrong spot. Even so, PHP is fairly forgiving and also explicit in warning of mistakes, but sometimes simple errors can also be deceptively hard to find.

The isset function is frequently used in if statements to test for a condition. Yet it can also fool the programmer when dealing with form input. For example input from a form looks something like this:

<input type=”text” name=”book” value=”<?php print $_SESSION[book]; >” />

However, the $_SESSION[book] variable happens to be empty, because say a book has not yet been chosen. What is more when the user submits the form, he does not fill in the “book” data.

Now if the script receiving this data looks like this:

if(isset($_SESSION[book]))
{
$x = “Eat chopped liver.”
}

Then someone is going to be eating chopped liver because even though there is nothing in the variable $_SESSION[book], the variable is still SET.

In all of my days writing PHP I have never before run accross the Levenshtein Distance. I don’t suppose that this is strictly a PHP idea. Nevertheless, I was intrigued to find out that there is a specific function in the library that will calculate the Levenshtein Distance between two strings. It looks like this:

levenshtein(string1,string2,insert,replace,delete)

The required input is the two strings, and then optionally you can give weight to certain distance perameters. So just what is this function measuring? Quite simply how many changes would have to be made between two strings in order to make them equal.

I have been pondering as to why we should ever want to quantify such a thing. But a little cogitation would show that this distance would work very well for spell-checkers in trying to determine what a person meant to write when using a particular spelling. For example, if you wrote “recieve” the Levenshtein Distance to “receive” would be in the neighborhood of two with only two replaces. A person writing “recieve” would probably not be trying to write “rectify”, which would be a distance of three. But that would be a whole lot more likely that “transmogrify”, which would be a much greater distance.

While I don’t think this distance says much about entomology, I can see how it could be a useful tool in scripts dealing in word processing.

A program dealing with the Levenshtein Distance between certain names might also prove entertaining. I will ponder that one.

Using php there are two ways to get info from a database. The first is a standard query in the form of “mysql_query()”. When selecting info in this manner it is placed into a buffer on the server. To work with it, it must be fetched from the buffer using “mysql_fetch_array()” or some such function.

The other way to get info is via “mysql_unbuffered_query()”. Info downloaded in this format is worked with line by line as it comes down the pike. This eliminates the need to call the info from a buffer.

So, why is it that the standard query is more often used when an unbuffered query eliminates a step in the process. Very simply, by buffering you know before you begin how many rows are the result of the query. There may also be performance aspects involved especially with regard to the SQL server.

So, then, why use a unbuffered query? Besides eliminating a step, it can also speed up the processing server’s processing time for very large queries.