The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

It took some digging to find any mention of PHP5 on Pair's site. In fact I only found indirect reference to it beyond the link mentioned above. What I have discovered is that by default Pair uses PHP4. They only use PHP5 if the .PHP5 extension is used or if the .htaccess file instructs the use of PHP5 (e.g. "application/x-httpd-php5cgi html"). I also discovered that PHP5 is installed as a CGI and not as a standard module the way PHP4 is installed. This alone broke a key Apache function call on a test I ran of a few of my pages (I created copies with the .PHP5 extension of a few pages). Once this issue was resolved, things seemed to run just fine.

I'm not sure, however, that I'm ready to switch my site to PHP5 as I will need to do a lot of testing and I'll need to figure out how to install PHP5 on my WinXP box in a similar configuration that Pair uses so that I can test before uploading. Unless I can pull this off, I won't be able to develop in PHP5.

Personally, I'm more interested in the fact that they upgraded MySQL and what this will enable me to do with my queries. I have many queries that I would have preferred to write in a more efficient manner but wasn't able to because of limitations in MySQL.

In regards to the negativity of upgrading or "catching up with the rest of the world" I really haven't seen any compelling evidence that I will realize any benefits from upgrading my sites. Saying PHP5 is faster is nothing but hyperbole that gets used as the reason to upgrade with every software package I've ever used and rarely does it holds true. If PHP5 is really faster, then by how much and why? If I use the same code on PHP5 vs. PHP4 will it really be faster or will it only be faster if I rewrite the code? Security isn't really an issue because PHP4 is still being supported. New functionality isn't really an issue as PHP4 does all I really need to do.

Sometimes upgrading to the latest and greatest version of a program doesn't really provide any real benefit. How many people here are still using Photoshop 6 or 7; Windows 98 or 2000; Office 2000 or older generations of other software? If software does everything one needs, is being supported with security updates and promised performance benefits are elusive, why should one upgrade? Just to hang out on the bleeding edge?

Preaching to people that they should upgrade because they should upgrade turns people off to the idea of upgrading. Disregarding or belittling valid concerns about upgrading also turns them off. If people are to upgrade then it must be easy and provide compelling and tangible benefits. For me MySQL upgrades promise greater possibilities of tangible benefits than does PHP.

Well, performance wise, I'm not sure of it myself. PHP 5 uses the new Zend II engine, apparently, but since I haven't (as of yet) been able to get side by side PHP 4 and PHP 5 on the same machine as Apache2 modules, I don't really know.

I've actually made an attempt with my home testing server to get PHP 4 and PHP 5 running as Apache 2 modules side by side. I've managed to eliminate the errors in the error log, but it's still dying (or killing technically) because of some illegal memory access or another. To get as far as I've gotten, though, required changing the source code of sapi/apache2handler/sapi_apache2.c and of main/php.h to use a different MIME type, and to change the Makefile to install PHP into different directories than PHP 5. My hypothesis so far is that I'm missing something and both PHP versions are accessing the same something or other.

My conclusion though, is that it may well indeed be easy (relatively) to get the two PHP versions running side by side. I haven't rewritten any code, but I know if I do get it working it won't be a practical solution for hosting companies as it would be a hack. Still, if it's possible, then it shows that there weren't any technical reasons that the PHP developers couldn't have made the two PHP versions run side by side (like 4 and 3) which leads me to conclude that either they simply didn't bother or view it as important, or else they purposefully chose not to do so for some, currently unknown, reason.

I've spent the last few days trying out tricks to get PHP4 and PHP5 running side by side as Apache modules and all of them require hacks that mostly work but still have some bugs and most importantly, will break upgrades (or at least make keeping up to date a pain in the butt). I was going to order a new server for PHP5 development but I just rethought that and now I will order a beefier server, move my PHP4 stuff over and instead of installing PHP5, I'm gonna try out Ruby on Rails to test the hype for myself. In fact, if we could get people to jump ship like that, it might send a stronger message to the PHP language developers and hope they won't make life difficult for others like this again. I don't think that Ruby on Rails is necessarily better than PHP 5.1 but it is probably just as good and will save me a lot of work just from a server administration point of view.

