Posts filed under 'PHP'
The Dreamweaver forums have been ablaze with reports of simple PHP and ASP code causing Dreamweaver CS3 to crash. I have tested many of the sample code snippets, and can confirm that CS3 is crashing on Windows XP and Vista, but not on Mac OS X. It also affects the PHP code in my books.
The cause of the crashes appears to be the clock change following the end of summer time in Europe. Since the United States is still on daylight saving time until 4 November, American users have reported that they are crash-free—for the time being, at least. It’s not clear whether it’s an Adobe bug or one caused by the Windows operating system, but there’s little point getting into the blame game. What’s needed is a fix—and quickly.
The temporary solution appears to be to change your system clock back to any time before 2 am on 28 October. Alternatively, use Dreamweaver 8.0.2, which isn’t affected. Neither solution is ideal, but Adobe has been alerted to the problem, and hopefully a permanent solution can be found soon.
[Update]: The solution is to delete WinFileCache-********.dat, which was apparently corrupted by the clock change.
October 29th, 2007
I have just upgraded my Mac PowerBook G4 laptop to Mac OS X 10.5 (Leopard). The installation went fine, but there are a couple of issues you need to be aware of if you use your Mac to develop PHP, as they could affect your decision to upgrade—at least for the time being.
Leopard installs Apache 2.2.6 instead of the Apache 1.3 series that was used in all previous versions of Mac OS X. As a result, when you restart your computer for the first time, web sharing will be disabled. Turning it on is exactly the same as described in all my books. However, if you use the Mac OS X PHP package from Marc Liyanage, it won’t work.
Although Marc offers an Apache 2 version on his site, that won’t work on Leopard, either. According to a post from Marc on 26 October in this thread in his forum, he needs to figure out how to integrate it all, but is currently very busy at work. The same thread discusses using the version of PHP preinstalled in Leopard. Apple has inexplicably decided to install PHP 4, even though it comes to the end of its support life in just over two months’ time. [Updated 28 Oct 2007] As Dan Brown points out below, PHP 5 is, indeed, preinstalled in Leopard. The confusion is caused by Apache being in a new location. I suspect that the old versions of Apache and PHP were left on my machines because they were upgraded from OS X 10.4, and that a completely fresh install of Leopard would have only Apache 2.2.6 and PHP 5.2.4.
Following Dan’s instructions below will get PHP 5 up and running in Leopard. However, the default installation of PHP doesn’t read php.ini. You need to create that yourself. I’ll try to get some instructions up on my site in the next day or two.
I have no idea how long it will take Marc Liyanage to work his usual wonders with his PHP package, but if you want to use Mac OS X to develop PHP sites, either delay upgrading to Leopard follow Dan’s instructions below or use the all-in-one package from MAMP. I have never used MAMP, but it has a good reputation. Perhaps it’s time for me to give it a try.
[Added 28 Oct 2007] MAMP seems to work without problem on Leopard, and is definitely worth considering if the idea of working in Terminal sends cold shivers up your spine. After downloading it, simply copy the MAMP folder to Applications, and then double-click the MAMP icon inside the MAMP folder. I suggest that you select Preferences > Ports, and click “Set to default Apache and MySQL ports”. If you do this, it’s important not to switch on Web Sharing in System Preferences. You must also close down any existing MySQL server. It’s also important to realize that the Apache and MySQL versions installed by MAMP are completely independent. The site root and MySQL data store are in different locations. Any databases created in a previous installation of MySQL must be exported, and reimported into the MAMP version of MySQL. The need to move things around detracts from the attraction of MAMP if you already have several databases stored in an existing installation of MySQL.
October 27th, 2007
It’s been a long time since I’ve posted anything in this blog. I’m definitely not one of the world’s most prolific bloggers—not by any stretch of the imagination.
One reason I’ve been so quiet is because of the pressure of writing The Essential Guide to Dreamweaver CS3 with CSS, Ajax, and PHP. It’s the longest book I’ve written (730 pages, not including Introduction and Index), and I needed to get it out as soon as possible after the release of Dreamweaver CS3. The book was finally shipped to the printers at the end of June, so it should be available at online booksellers and in bookshops on or around 23 July. I finished the book in record time—seven months from starting the first chapter to finally packing it off to the printers. In spite of the rapid turnaround, it’s been fully tested in the final version of Dreamweaver CS3. I’m also delighted that Tom Muck, the highly respected developer of Dreamweaver extensions and author of several books, agreed to be my technical editor. Between us, I believe we have created a great book. Please go out and buy it by the cartload. 
Another reason for not blogging much is the fact that, when testing Dreamweaver CS3, I have been under a Non-Disclosure Agreement. It’s hard to blog when the things you really want to write about have to be kept under wraps until the software is released.
July 7th, 2007
… or maybe they were just too polite to say.
I’m currently working on the draft of a new book about PHP, and decided to create a form to demonstrate the effect of the various arithmetic operators. I used the same set of examples that I’ve stuck with ever since Foundation Dreamweaver MX 2004. The example for modulo division is $x % $z, where $x is 20 and $z is 4.5. Since modulo gives you the remainder of a division, the result is obviously 2.
Well, at least that’s what I thought. It’s mathematically correct, so nobody ever questioned it. Imagine my surprise, then, when I fed this example into my form and the result came back as 0. Had I stumbled across a PHP bug?
I hunted around on the official PHP site, and couldn’t find anything. So I did some more tests. When I played with integers, modulo worked exactly as I expected. It’s just with decimal fractions that it behaved oddly.
Finally, I consulted Programming PHP by Kevin Tatroe and Rasmus Lerdorf, which reveals that, in PHP, the modulo operator converts both numbers to integers before performing the calculation. As a result, 4.5 was being rounded up to 5. Hence my mistake.
It’s nice to discover an error in one of your own books before others point it out, but it’s a bit embarrassing to have made the same mistake in four books. 
Strange that it’s not mentioned in the PHP manual, either.
March 8th, 2007
Let’s me nail my colours to the mast straight away: I use XHTML and have done so for several years. XHTML 1.0 has been a W3C recommendation for seven years (since January 2000). I’m aware of the well-argued objections by Ian Hixie, among others, against sending XHTML as text/html. Opponents of switching to XHTML 1.0 also point out quite rightly that XHTML 2.0 won’t be backwards compatible with previous versions.
So the arguments that break out in online forums from time to time about whether to use XHTML always tend to go over the same ground again and again: XHTML 1.0 isn’t really XHTML because it’s normally delivered using the wrong MIME type (text/html instead of application/xhtml+xml), and anyway everything’s going to change several years down the line when XHTML becomes the standard. My viewpoint has always been this:
- XHTML 1.0 is an official standard
- It’s fully supported by modern browsers (even Netscape 4 has no problems with it)
- Using XHTML 1.0 properly (in other words, making sure that it validates) teaches you the stricter standards that will be necessary when XHTML 2.0 eventually comes along (if it ever does)
- Well-formed XHTML makes it easier to work with CSS and dynamic code, such as PHP
Of course, you could use the same arguments about valid HTML 4.01. What matters most of all is that your code follows the rules and doesn’t rely on the forgiving nature of current browsers to cover up your mistakes.
This subject came up again a few days ago in the Dreamweaver forum. The discussion didn’t produce any real enlightenment, but it set me thinking. One of the arguments used in the past against adopting XHTML 1.0 is that “it doesn’t futureproof your site” because you’ll have to do everything again when XHTML 2.0 comes along. Then it struck me: that argument is completely wrong.
XHTML 1.0 is HTML 4.01 reformulated as XML. Since XML is designed to be machine-readable, it is futureproof. Pages designed with XHTML 1.0 may not be displayed by future browsers in the same way as XHTML 2.0, but the DOCTYPE will tell the XML parser how to read it. The same isn’t be true of HTML pages, even if they validate according to the 4.01 recommendation, because an XML parser will choke on empty elements, such as img tags.
January 2nd, 2007
PHP Solutions has been out for only just over a month, but I’m thrilled to see that Carolyn Wood, Editor of Digital Web Magazine, has put it at the top of her favourite books of 2006. What I find particularly encouraging about her brief comments is that she’s already using some of my “solutions” in her own sites. All too often I find that I pick up a book on web design or technology, and think: “Hmm, that’s interesting”, but then never really do anything with my new-found knowledge. It’s nice to know that I’ve inspired at least one person to try something out.
December 22nd, 2006
As a result of lobbying here and in a private forum, the Dreamweaver 8.0.2 PHP hotfix is now freely available for download from this technote on the Adobe website. Thanks to Scott Fegette of Adobe and everyone else for their efforts behind the scenes to bring this about. Please note that the hotfix is needed only if you are using Dreamweaver to develop with PHP. It is required to complete chapters 9 through 12 of my book Foundation PHP for Dreamweaver 8. It fixes the following problems in PHP pages in Dreamweaver 8.0.2:
- CONCAT() stripped out of SQL queries by Dreamweaver
- Failure of XSL Transformation server behavior in PHP 5.1.4 and above
- Backslashes incorrectly inserted when magic quotes are turned off
- Problems with LIKE in SQL queries
December 18th, 2006
A lot of people have complained (and rightly so) about the way Adobe forces people to jump through seemingly endless hoops in order to get the PHP hotfix that fixes a handful of serious bugs in Dreamweaver 8.0.2. One of the advantages of being an author of books on Dreamweaver is that I can participate in a private forum and raise matters of concern directly with Adobe and the Dreamweaver team. Yesterday, I posted a message in the forum expressing my frustration about the “scandalous lack of availability” of the hotfix, and in the process sparked off a heated debate.
I pointed to the slew of complaints in response to my original blog post. Fortunately, Phil Adkins had reproduced the response he received from Adobe Customer Service. An Adobe representative quickly replied that Phil had got in touch with the wrong department. It wasn’t Customer Service, but Technical Support he should have contacted. Quite frankly, this is nonsense. When customers get in touch with a company, they frequently have no idea which department they’re dealing with. It’s the job of Customer Service to put them in touch with the right one.
But it shouldn’t be necessary to ring or email any department in Adobe to get the hotfix. It should be made available for immediate download like any other Dreamweaver updater. That message has been passed on to Adobe in emphatic terms by me and several other people. The Adobe rep promised to convey that message to the Dreamweaver team. (Update: the hotfix can now be freely downloaded - see Scott Fegette’s comment. )In the meantime, the following should help:
Contact Dreamweaver Technical Support, not Customer Support (the details are in the right column of this Adobe page)If Technical Support doesn’t know what you’re talking about, tell the representative that it’s covered by TechNote b6c2ae2aTell Technical Support that you need DW802_HotFix-0_6_0.mxpIf you still get nowhere, ask the representative for an incident number, and post the details here - I’ll pass them on to my contact inside Adobe
Hopefully, nobody will need to go as far as the last point, and this silly saga can be brought to a close. The tragedy is that it happened in the first place.
December 16th, 2006
Waiting for the first reviews of a new book is always a tense time for an author, so I was delighted to visit Amazon.com today and see not only one, but two reviews that give PHP Solutions five stars. It’s as though Christmas has come early. All I need now is for lots of people to take notice of what one of the reviews says: “this book is a must have”. Although I enjoy writing books, it’s hard work, and the author gets only a tiny portion of the cover price in royalties. Buying through the Amazon links on my site can actually double the amount that I receive for a single copy.
December 9th, 2006
For years, one of the big complaints from newcomers to PHP has been the lack of a decent way of automating the installation of PHP on Windows. The Windows installer on the official PHP site was totally inadequate to meet the needs of non-experts. It installed a severely restricted CGI version of PHP that included no extensions and required IIS. The lack of extensions meant that support for MySQL was no longer automatically built into PHP 5, and the requirement for IIS excluded anyone using XP Home. All that has changed with the release of PHP 5.2.0. The Windows installer now offers the full range of extensions and automates most of the configuration on a wide range of web servers.
I suppose you could argue that, if you plan to use a programming language like PHP, you should be capable of digging around in a few configuration files and setting everything up manually. That’s true, but it’s been a case of chicken and egg for many people. If you’re completely new to programming, it’s very off-putting to have to struggle for days trying to get everything installed and working correctly. The configuration instructions in the PHP documentation do contain all the necessary information, but they’re very intimidating for a beginner. In fact, it was because I found so many readers stumbling at the first hurdle that I devoted so much space to detailed step-by-step instructions in all my PHP-related books. Yes, I could have told people to use XAMMP or one of the other all-in-one packages, but I have always preferred to stick with the official version. Too many people were left in the lurch when a very popular package stopped development overnight several years ago.
First impressions of the new Windows installer are very favourable. The interface is very familiar to Windows users and the steps are easy to follow. However, in order to make the necessary choices, you need to have a basic idea of the various features offered by PHP. You also need to install a web server first. Otherwise, the installer can’t do the necessary configuration, thereby removing one of its main advantages in the first place. I tested the installer by completely removing all traces of PHP from my computer, and it performed a successful install on top of Apache 2.2.3 with the minimum of fuss. You can see full instructions, complete with screenshots in the Tutorials section of my site.
I would be interested to hear the experiences of others, particular anyone trying it out with IIS.
November 3rd, 2006
Next Posts
Previous Posts