PHP5

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.

Did you notice the cost of voting for NOT upgrading to PHP5 is 1 and the cost of voting FOR it is 5?

Makes sense to me and wow .. I know I searched for PHP5 earlier, but didn't find it. Maybe I failed to look for PHP 5 vs PHP5.

Anyhow, it's easier for them "not" to upgrade to PHP5, thus why the points cost less.

php5 will break a lot of user's scripts, so one reason for going slow on upgrading throughout DH. Give all the third party script developers time to upgrade their scripts to be php5 compliant.

A toggle would be nice.

In reply to:

---

php5 will break a lot of user's scripts, so one reason for going slow on upgrading throughout DH. Give all the third party script developers time to upgrade their scripts to be php5 compliant.

---

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.

I'm not disagreeing with y'all on the benefits... but it WILL be a nightmare for many users who may not be as technically saavy and upgrade conscious as you. This is a shared space.

In reply to:

---

It has already been more than 8 months since the first stable release of PHP 5, and it has since been updated twice.

---

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.

That'd be why it's being suggested as an option. Those users who are savvy enough to take advantage of the benefits can have it, and others can stick with PHP4 until it fades away.

+1 for offering PHP5 as a control panel option.

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.

- Jeff @ DreamHost
- DH Discussion Forum Admin

In reply to:

---

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).

PHP5 requires LibXML2 vs 2.5.10 or greater. Dreamhost is still on 2.4.9. And the latest version is 2.6.18: http://xmlsoft.org/sources/

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.

In reply to:

---

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.

---

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).

> 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™.

- Jeff @ DreamHost
- DH Discussion Forum Admin

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?

> 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:

https://panel.dreamhost.com/index.cgi?tree=home.sugg

- Jeff @ DreamHost
- DH Discussion Forum Admin

Yes, I've voted. Is there a way to view the overall voting results?

In reply to:

---

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).

PHP5 requires LibXML2 vs 2.5.10 or greater. Dreamhost is still on 2.4.9. And the latest version is 2.6.18: http://xmlsoft.org/sources/

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.

---

Given the estimated time frame for PHP 5, is there any chance these other issues would be resolved in a sooner time frame, allowing users to successfully compile their own php cgi library?

I went ahead and compiled my own version of LibXML2 with no luck:

In reply to:

---

checking libxml2 install dir... /home/gpcentre/lib
configure: error: libxml2 version 2.5.10 or greater required.
[yerba]php-5.0.3/$ ls /home/gpcentre/lib
SpamAssassin@  libxml2.la*  libxml2.so.2@       perl/  pkgconfig/  xml2Conf.sh
libxml2.a      libxml2.so@  libxml2.so.2.6.18*  php/   python2.1/

---

What did you use for the configure command for PHP 5?

For example, did it include:

--with-libxml-dir=$HOME

(I believe that would be the correct path, from what I see.)

I actually got that working using $HOME finally (was using $HOME/lib originally). I was just about to post that until the configure died two more times.

It's not compling any extensions.

Died on CURL (set to /usr), mcrypt (set to /usr) and now mysql (set to /usr). I'm stopping here. I need MySQL, removing that is not an option.

/usr are values I gathered from phpinfo() of the CGI PHP4 I'm running on my site.
http://www.gpcentre.net/info.php

As I said earlier, I don't want to install every library it dies on into my home directory.

*PS: Let me also add that I know /usr worked once upon a time as I had compiled PHP4 CGI once before. No clue why it doesn't work anymore. This was before some server moves, must be cause of that...Edited by guice on 03/28/05 08:27 PM (server time).

I had to compile all the libraries, too...

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.)

Maybe it's a candidate for the suggestion box?

In reply to:

---

Maybe it's a candidate for the suggestion box?

---

Should need to. They use to be there and there's even a FAQ on how to Compile you're own version of PHP. They should be there.

O_O
Ummmm pardon the ~bump~, but does anyone else see that PHP5 is now available as a PHP-CGI sub-option in Domains->Manage???