"I disapprove of what I say,
but I will defend to the death my right to say it."

I sell a commercial application that requires PHP5. I think that sales have been hurt a bit by the fact that PHP5 support in shared hosting environments is far from ubiquitous. Right now I'm averaging about 2-3 sales per week with one in three buyers emailing me after the fact saying they just realized their host doesn't support PHP5 yet.

By far the most popular response I got back from hosts as to why they did not support PHP5 (and I asked A LOT of them), was "CPanel doesn't support it yet." Which to mean translates to ignorance on the part of web host company owners.

I did receive a fair number of responses that when PHP5.1 went stable they would upgrade--and indeed I do think I have seen slight rise in the number of PHP5 capable hosts since that happened.

BTW, I think your product is trail blazing. First real product I have seen for php 5 that I could tell my clients about.

As long as the majority of hosting providers don't switch to it its not quite safe. For intranets ... PHP5 should be the de facto tool ... especially if you need a well designed system

My Intranet is running 4.3.8 with apache 1.3.30 on a gentoo box. They didn't let me setup my own server

Well I might inherit the system as the head IT guy just left, technically I am the webdev/database admin, so when I finish my intranet system I will start overhaul on the server using php 5 and Mysql 5.

I just had a conversation with a new client today. They are running 4.3.x and had attempted an upgrade to a newer version. After the upgrade broke their existing web sites, they backed off the upgrade and their management decreed that they will no longer upgrade PHP.

PHP 4 seems to have reached a "good enough" stage that's really hard to get past, especially with the backward compatibility breaks.

Serverseed IS NOT reliable.

I have had nothing but problems with this. I'm replying to warn users who may think that serverseed is greate. Almost every subdomain and addon domain that I try and use fails, and it's taken me weeks to get support, followed by some excuse. If you have more then one web site, I would stay far away from this organization.

Originally Posted by Bleys

Fortunately the majority of my customers have decided to just go ahead and purchase a PHP5 hosting account (I recommend serverseed.com to them, usually, who are reliable and cheap). I have given a couple of refunds, as well. I figure if I am nice about it, when their host upgrades there's a good chance they'll come back and order again.

As for contacting hosts, I mainly did that when I was trying to decide if I should write the script in PHP5 or not... I did a broad survey to see how many hosts had plans to upgrade, when, etc.

I just had a conversation with a new client today. They are running 4.3.x and had attempted an upgrade to a newer version. After the upgrade broke their existing web sites, they backed off the upgrade and their management decreed that they will no longer upgrade PHP.

PHP 4 seems to have reached a "good enough" stage that's really hard to get past, especially with the backward compatibility breaks.

And for bigger sites the tremendous efforts needed to get the code php5 compatible.
I just took a quick "wc -l" round on our class repository where i work, its roughly 30000 lines of code that has evolved to where it is today (php4), some of it way back from php3.

We run multiple sites and services and thats merely the backend code which are somewhat common. On top of that comes what i'd call "client code", the code that stitches together the actuall sites/services.
I cant be bothered to run all over the place to find the number of codelines there, but i can say its a fair bit.

Add to the equation that only some parts of the class repository is unit tested, most of the client code is detestable code. So to get things over to php5 requires to take 1 component at the time and make sure it works, meaning we first have to make the code testable, then add tests, then probably refactor it to smaller components, then start testing each unit against php5, then test the full sites/services against php5. All this while keeping up with bugfixing, new projects etc.

That is a lot of work and its not just to tell the managers that "we have to rewrite every line of code written in the companies history, ok?".
But at the start of 2006 i suggested a set of "new year resolutions" for our tech group, one of those was to have all code over to php5 by the end of the year. So far we've just set up php5 as cgi running alongside php4 on our dev server

