Much of PHP’s success can be attributed to it being free and open, able to run on nearly every operating system, and being easy to use and learn.   Yet the same things that have made it so successful in the open source community have historically hindered its commercial success.   But why?

Quite simply PHP is a scripted language.   Unlike C programs which need pre-compilation to run, PHP is compiled and executed on the fly by the PHP engine.  Perl, JavaScript, and Shell script all execute in a similar manner.  This makes PHP very flexible and friendly to open source and hobbyist developers, but it essentially requires you to “give away” your source code in order to distribute your program.

Of course commercial developers attempting to make a profit on their work won’t  want to give away their code, not if they expect to make money! But the PHP market was huge and lucrative, so unsurprisingly a company stepped in to offer a solution.  That solution is IonCube, and here’s how it works.

First, the commercial PHP developer will write their application.   When it’s finished, the developer will use the IonCube program to encode the raw, human-readable PHP source code in a proprietary binary format.  This protects the underlying source code from prying eyes by turning it into a jumble of unreadable goobleygook.

Next,  the application is purchased by an end user.  After the purchase, the application developer provides the customer with a special key which is used to “unlock” the encoded source.

Finally, the customer installs the IonCube Loader on their web server, which acts as a on-the-fly decoder for the coded application.    At no time is the user ever able to view the PHP source code:  all the decoding happens inside the web server via the IonCube loader.   This keeps the application code a secret for the developer, as well as allowing fine control over the licensing of their application via the unlock key.

Though IonCube had a rocky start at its debut in 2002 (thanks somewhat to vocal opposition by strong open source proponents), it has slowly become the de-facto standard for distributing non-free PHP applications.   Though not all web hosts support it, The Linux Fix offers the IonCube Loader with every web hosting plan we provide.  We hope that it gives you the freedom of using whatever PHP application you choose, without much fuss!

Nevertheless, when it comes down to scripting and programming, I try to take my time.   When I’m in the process of writing code, especially when that particular bit of code may involve external processing (say reading from a URI), I like to think out all the possible ways it could go wrong.   Not only is this good programming practice for debugging purposes, but writing it in such a way allows you to present very relevant and accurate error messages to your users.

Now, let me explain why this is important.

Earlier this week I was offering help to my housing overlords with a computer problem they happen to use for their point-of-sale system.   Whenever they tried to print a receipt on their printer, an error message would pop up stating “Insufficient disk space to print”.

The computer had 300GB of free disk space.

To make a long story short, the program lied.   The problem was that “C:\windows\temp” had the read-only attribute turned on.   The disk wasn’t full at all, but since the printer driver program couldn’t write to that path, it assumed the drive was full.  We all know what “assume”-ing makes us…

One silly coding choice by a programmer burned several hours of my life away.   If the programmer had simply chosen to test a few conditions before attempting to write the file, namely:

• Does the directory exist?
• What are the modes on the directory?
• Is there a file named the same as I’m about to write?
• … and so on