Miles Thompson wrote: > The problem with PHP 5 is that the ISP's have to be so conservative. > There's no tagging mechanism which says "process these files with > PHP5, use PHP 4 for everything else." That would be so wonderful. Just to be able to set what PHP .so to use based on <VirtualHost/> or <Directory/> in Apache would be bliss. Under Windows it's easier, of course, since you have specific configurations for each virtual host in IIS. I've tried running the CGI version of PHP5 on a PHP4 system, and of course it works, but it's slower than molasses in January. > So, based on experience, better to move early than later. I suspect a > jump from PHP4 to PHP6 will be huge -- the problem is to move the ISPs. A lot of ISPs run some form of enterprise Linux, or it could be just a control panel, that is dependent on the RPM version of PHP, which in most cases is still stuck arond 4.3.x somewhere, except in those cases where the ISP has taken the law in their own hands and compiled PHP from scratch, overwriting the RPM version, and hoping that this will not break anything too seriously when the control panel tries to upgrade itself the next time. ;) Others use scripts that are encoded with either IonCube or Zend, and are thus forced to stay with PHP4 since their software vendor hasn't made the leap yet. For instance, when encoding with Zend Encoder for PHP4, you can get some pretty nasty errors when running under PHP5. If the software vendors could make the leap RIGHT NOW and convert their godforsaken software to PHP5 and release two versions since there'll hardly be any difference in the code, we'd be a long way already. It's all mostly related to the encoder in these cases, for instance Zend. That's the way we do it with one of the applications I've written, it's shipped both as PHP4 and PHP5 Zend encoded, as well as IonCube encoded. Warm Regards, Torgny -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
