A week ago, I wrote about the blip in supplies of The Essential Guide to Dreamweaver CS3 with CSS, Ajax, and PHP. My publisher (friends of ED) got onto the case immediately, and told me that 388 copies of the book were on the way to Amazon.com. You might think that would be enough to keep Amazon going for a while. Indeed it did—about one day. Now, although I’d love to sell that number of books in a day—and every day—for a sustained period, books about Dreamweaver and PHP don’t fall into the same category as Harry Potter. The reason the mountain of books disappeared so quickly is because of back orders waiting to be fulfilled.
I’ve just checked Amazon again—and on Monday morning (London time, 28 January), the book was back in stock, but there was only one copy left. Wow, this book is hot! Grab it while you can. Nothing pleases me more than to see my book fly off the shelves, but it’s equally frustrating to see readers unable to get hold of a copy because demand was higher than anticipated. I see that Amazon is now quoting 4 February as the date supplies should be back to normal. Let’s hope it’s no later than that, and preferably sooner.
January 28th, 2008
For the past couple of weeks, the availability of The Essential Guide to Dreamweaver CS3 with CSS, Ajax, and PHP has been listed on Amazon.com as “usually ships within 1 to 3 weeks”. Very often, particularly with a recently published book, that means demand has been higher than expected, and there’s a temporary blip in supply. However, today the availability suddenly changed to “usually ships within 3 to 6 weeks”, so I decided to get in touch with my publisher to find out what’s going on.
Apparently, demand for the book has risen in recent weeks, so that’s good news for me. Thank you to everyone who has bought a copy. It has also been reprinted, and I’m told the new copies should already be in the distribution chain. Apologies if you have ordered a copy, and still haven’t got it. We’re trying to find out if we can speed up deliveries. [Update:] It looks as though things are moving. Amazon seems to have got hold of a few copies, and it’s quoting January 30 as the day when supplies should be back to normal. If you can’t wait, The Essential Guide to Dreamweaver CS3 is available for immediate download as an eBook. You can buy it through visiting the book’s page on the friends of ED website. By the way, this distribution problem does not affect Amazon in the UK, where the book is reported to be in stock.
January 22nd, 2008
One of the features I stressed in PHP Solutions was the need to write secure code. On page 378, I said it was essential to display error messages in a development environment so that you can debug your code. However, raw error messages look unprofessional in a live website. Well, guess who forgot to take his own advice? Yes, it was me—guilty as charged. Do as I say, not do as I do.
I found out as a result of a couple of messages posted under a pseudonym to my blog. Since I have been involved in an acrimonious discussion about security in the past couple of days, I suspect that someone involved in that discussion, either as a participant or an observer, wanted to embarrass me. The way in one of the messages was phrased appeared to be a direct reference to something I had written in the other discussion. Sure, I’ve ended up with (a little) egg on my face, but the error message didn’t reveal anything about the structure of the site; and I have now implemented the advice on page 378.
Am I embarrassed about the event? Yes, I suppose I am, but we all make mistakes from time to time. If I have made a mistake, I’m usually the first to admit it, particularly if the person pointing it out does so in a spirit of mutual help. I decided not to publish the messages—not to save my red face, but because the poster didn’t have the decency to use his (or her) own name, and because it was done in an offensive way. The poster accused me of wasting my time in a forum that I haven’t visited probably for about two years, although it’s a forum that provides a lot of free and usually very sound advice about website design.
Security on the web, as well as in everyday life, is important to all of us. Pointing out another person’s mistakes can be a valuable service. It’s not a question of scoring points, but of helping one another. Throughout the other discussion, I used my own name, as did most other participants. We had a genuine disagreement, but everyone was open about it. Sadly, the person who found a minor security error in one of my pages decided to be abusive and hide behind a false name. So, whoever you are, thank you for bringing it to my attention, but your actual posts have been sent to cyberoblivion.
January 22nd, 2008
PHP 4.4.8 was released today (3 January 2008)—three days after PHP 4 officially reached the end of its support life. For some strange reason, PHP releases are always made on a Thursday, so the release was delayed until today to avoid slipping it out on 27 December while everyone was still comatose during the Christmas and New Year holiday season. This version incorporates a handful of fixes for security issues and bugs, but adds no new features. Unless a major security issue emerges between now and the Beijing Olympics (8 August 2008), this will be the last ever version of PHP 4.
My reaction? About time, too. PHP 4 should have been abandoned a long time ago. The problem is that hosting companies moved to PHP 5 at a glacial pace. Even now, three and a half years after the release of PHP 5.0, only one in four PHP websites runs on PHP 5. In the early days, administrators blamed stability problems and memory leaks on shared hosting. Since I use a dedicated server, I have never come across such problems myself, but PHP 5.1 and 5.2 have added stability and performance improvements that should overcome any objections.
Perhaps a major contributory factor to the slow adoption of PHP 5 has been the memory of what happened when register_globals was turned off by default in 2002. Suddenly, scripts that had worked the day before ground to a halt. Turning off register_globals was done to plug a gaping security hole in PHP; but so many people relied on variables being created automatically from form fields and URL query strings that exasperated system administrators turned register_globals back on in spite of the security risk. This was, of course, the wrong solution. Instead of permitting insecure scripts, hosting companies should have shown their clients how to write secure scripts by using the $_POST and $_GET arrays.
There’s now a fear that switching to PHP 5 will suddenly break all scripts written to PHP 4 standards. The answer is that—in the vast majority of cases—it won’t. The only area of major incompatibility between PHP 4 and PHP 5 lies in the object-oriented model. Even so, there should be no problems continuing to run old OOP scripts as long as you don’t try to mix them with ones written using the new PHP syntax. I have a large website written using PHP 4 classes, which I moved onto my PHP 5 server back in August 2004. It ran perfectly with no changes, and is still running happily.
If you’ve no idea what an OOP script looks like, you probably have nothing to worry about anyway. Object-oriented code tends to be used only by advanced developers. Those most at risk are cut and paste merchants who use code in their web pages without knowing how it works. As long as you get code from a good source, you don’t need to understand it in minute detail, but you do need to know what it’s for, and how it fits in with the rest of the page. If you’re worried that you might have PHP OOP code in your pages without realizing it, look for the -> operator. A typical line of OOP code looks like this:
$result = $db->query($sql);
The key to successful migration to PHP 5 is well-written code. If you have been using best practices, such as writing scripts to work with register_globals off, you should have no worries upgrading to PHP 5. Other things to check:
- Use
$_SESSION instead of session_register().
- Use
$_POST, $_GET, and the other superglobals instead of the deprecated long versions, such as $HTTP_POST_VARS. Many PHP 5 servers don’t support the long versions; and even if they do, you should never mix them with the new superglobal arrays. When created alongside each other, they are treated separately, and changing the value of one has no effect on the other.
- Make sure that you pass arrays as arguments to functions that expect an array. PHP 4 won’t complain if you pass a string instead. PHP 5 isn’t so obliging.
Migrating to PHP 5 is not only nothing to worry about, it offers a lot of advantages, the most important of which is that PHP 5 remains under development. Security improvements are constantly being made. There are also lots of new features that make coding simpler and more pleasurable. For example, writing to an external file is simply a question of using file_put_contents(); no need to mess around with file handles unless you need to read the file at the same time. PHP 5.2 also introduces a very useful set of filters for sanitizing user input. And working with XML is a piece of cake with the aptly named SimpleXML.
If your hosting company hasn’t yet announced plans to migrate to PHP 5, start pressing for it to do so now. Also, get an assurance that regular updates will be made to the version on your server. It’s no good your hosting company moving to, say, PHP 5.1.6, because the PHP 5.1 series is already dead. As the PHP “museum” page warns, older releases are listed for archaeological purposes only, and they are no longer supported.
While checking on your hosting company’s offering, it’s also worth checking which version of MySQL is being offered. Few people seem to realize that all support for MySQL 3.23 ended more than a year ago. Active support for MySQL 4.0 and 4.1 also ended in 2006 (extended support continues until the end of 2008 for 4.0, and until the end of 2009 for 4.1). With MySQL 5.1 due out any time soon, you should be insisting on a minimum of MySQL 5.0. At a push, 4.1 will do.
This isn’t advocating the latest versions just for the sake of being up-to-date or trendy. Security on the web is extremely important, and it’s unrealistic to expect the developers of PHP and MySQL to keep patching up older versions. The PHP development team is working hard on PHP 6, but progress has been delayed by the constant distraction of maintaining two major versions at the same time as creating the next one. It also presents a problem for authors like myself. When I wrote PHP Solutions, I wanted to use PHP 5 code throughout, but I realized that the majority of readers would still be stuck with PHP 4. As a result, I had to write two versions of much of the code. With PHP 4 now officially no longer supported, there’s no reason to write books and tutorials that are hamstrung by the need to provide workarounds. So, if your hosting company doesn’t upgrade, you’ll find support for your system more and more difficult to come by.
January 3rd, 2008