Tinsology

In my experience, one of the most common pitfalls for beginning programmers is not understanding the relationships between objects in their environment. This is especially the case in web development where there is in almost every case a blend between multiple client side and server side scripts. Failure to understand the the way browsers and servers communicate or the relationships between (X)HTML (or JavaScript or CSS etc) and PHP (insert alternative language here) will certainly lead to a poor or incorrect implementation. If you are an experienced programmer you probably won’t gain much from reading this, but if you are a beginner, hopefully I can provide some insight that will save you a lot of trouble.

The difference between client side and server side code is fairly simple. Client side code is processed by the client (the browser to be more specific) while server side code is processed by the server. HTML for example is parsed by the browser; the browser is responsible for taking that code and turning it into what you see in your window. For the purposes of parsing web pages, there is a short list of the types of code the browser can deal with. A typical web page, as far as the client is concerned, consists of some flavor of HTML often supplemented by CSS, or JavaScript (an exhaustive list of the types of client side code is beyond the scope of this entry).

Server side code, on the other hand, is never seen by the browser. The browser is not and should never need to be aware of server side scripts such as PHP. While a web page consists of client side code, this code is often either partially or entirely generated by a server side script. For example:

$title = 'Client Side Vs. Server Side Code';
if($title == '')
	echo '<title>Tinsology</title>';
else
	echo "<title>$title</title>";

When you navigate to a page containing the code above the browser will see “<title>Client Side Vs. Server Side Code</title>”. That’s it. The browser does not see any of the PHP code that generated the title. When you request a page containing PHP code from the server, the server first processes that page and then sends the resulting output to the client.

Server side code is browser independent (unless explicitly coded otherwise). This means that if the page you create looks different in Internet Explorer than it does in Opera it has nothing to do with your PHP code, but rather the resulting client side code.

The majority of PHP code I see, whether it be posted by a beginner on a forum, or built into a large application, seems to suggest that the current standard when accessing a database is to make use of whatever database specific commands PHP provides for your particular database (ie mysql_query, mssql_query, etc). Often times, calls to these function are coupled with various attempts to prevent sql injections (such as calls to mysql_real_escape_string). Altogether, however, to me it seems clumsy and insecure.

PHP5 provies a built in (partial) database abstraction layer that can not only simplify the process of querying your database not only protecting against sql injections, but optimize your queries and make your application more portable: PDO (PHP Data Objects). A typical database transaction with PHP might look something like this:

mysql_connect('localhost', 'user', 'password');
mysql_select_db('myDB');

$data = mysql_real_escape_string($_POST['data']);
$query = 'SELECT column FROM table WHERE data = \'' . $data . '\'';

$result = mysql_query($query);
while($row = mysql_fetch_array($result, FETCH_NUM))
{
     echo $row[0];
}

Now with PDO

$dsn = 'mysql:dbname=myDB;host=127.0.0.1';
try {
     $db = new PDO($dsn , 'user' , 'password');
}
catch(PDOException $e) {
     echo $e->getMessage();
}

$query = 'SELECT column FROM table WHERE data = ?';
$statement = $db->prepare($query);
$statement->bindParam(1 , $_POST['data']);
$statement->execute();

$rows = $statement->fetchAll(PDO::FETCH_NUM);

foreach($rows as $row)
{
     echo $row[0];
}

Outwardly, the second example might not seem like an improvement on the first. What is important, however, is what is going on underneath. From PHP.net:

Calling PDO::prepare() and PDOStatement::execute() for statements that will be issued multiple times with different parameter values optimizes the performance of your application by allowing the driver to negotiate client and/or server side caching of the query plan and meta information, and helps to prevent SQL injection attacks by eliminating the need to manually quote the parameters.

In addition to this, it simplifies the process of making your application compatible with another database. If you were to use database specific function throughout your application, you would need to change each to allow it to work with another database.

PDO, however, is not a complete database abstraction layer. While it does aid you in making your application portable, it will not emulate features of a particular database. If your queries are incompatible with your database PDO will not help you. Rarely, however, will it be the case that your queries are not compatible with most sql databases.