(Maybe my server is just new? I'm on Ike.)

[edit]
I think it's openly available, limbo-randy has the option too...
DREAMHOST:
THAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANK YOU!Edited by VxJasonxV on 05/27/05 07:23 AM (server time).

On Nice! I hadn't even noticed. I so rarely go into that section of the site these days.

Thanks much for pointing that out!

And thanks a mill to DH for adding that option!!

Here's the changes I've seen from the default PHP5 configuartion (default value in parens):

allow_url_fopen: Off (On)
magic_quotes_gpc: On (Off)
log_errors: On (Off)
max_input_time: -1 (60)
output_buffering: no value (4096)
register_globals: On (Off) -- ACK! TURN IT OFF! Turn it OFF!
register_long_arrays: On (Off)

It's installed with MySQL but not with mysqli. It is also installed with fastcgi enabled.

The biggest beef I have with this install is the fact that register_globals is still on! Please, turn register_globals off!

In reply to:

---

The biggest beef I have with this install is the fact that register_globals is still on!

---

I've got to agree with guice here. If DreamHost is going to offer PHP5, please, please, PLEASE turn off register_globals. It defies logic to go through all the trouble of implementing PHP5 and then missing the opportunity to put this issue to bed.

I also in big favor of offering the mysqli extension, and even SQLite, since it will become a great way of offering self-contained scripts that require limited database functionality, such as a stats package.

In reply to:

---

I also in big favor of offering the mysqli extension, and even SQLite, since it will become a great way of offering self-contained scripts that require limited database functionality, such as a stats package.

---

SQLite is enabled by default (and is installed), however mysqli has to be enabled upon compile time via the same means as as mysql; --with-mysqli

Should we send it to suggestions, or all send it into support?

Well, nate and dallas do regularly read the forums, but it wouldn't hurt to send in a support/suggestion ticket under the PHP heading about it.

Another question.
magic_quotes_gpc() is On.
I'd like to know what everyone else's thoughts are in regards to asking to shut it off.

In reply to:

---

Another question.
magic_quotes_gpc() is On.
I'd like to know what everyone else's thoughts are in regards to asking to shut it off.

---

That's a toughie. Part of me thinks it should be set to off, simply because it gives more control back to the developer; however, it would mean care would have to be taken to ensure that slashes are added when appropriate, with addslashes().

Yeah, I suppose I would rather it was set to off.

In reply to:

---

Another question.
magic_quotes_gpc() is On.
I'd like to know what everyone else's thoughts are in regards to asking to shut it off.

---

As a developer, I'd prefer them to be 'Off' as well. As scjessey said, it gives the control to the developer and not PHP.

On a side note, it's also a good idea to turn off register_long_arrays. This just creates $HTTP variables similar to the ones already in $_SERVER and it's a performance hitter.

I just turned it on and the panel is reporting that the change is active, but my software is still reporting PHP 4.3.10. Any idea how I can actually get it to activate?

bryan | website

Make sure you don't have any directives within your .htaccess file.

If that doesn't work, I guess you can add it youself:

In reply to:

---

Action dh-php /cgi-system/php5.cgi
AddHandler dh-php .php .pcgi

---

That goes into your .htaccess file within your root directory.

Thanks guice. I added that to my .htaccess and it manually turned it on. I also filed a ticket with DH to have them fix it on their end so I can just use the control panel eventually.

This of course only happens on 1 domain, my others are all able to turn it on and off just fine. But your solution works for at least the time being. Thanks!

bryan | website

So I keep getting these XML not supported errors when using PHP 5. So is XML support seriously not compliled into this build of PHP? It was there in 4 right?

bryan | website

hmm, PHP5 on DH's server was compiled with '--disable-libxml' which, you guessed it, disabled XML and SimpleXML.

Now that's wrong. I know why they did that, too, but absolutely shocked they actually did it!

Nate/Jeff/Dallas, why did not yall just upgrade the libXML libraries instead of disabling XML entirely? Full details on upgrading libXML is in this thread, posted by me!


You know, I hate to say it, but more and more their PHP5 install is starting to feel more like a rush job instead of being actually thought through...

As a stop gap, I just followed the instructions in the wiki and compiled my own version of PHP. Hopefully DH will eventually build this in.

bryan | website

In reply to:

---

So, believe it or not, we've finally implemented PHP 5! Yeah, for real!
In fact, you can turn it on right now for any of your fully hosted
domains from the "Domains > Web" area (click "Edit" for your domain).
Realize PHP 5 is only available for now as php-cgi though (not as an
apache module). But if you've absolutely got to have some cutting-edge
PHP 5 feature, that shouldn't matter too much, right!

---

Hum, guys (DH dudes), we can like get the Issues with PHP5 fixed before you spam the world that you've gotten it installed. ;)

There's a lot of problems with your install and they must be fixed before production use!

In reply to:

---

There's a lot of problems with your install and they must be fixed before production use!

---

Yeah, guys. Don't let the evil spectre of register_globals plague us for the rest of eternity, and be bold and turn off them magic quote thingiwotsits.

No xml...
I guess that explains the errors I just noticed in my MediaWiki.

hmmm, PmWiki was breaking under PHP4... fixed by going to PHP5 and it breaks my MediaWiki install. :-P

It is a shame that php5 is currently breaking one of the "One click installs" just because of libxml. :-(

Put it in suggestions, e-mail support with that information (one breaks, one doesn't, and this is all stuff you offer ;D), and all that good stuff.

I shall be doing the same shortly.

I've submitted a problem ticket on PHP5 since it is problems with PHP5 itself. Here's a quote of the ticket I've submitted;

In reply to:

---

As I've pointed out on the DH forums
(http://discussion.dreamhost.com/showflat.pl?Cat=&Board=3rdparty&Number=19315)
there are a number of problems with your PHP5 install. To go down the
list:

- register_globals is on - REQUIRED OFF
- register_long_arrays is on - Highly Suggested OFF
- magic_quotes is on - Suggested off
- No XML support what so ever; MAJOR problem. I know how you can fix
this if you need help.
- No mysqli; one of the key additions in PHP5 is mysqli and it's
support for MySQL 4.1+ features. You've just installed MySQL 4.1, now
install mysqli.


It's actually very important you get these things fixed before you
cripple yourself, again, cause too many people are relying on features
turned on (ie; register_globals!).

---

I completely support guice's recommendations and concerns. This is an excellent opportunity to establish "best practices" where PHP 5 is concerned.

I got a reply on my Support request in regard to the XML issues with MediaWiki.

You can have the best of both worlds though.

Create a .htaccess file within your wiki directory with the following:
Action dh-php4 /cgi-system/php.cgi
AddHandler dh-php4 .php .pcgi

This will make just the .htaccess directory use PHP4 CGI. To use the PHP4 Apache Module, just use:
AddHandler application/x-httpd-php .php .pcgi

Then you can set your site to PHP5 for everything else.

It does suck they can't get PHP5 installed with LibXML2. Kind of wish they'd just install LibXML in a different directory per the source just to run PHP5, but I can understand the desire to keep with the Debian packages.

Lets just hope they fix the other issues (I'm still in talks with them on that).

.htaccess... I had totally forgot what it can do...

8-|

Thank you very much,
though I think I might change over to PmWiki in the future since I can customise it easier then MediaWiki

thanks again.

From the PHP5 ("No XML Support in PHP5?") thread in programming:

In reply to:

---

Yeah, duh, the guy who packaged up PHP5 messed up and included the wrong php.ini

I fixed it. Everything's from the php.ini-recommended in the PHP5 distro.


nate.

---

Yay :D. Good bye Register Globals, etc. etc.

guice, I had a question. I think I'm going to use your suggestions for dh-php5, although I'd prefer to do it the other way around, have 4 running and set up a handler for 5.
Can this be done?

Yes. Just point the CGI to /cgi-system/php5.cgi

All I have to say is:
WOOT

Thanks guice ^_^.