My company is having to upgrade to PHP5 to achieve industry compliance. If we're found to have unpatched known vunerabilities in software we run on (and in our own code) we'll be held liable so we can minimise that liability by moving to the latest PHP/MySQL. I welcome the upgrade as a developer but also realise it's a lot of work.

For most companies this would not sit too well either since business often likes to sit back and watch software for a bit before commiting to upgrade.

Fortunately (in an odd sense) the code is largely procedural based with not much clever stuff going on so I can't see there being much breakage when it comes to moving to 5 though - famous last words

If any of the cpanel distributors came out with a fully working mysql5 , php5 and php4 solution out-of-the-box then you would see almost all of the web hosting wold running them within a two week period.

Its funny you say that, i was only thinking earlier that if zend "volunteered" to re-write a few of the most common, hosted apps into php5, in the same way that m$ gave away its vb consultants in the mid/late 90's to migrate business apps away from powerbuilder, then i reckon the community would see complete php5 adoption within 6 months.

I've used PHP5 on Site5 quite successfully, and since their PHP4 installation is based on CGI rather than mod_php, the environment difference is minimal. It's grueling having to go back to PHP4 code now, and quite frankly I think that staying with PHP4 only makes sense for people who have no interest in OOP whatsoever.

As for the "I'll just give up and try Rails" comment, good luck. Rails can be quite finicky on shared hosts, so you're not really gaining anything by going with that over PHP5 unless you specifically know what features Ruby/Rails has that PHP5 doesn't that serve your specific programmatic needs.

Hopefully by the time PHP6 comes out, PHP5 will have gained much more marketshare -- otherwise, some people are going to be even more shocked at the changes!

It's grueling having to go back to PHP4 code now, and quite frankly I think that staying with PHP4 only makes sense for people who have no interest in OOP whatsoever.

Well, we have a very big interest in OO. Even our Perl code is OO .

We are still using PHP 4.3 after an abortive attempt to move to 4.4 late last year. This means that we will jump straight to PHP 5.1, which seems the easiest route.

Our problems are usage of the PHP 4 XML libraries, and loads and loads of references. There are quite a few times where a copy, lack of reference, is important too. Due to the size and complexity of this app., we have no choice but to get to PHP4 and PHP5 compatibility simultaneously whilst we migrate the servers. Everyone is dreading it so much, we keep putting it off .

Anyone managed to do a gradual approach rather than a big bang? Anyone any experience running with the various compatibility flags during migration?

I started off with PHP5.0.1, then moved at various point, from 5.0.3 to 5.1.0 as recently as this month; My host moved from 5.0.3, to 5.0.4 last month so now the uptake isn't as slow as what it used to be, as it was earlier this year.

You have everything to gain by moving in my view, but as you note PHP6 is around the corner - so to speak, but there is nothing definite that I can find, so PHP6 could be another 12 months away, or it could be less...

No one knows, but as far as I'm concerned, PHP4.yuk is dead and buried. Let the celebrations continue

Hmmm, you think PHP6 will come,...within 12 months... they better be writing stuff from scratch then and dump everything that's in it up untill v3.x, cause they have major problems with it, hence why lot's of servers are still running v4.x and dont bother to go to 5.x cause it's not up to it's requirements, hope v6.x will be

Anyone managed to do a gradual approach rather than a big bang? Anyone any experience running with the various compatibility flags during migration?

Not a gradual approach per se, but we "simulated" it on another server first. Copied over everything and performed a total upgrade there. After we fixed most of the scripts we offlined the main server, upgraded, copied updated scripts over and started debugging. We upgraded some other big stuff on that machine that day, too.

Maybe, just maybe it isn't so problematic, at least for us it wasn't. We luckily only had 1 server to upgrade, because we were already up-to-date on the developer computers. Projects that don't run on our server were either not upgraded at that time, or were already php5 compatible. I'm glad it's over, it was quite stressful, and quite a few glitches were reported over next few weeks. And I prefer php5 to 4 any time of day.