How are we on the front of the PHP5 upgrade? It’s been over 6 months since the talks about upgrading to PHP5.
Has there been any headway? As a developer, it is now really hendering my development in creating sites for clients as they, too, host their site on Dreamhost. I have fully migrated to PHP5 in my place of work and feel hendered in having to downgrade for my clients; especially when their sites can greately benifit from PHP5’s feathers.
Has the option to provide a seperate option of a PHP5 check box within the Domain Tab been brought to the table, yet? Similary to that of your PHP as CGI and Extra Security check boxes.
I’d put all 20 of my suggestion points within the Suggestion Tab into PHP5, but I don’t see it listed.
It has already been more than 8 months since the first stable release of PHP 5, and it has since been updated twice. There are hardly any backwards-incompatible differences to worry about, and these are more than offset by the performance increase.
The advantages of switching to PHP 5 are significant. Developers will be able to take advantage of support for Improved MySQL, SQLite, and a better object model.
It has already been more than 8 months since the first stable release of PHP 5, and it has since been updated twice.[/quote]
It has been 4 years and 10 months since the first stable release of PHP 4 and it has been updated over two dozen times. It’s stable fast, and most PHP scripts are written for it.
I think that most admins don’t like the idea of becoming a security guinea pig for the PHP folks during these ‘early’ years of PHP5.
Besides the new oo features and miscellaneous updates, are there any other reasons to upgrade? For instance, is there any evidence that PHP5 outperforms PHP4? Benchmarks/analysis?
Another thing to keep in mind is that once PHP 4 development/maintenance has ceased, you will see a large migration to PHP5 no matter what.
PHP5 is pretty exciting, though as has been mentioned this is something that is so heavily used by DH customers that switching to it has a potential to break a lot of sites.
There has been some talk about offering a CGI binary version of PHP5 during a transition period, that you would be able to switch to from the Domains/Web section of the web panel. I’m not sure how feasible this would be to add, but it seems like a good middle-ground until we phase out PHP4.
Also, I’m pretty sure you can compile your own PHP5 CGI binary and run it from within your home directory, if you are so inclined - though this would be technically unsupported.
That we cannot. Dreamhost has the wrong version of the LibXML2 library on their servers (maybe more; but that’s where my compile dies). And I don’t want to go out and having to compile that, too (and possibly any other libraries that might be outdated).
I would also point out that LibXML 2.5.10 is almost 2 years old. I’ve personally upgraded my company’s system and my local system to 2.6 w/out any issues.
Allowing the CGI option is a very good starting ground in converting to PHP5. Sites can then slowly move over, you can lock down things like ‘register_globals’ by default and it will insure that Dreamhost has the upto date libraries incase a user wants to compile their own version of PHP5.
I’m not entirely sure either where you’re coming from how this wouldn’t be feasiable. You taking about a performance issue in useing the CGI binary vs built into Apache? Or are you just talking about the technical reasonings of co-existing with PHP4?
Performance is no different, if not better, than running PHP4 as a CGI binary which, judging from the allow_url_fopen announcement, ther are more sites than you realize doing that.
PHP4 and PHP5 can co-exist as easily as PHP3 and PHP4 did during that transition a few years ago. Just name the binary php5 and use traditional apache conf’s to link .php and .pcgi to the PHP5 binary just like you would if an entire site opted to use PHP4 CGI.
However, PHP5, by default, installs itself into /usr/local/php5/ to avoid any conflicts with PHP4 that’s within /usr/local/php (by default).
[quote]I’m not entirely sure either where you’re coming from how this wouldn’t
be feasiable. You taking about a performance issue in useing the CGI
binary vs built into Apache? Or are you just talking about the technical
reasonings of co-existing with PHP4?
Actually, I was mainly thinking of whether or not we can spare the administrative time to add it, test it, and roll it out to customers. Technically it should be possible for all of the reasons you mention, and (in my opinion) A Very Good Thing™.
[quote]Another way to look at it is: “How long can we afford NOT to add it, test it,
and roll it out to customers.”
Any idea? Weeks? Months? Next year?
We can’t really commit to a release timeframe at this point, but I’m not inclined to think it’ll take until next year. Weeks/months seems more likely.
Of course, it really depends on what other stuff our Admins have on their plates (which are always very, very full), and customer demand. If you haven’t done so already, be sure to vote for PHP 5 support here:
[quote]That we cannot. Dreamhost has the wrong version of the LibXML2 library on their servers (maybe more; but that’s where my compile dies). And I don’t want to go out and having to compile that, too (and possibly any other libraries that might be outdated).
I’m guessing that they compile everything once on a central machine, then they copy only the binaries to each server. (They don’t bother copying the headers, which you’d need to compile other programs that use those libraries.)