There are actually a few cases where where PDO will not be able to execute your queries (example: http://dev.mysql.com/doc/refman/5.0/en/c-api-prepared-statement-problems.html) but these cases are few and far between. Really it is rarely the case that you should NOT be using PDO.

Using PDO does not guarantee that user data is safe. You should always validate and sanitize user input, but PDO provides a decent extra line of defense.

http://us.php.net/pdo

Before I get into the topic of how to consolidate all of your error pages, let me first explain how to use .htaccess to create custom error pages. If you already know how to do this feel free to skip to the next section.

Creating Custom Error Pages

.htaccess, among other things, allows you to specify custom error pages for your site. Say a user requests a file that does not exist, typically that person will get an error page that looks somewhat like this:

—————————————————-
Not Found

The requested URL /somepage.html was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
—————————————————-

Not only is this message not helpful, but it is unappealing. Most likely you worked tirelessly making your site look presentable, so it would be a shame for a user attempting to access a page on your site to be given an ugly error message.

.htaccess allows you to specify the page you would like to use as an error page for a particular error (404, 301, 500 etc.). To do this, if it does not already exist, create a file called .htaccess in the root ( / ) directory of your site, or whatever directory you want to use custom error pages for. Note that these custom error pages will be used not only for the directory that the .htaccess file is located in, but all of the ones below it, unless you specifically override it.

Once you have created your .htaccess file, for each error you would like a custom page for add the following line:
ErrorDocument
So for example, if you would like to use a custom error page for a 404 (file not found) do the following:
ErrorDocument 404 /404.html
Where 404.html is your custom error page. Note that not every code is an error code. If you tried to set up an error page for code 200 you would end up creating an infinite loop.

Consolidating Your Error Pages

So you’ve setup your custom error pages. Mostly likely you haven’t taken the time to create a custom page for every error, and its most likely the case you don’t need to. I can honestly say I’ve never gone to a site and have it come up with a 414 Request URI Too Long error. Still, you might have taken the time to create several pages for the more common errors. You may even have a whole directory dedicated to error pages. Instead, you may want to consider using a single error page for all errors. If you’re experienced with .htaccess, you may already know how to accomplish this, if not I’ll show you.

In your .htaccess file you’ll still need to add a line for each error code you want to use a custom page for. Make sure to use the same scheme when naming all of your error pages, for example fourohfour.html, and 5hundred.php would be a bad choice. For this example I’ll use error.php (ie error404.php). These pages don’t actually need to (and should not) exist. Now we just need to create a RewriteRule for our error pages:
RewriteEngine On
ErrorDocument 404 /error404.php
ErrorDocument 500 /error500.php
RewriteRule ^error([0-9]+) error.php?code=$1 [NC]

You could eleminate the need for the rewrite rule by redirecting all of your errors to the same page like so:
RewriteEngine On
ErrorDocument 404 /error.php?code=404
ErrorDocument 500 /error.php?code=500


This, however, reveals the underlying system. This might not be a problem for most people, but some people prefer the look of urls that don’t contain parameters (?code=xxx). Also, if you decide you want to track what errors your users are getting (like what pages they are linking to that don’t exist) you can store this information in a database, in which case you wouldn’t want users to be aware of the underlying system.

Now whenever a user gets a 404 or a 500 error they will be redirected to error.php and the error code will be passed to that script. In error.php you can now set up custom messages for each error code. Here is a simple script as an example:

$code = $_GET['code']; //the error code
$code .= ''; //avoid integer indexing of the array

$errors = array( '300' => 'Multiple Choices',
                 '301' => 'Moved Permanently',
                 '302' => 'Moved Temporarily',
                 '303' => 'See Other',
                 '304' => 'Not Modified',
                 '305' => 'Use Proxy',
                 '400' => 'Bad Request',
                 '401' => 'Authorization Required',
                 '402' => 'Payment Required',
                 '403' => 'Forbidden',
                 '404' => 'Not Found',
                 '405' => 'Method Not Allowed',
                 '406' => 'Not Acceptable',
                 '407' => 'Proxy Authentication Required',
                 '408' => 'Request Timed Out',
                 '409' => 'Conflicting Request',
                 '410' => 'Gone',
                 '411' => 'Content Length Required',
                 '412' => 'Precondition Failed',
                 '413' => 'Request Entity Too Long',
                 '414' => 'Request URI Too Long',
                 '415' => 'Unsupported Media Type',
                 '500' => 'Internal Server Error',
                 '501' => 'Not Implemented',
                 '502' => 'Bad Gateway',
                 '503' => 'Service Unavailable',
                 '504' => 'Gateway Timeout',
                 '505' => 'HTTP Version Not Supported'
                      );

echo $code . ' ' . $errors[$code];

Clearly the error page generated by the script above would be no better than the default ones, but it is just an example. You could easily embed it into your site in order to maintain consistency for your users.

For some reason whenever I see someone post code that cycles through an array or does something repeatedly, that code takes the form of some kind of loop. I admit that I’m guilty of this as well, but when I think about why I’m cannot come up with a reason. I’m comfortable with the alternative (recursion) and in many cases I have to think harder about a problem to formulate the solution in a loop rather than recursion.

For those of you who have not been schooled in the arts of recursion, in simple terms it involves a function calling itself or recursing until it finds a solution. A basic recursion has two portions: the base case, and the recursive case. The base case establishes a condition for returning, without it the recursion would be infinite. The recursive case is the case where the function needs to be called an additional time. To demonstrate this lets say we have an array of ten integers numbered 1 through 10 in order. I’ll write two functions for finding a value within that array, one using a loop and the other using recursion. Assume our array is called myArray and is already initialized.

<?php
function find($value)
{
     foreach($myArray as $x)
     {
          if($x == $value)
               return true;
     }
return false;
}
?>

<?php
function find($value, $position = 0)
{
     //this is an error case
     if($position > 9)
          return false;
     //this is our base case
     if($myArray[$position] == $value)
          return true;
     //this is our recursive case
     return find($value, $position + 1);
}
?>

A few things to take note of: First, our recursive version of the find function has a type of case I didn’t mention, an error case. Not every recursion will have an error case, but it must exist in case the value we are searching for does not exist in the array. Otherwise we would end up indexing outside of our array. A second thing to note is that the recursive version of the find function has a second parameter to keep track of the position in the array. The foreach loop in the loop version does not appear to have a value to keep track of our position but it still exists. Foreach is a shortcut syntax, the position is still being tracked but the programmer does not have to be aware of it (which is good in some cases, and bad in others).

Typically in recursive functions like the one above you want to be able to call it without having to give additional inputs for the recursion. This is possible in the case above because in PHP there exists default values. Above I default the variable position to 0 so even if that parameter isn’t given in the call the search will start at 0. In other languages this may not be possible, but there are alternatives. In java for instance there are no default values so we must rely on another feature: polymorphism. In java functions are identified by their signature, not their name. I can define a method foo that takes as input an integer and another method foo that takes as input a string. I’ll use this feature to implement the same recursive function in java.

public class RecursionTest {

     private int[] myArray; 

     public static void main(String[] args)
     {
          //assume myArray is initialized
          find(5);
     }

     private boolean find(int value)
     {
          return find(value, 0);
     }

     private boolean find(int value, int position)
     {
          //error case
          if(position > 9)
               return false;
          //base case
          if(myArray[position] == value)
               return true;
          //recursive case
          return find(value, position + 1);
     }
}

You may be asking “What’s the point of all this recursion stuff when the loop accomplishes the same thing?”. I have two answers. The first is performance and the second is modeling your problem. When you use a loop to solve a problem, any variables you create are allocated in the heap. Alternatively with recursion, your function calls are all placed in the stack.

Typically stack allocations are cleaner than heap allocations. The stack basically keeps track of function calls and their inputs. When a function is called it and its inputs are placed on the stack. When that function returns it and its inputs are removed from the stack. In this case all of the memory allocation occurs in sequence, the system doesn’t have to worry about searching for free space on the stack and the programmer doesn’t have to worry about making sure that information is deleted from the stack (in a non-garbage collected language I mean).

In the heap on the other hand, the runtime system must find memory large enough for your data to fit in, which could lead to fragmentation. When the data is no longer needed the memory must be marked as free.

Does this mean that loops are inferior to recursion? No. There are cases were a loop would perform better than a recursion.

Now, on to my second point: modeling your problem. Once you get comfortable with recursion you will find that there are some things that seem much simpler to code without loops. Recursion also forces you to create a function or method for a certain task rather than just throwing a loop into your code, which can lead to massive blobs of unorganized code. If you have trouble with organizing your code try recursion for a while and I guarantee you’ll produce code that is easier to deal with.

For the time being I’m going to set out to solve more problems with recursion rather than loops, just for the sake of being an outcast.

P.S. the title is a blue oyster cult reference and I don’t know why.

Here I will show you how to intercept an incoming email through piping. I have also written a guide on How to Access Email in a Mailbox through IMAP

One of the most frequent questions I’m asked, or I see asked on forums is “how do I send out an email using PHP?” The answer to that is fairly simple and well documented. It more or less involves the use of a single function mail().

Something a bit more complicated and, I think, more interesting is how you can intercept an incoming email with a pretty small chunk of PHP code. The answer to how to do this, though not so difficult to find out, is a far less trivial thing.

The Scenario (optional if you don’t feel like reading)

Say we are building a contact form for a web application. This pretty basic contact form takes whatever input  the user gives, to keep things simple we’ll just say its the users email address and a message. This message is then sent to a database where it can be read from an administrative control panel of some sort. This is pretty simple and for the most part effective. Personally I have a problem with this type of setup. If users are not logged in when using the form there is no guaranteed way to respond. The email address they provide may or may not be valid, or they could just be spamming some nonsense because they are anonymous in the Internet and no one can stop them. A simple solution: Force users to log in. But Wait! what if users are having trouble creating an account or logging in and this is the reason why thy need to contact you? OK, to solve this problem we’ll just set up an email address that users can contact us with in addition to the form. This solves the problem of reliable contact information and minimizes the spam problem (the email address can still be spammed but a lot of it can be filtered). So once this is all setup will have a contact form that sends info that can be read by all of our admins in our admin panel… and the occasional email to some email account that all of our admins will need the password to to check regularly.

This may be acceptable to some… but not to us! We know of a better way to consolidate all of our communications with our users while at the same time having our desired setup. OK maybe you don’t or else why would you read this. Here’s how we do it:

The Code(this is where you should start reading if you like to get to the point)

Some of you may be thinking that PHP is so magical that there is a simple function that is going to go out and fetch the email we want from where ever it is on the server. Well you’re wrong (not about the magical part). What we need to do is setup a script that can capture the email when the server recieves it. This is actually pretty simple, all we need to do is extract the email data from standard input (php://stdin).

$file = fopen('php://stdin', 'r');

Once we establish a file pointer to our input stream the rest is the same as reading in any other file. Here’s the complete code:

< ?php
$data = '';
$file = fopen('php://stdin', 'r');
while(!feof($file))
{
     $data .= fgets($file, 4096);
}
fclose($file);
?>

$data now stores the raw content of the email, headers and body. At this point we just need to decide what to do with the email, I’ll leave that for you to decide. So other than that our script is complete correct? False. We have not yet addressed one crucial step. The server needs to be told how to execute this script. You may be wondering, why would we have to tell the server what to do with a .php file… its .php! The main difference between a user requesting a .php file via the internet and what we are doing here is what is handling the request. When a user goes to index.php on your website, apache knows what to do with the file because that is how it has been configured. The server on the otherhand will not necissarily assume that the file should be parsed by php. So how do we tell it to you say? Hashbang. A hashbang tells the server how to handle a file, in our case we will use the following hashbang #!/usr/bin/php -q. Note that this may or may not work for you depending on the path to php on your server. The one I’m using is the default, so if you’re not sure use that one, otherwise contact your hosting provider. Ok so here is our completed, hashbanged code:

#!/usr/bin/php -q
< ?php
$data = '';
$file = fopen('php://stdin', 'r');
while(!feof($file))
{
     $data .= fgets($file, 4096);
}
fclose($file);
?>

Note that the hashbang is outside of the php tags. This is absolutely necissary for the script to work. Save this code and take note of the path to it.

The Setup

Now that we’ve written our script we need to tell the server what to do with incoming email. This setup is going to vary depending on your server configuration, I’ll tell you how to do it on a linux server with sendmail and cpanel but for anything else you’re on your own (or you can post back explaining how and I’ll add it to the tutorial). What we need to do is setup a forwarder. If you have cPanel this is fairly straightforward. In your mail section find the forwarders option and click it. From there click add new forwarder. At this point you’ll have a few different options: you can forward to another address, discard and send an error message, do nothing, or pipe to a program. We want to pipe to a program. Just type in the address that you want piped, select the pipe option and then set the path to the path to the file you just saved. If you have access to your home directory, you can forego using cpanel and use a .forward file. All you have to do is create a file called .forward and add the following line:

email@address.com,”|/path/to/script.php”

Of course replace the email address with the address you want forwarded and /path/to/script.php with the actual path to the script. You can also omit the email address portion to have all mail forwarded to the script. I believe this process is the same using Exim or Qmail.

Well that’s it for the most part. Feel free to post back with any problems you have or additions you’d like to make. I’ll write about taking a raw email and converting it to a more friendly format, in this case an associative array, in the near future.

Since launching this blog a few days ago I have yet to post and code examples or tutorials. In preperation for this, and having decided that plain text code examples just wouldn’t cut it, I went searching for a plugin to format and highlight my code. Not too long afterward I came across the SyntaxHighlighter plugin. After a simple installation I was able to do things like this:

<?php
//this is php code
echo 'hello world';
?>

How is the feat accomplished you say?The plugin allows you to post your code by surrounding it with the tags [/sourcecode], where lang is equal to one of these supported languages:
<ul>
<li>C++ — <code>cpp</code>, <code>c</code>, <code>c++</code></li>
<li>C# — <code>c#</code>, <code>c-sharp</code>, <code>csharp</code></li>
<li>CSS — <code>css</code></li>
<li>Delphi — <code>delphi</code>, <code>pascal</code></li>
<li>Java — <code>java</code></li>
<li>JavaScript — <code>js</code>, <code>jscript</code>, <code>javascript</code></li>
<li>PHP — <code>php</code></li>
<li>Python — <code>py</code>, <code>python</code></li>
<li>Ruby — <code>rb</code>, <code>ruby</code>, <code>rails</code>, <code>ror</code></li>
<li>SQL — <code>sql</code></li>
<li>VB — <code>vb</code>, <code>vb.net</code></li>
<li>XML/HTML — <code>xml</code>, <code>html</code>, <code>xhtml</code>, <code>xslt</code></li>
</ul>
The words following the — are valid arguments for language corresponding to that particular language, meaning that for python code you can set language equal to ‘py’ or ‘python’. Pretty cool right?

But Wait!

There was one catch in my case when it came to getting this plugin up and running. I had previously installed a plugin called <a href="http://bluesome.net/post/2005/08/18/50/" target="_blank">Exec-PHP</a> that allowed me to insert php code into posts that would be executed rather than displayed (this only works for me and it only works in posts so don’t get any ideas). So now all of my code examples would simply be executed, resulting in whatever the output of that example would be (worse potentially, the execution of that code everytime someone loads that page).

I came up with two possible solutions to this problem. The first being just to not use php tags in any of the code I post (NEVER!!!). The second being that I throw away about an hour of my life, dive into the exec-php plugin code, and set things right. Clearly I chose the second of these options.

So far I’ve only found 1 bug with this modification. I can’t display the code I used to impliment it. Any php code containing the strings [sourcecode language='p h p'] or will most likely break the plugin. Here is the link to download the plugin with the modification, feel free to comment back with error reports or improvements:

Download