Maintaining Standards with PHP Code

In this article I want to talk a bit about standards. Not necessarily standards like you’d find with W3C, and not code formatting standards, but coming up with a consistent plan as you code and sticking with it. Staying close to the PHP manual and following developments with PHP so you don’t get bit in the butt later. I’ve been working with PHP for some years and have seen it go from version 2 through the current version and there have been many changes along the way.

In particular, I was thinking of two specific situations from my past which can bring down a site unexpectedly.

Shared Hosting

This is hard, but for most sites it is how they get online. You find a host, pay a monthly fee, and they take care of the rest. You just code and upload. This is fine, but the lack of control can be frustrating at times. Not only that, you never know who the person is playing SysAdmin on the other end of the wire.

In early 2000 I built a site for a company and it ran for nearly a year when I made a major international move. We were getting ready for another modification after I got settled. Amazingly enough, I was moving to one of the cities where this company had an office. When I got to my destination in early 2001 I had a horrible time getting an Internet connection. I think they were still in the dark ages.

Unfortunately, during my 6 weeks without an Internet connection (known now as my ‘blackout’ period), the shared host decided that PHP 4 was mature enough to upgrade. They sent out plenty of warnings that major changes were coming….but I didn’t get them without e-mail! One day they finally changed over and I had to go borrow a computer to find out why the site didn’t work. It turned out that PHP changed the format for notation for Apache directives. Very simple, very minute, probably not even necessary from my point of view. We got it fixed and we were back on the road and in a couple months we were working toward another redesign.

They say that waking up is hard to do

Have you experienced this? One day your site is down. You clear your schedule, visit the mailing lists and forums and spend your day (or two) finding out what went wrong. Waking up from this nightmare may leave you in a cold sweat. Keeping up with PHP or any software can be difficult. PHP isn’t bad, but you will notice some inconsistencies in the interface and over time things like that will be fixed, eventually breaking old code. What’s even worse is keeping up with shared hosts. Let’s take a look at scenario #2 from the hosting company’s point of view.

I worked for a typical Internet hosting company. We had many web sites on our machines, all with access to PHP. Although I can’t go into details, I would say their implementation of PHP was unusual. It was certainly not stable or secure.

It wasn’t unusual for the SysAdmin to come to work in the morning, read his e-mail, find out there was an upgrade for PHP released overnight and install it. That’s fine for your development server, but would you do that for the machines hosting many thousands of web sites?

Well, they did, they still do and so do many shared hosts. Not the good ones of course. The good ones I’ve been with test very thoroughly before making upgrades. Then they notify the clientele in advance of a change so they can monitor their site.

The problem is, you probably don’t know who is on the other end of your web site. What is their level of ability? Their work ethic? You probably don’t know.

The Standard

The ‘standard’ in this case simply reads “Keep up to date.” Read the PHP manual. Subscribe to the mailing lists. Get the RSS feed. Know what they are doing.

Scan through the manual frequently so you know what is going on. When you see that something is being phased out, like the HTTP_*_VARS, don’t keep developing with it!! Change immediately and start modifying your old code. That day will creep up when it’s gone and you won’t know when. Your site will go down even though you didn’t change anything. You’ll be on the phone with tech support blaming them. I’ve seen it. Worse yet, while you are on the phone with tech support, your former clients will be calling telling you their site is down.

If something is labelled as experimental in the PHP manual, be ready for changes. If you use it, don’t expect it to always work as it is now. You can even help the PHP team by submitting feedback if you use experimental features.

The Reward

The bonus reward for staying up to date is you are unlikely to be surprised. Not ever of course, things happen beyond our control. We can’t know everything, and we certainly can’t know the future. By knowing what’s coming as it is released by the PHP team you can at least get a head start, minimize the impact, and minimize the site outages, which could otherwise mean lost revenue.

If you get the opportunity to be your own SysAdmin, try it, at least on your development machines. PHP isn’t that hard to maintain, and you can see performance boosts by compiling only what you need. It is a big job to maintain a machine though, so if you aren’t up for it then make sure you know you’re hosting company well. Don’t just pick one. Peruse the online comments but don’t assume you are always getting a fair shake because hosting companies offer outrageous affiliate fees making people work hard to get referrals. Talk to friends, use tools at your disposal and make sure that the company you deal with only hires professionals in their field. If you made a bad mistake choosing a company don’t be afraid to move. You shouldn’t reward them for a bad job.

Taking these steps will make sure you are ready to go at each turn in the road. Neither rain, nor sleet, now snow can take down your site!

Now, are you ready for a slashdotting???