Any plans to make php5 the default?

[Mashi]

Hi,

I signed up yesterday. Great experience so far!

I was wondering if there are any plans to make php5 the default handler for php files. I know that this host has had php5 support for roughly 2 years and the mod_rewrite setup to redirect queries for php5 apps is almost 2 years old now.

Probably not many people have had the same problem as me because I wrote my framework to dynamically generate URLs for links so they all point to mashi.org:9000, and since it also uses mod_rewrite, none of them work. I can fix this easily, but I still thought I'd bring it up ;).

Alternately if you have a server that runs php5 only I'd be interested!

Thanks.

[Matt]

You can always provide URLs without the scheme + host e.g. /foobar.php and the browser will negotiate what the correct scheme + host should be (e.g. http://www.foobar.com or http://a.foobar.com).

PHP4/5/6 introduces an interesting dilemma. On one hand PHP4 is rumored to reach its end-of-life at the end of this year (http://derickrethans.nl/php_quebec_conference_rip_php_4.php), which means no further updates will be released for PHP4. On the other hand we do have legacy users who rely on constructs native to PHP4 ($this assignment, DOM parser, I'm looking at you) and some much more discrete engine changes that aren't readily visible.

The servers rely heavily on eAccelerator to provide caching and optimization to PHP code, but eAccelerator support for PHP 5.2 still isn't of production quality (http://eaccelerator.net/ticket/242). My statement takes into account the fact that Bart released 0.9.5.1 a few ago to correct a long-standing bug in 5.2 support since 0.9.5.

Third issue is running them in tandem, which the only way to do without switching to FreeBSD, would be to either run as one as a SAPI and the other as a CGI or to run parallel servers. Running PHP5 as a CGI would affect paths, because suexec chroots each request prior to processing, plus the legacy suexec binary used checks a flatfile map for the corresponding filesystem path prior to chroot'ing (thanks, Ensim!) The next best option then would be to run two Apache servers in parallel and use the proxy flag (P flag in the rewriterule directive) to pass it off to the PHP5 server on port 9000 and transparently return the data back to the user. This works unless you're using $_SERVER['HTTP_HOST'] in which case you will get the :9000 junk on there...

Regardless of whichever interpreter becomes the default, one party will get burned. Whether it's the early or late adopters depends on the default interpreter. Late adopters are much more resilient to change, so when PHP4's EOL rolls around I will be stocking up on Tums once again. They also have the least likelihood of upgrading their applications or providing workarounds immediately. Early adopters such as yourself on the other hand are much more malleable and therefore much easier to work with; as a result, you get the short end of the stick sometimes ;).

I definitely want to move forward with PHP6 once it's released and retire PHP4 after it reaches its EOL. Assuming a formal announcement comes through on php.net regarding the EOL by say August, then I feel that a 90 day warning would be adequate about the switch from PHP4 to PHP5. PHP4 would be accessible in the same fashion as PHP5 (i.e. rewrite rules) after the 90 day period through early 2008 after which point if you haven't made changes to the code, then in all likelihood it won't happen without coercion. PHP4 running on port 9000 would then be replaced by PHP6.

That is how I envision the transition from PHP4 to PHP5. I will have a definitive timetable once a formal announcement comes in on php.net's Web site.

[Mashi]

Thank you Matt for your response it is clear that this has not gone without consideration!