PHP 5.3: Why We’re All Late to the Party

Posted by Nessa | Posted in | Posted on May 27, 2010

11

It’s been almost a year since the PHP 5.3 branch was released to the PHP community, and yet we’re all still in the shadow of PHP 5.2.  If you’re just a faithful customer wondering why your host isn’t getting with the times, I’ll tell you exactly why: We don’t stock enough diapers to keep up with that ish.

Let me talk about you, the common website owner, that runs a simple Drupal or WordPress site.  You didn’t sign up with your host to go around in circles over compatibility problems that could have been avoided by your host doing a little research. As a programmer, I would hold it to any site owner to check their site’s requirements and the offerings of their host before they unnecessarily waste a lot of time and money, but as a system administrator I frown upon shared hosting providers offering software with known compatibility issues just to be able to advertise as the “latest and greatest”. The latest isn’t always the greatest, and it won’t be until the community catches up with what the greatest has to offer.

I’ve had numerous discussions with my superiors about whether to upgrade to PHP 5.3, and the end result is pretty much the same – we’re just not ready. And neither are our customers, or the developers of the applications they use.  And trust me – this is normal. We all went through the same thing when PHP 4.2 came out, and again with PHP 5, and again with PHP 5.2.  That being said, this is why all the good hosts are now also holding off jumping on the PHP 5.3 bandwagon:

  • Lack of compatibility:  Many open source applications and frameworks (such as Drupal, Joomla, Magento, and even parts of WordPress) are not fully compatible with PHP 5.3 yet
  • No Zend Optimizer or Zend Guard support
  • It’s not required for PCI compliance yet, which is one of the main reasons why hosts upgrade PHP on their servers

PHP 5.3 does have a lot of new features and functions to offer, and it will eventually wiggle its way into mainstream hosting -  it’s just not ready for the shared hosting population yet until everyone else catches up.  Most hosts (including IMH) will still offer PHP 5.3 as an optional upgrade for customers on VPS or Dedicated servers, or as an optional move to a server that has that version. In the meantime, start upgrading your applications and keep tabs on your softwares’ developers to find out when php 5.3 support will be available.  PHP 5.2 will likely become obscure near the end of 2010 or early 2011 in favor of 5.3, and you should be ready when it is.

Be Sociable, Share!

Comments (11)

Here’s an interesting story that illustrates your point pretty well. I developed a small PHP web app recently for work using 5.3. All was going well until I found out the day before I was supposed to release it that the server it was supposed to run on was running Hardy. Hardy only has 5.2 in the repos. Some of the other software running on there would have broken had we updated to 5.3 right then.

So I had to backport to 5.2. Luckily, it wasn’t a major problem, and I got it done in time.

I will say this, though. Drupal works fine on 5.3, as does CodeIgniter, and Jaws-Project.

@King Radical I dealt with an issue with Drupal a couple weeks ago from a customer that requested PHP 5.3. The Drupal developers stated they don’t have a timeframe for compatibility, but they do have some workarounds for people having this problem:

http://drupal.org/node/360605
http://drup.org/drupal-and-php-53

I have several instances of WordPress 2.9.* running flawlessly on PHP 5.3.2, and have been since PHP 5.3.0. Have not run into many issues. Any issues are more than likely caused by poorly written plugins.

Drupal Core might work fine on 5.3, but lots of the *must have* modules have issues :-(

I think the problem is actually cyclical in nature. No-one is upgrading to 5.3, so no need to update the code to work in 5.3, which does not force anyone to upgrade the servers….

These things do tend to be chicken and egg situations. Hosts will usually go by demand, so I think the initiation should come from software developers. So basically, we’d upgrade if we knew that there was support behind it from the software that our customers run.

Few years ago, I used to install a custom PHP interpreter as CGI handler on a cheaphosters shared server. Needs some securing and whitelisting via .htaccess RewriteRules, but this approach still works.

But I have to ask, what exactly are the incompatibilities of 5.3? Apart from the idiotic s***syntax for FUUUU namespaces, it’s syntactically the same. What have I missed?

I’m a big fan of sticking with what works and find it quite annoying to have to continually upgrade.

Imagine if our spoken language required an upgrade every year or 2? e.g. Hi was deprecated and we must now only use hello to avoid an unexpected response.

Sure there will be bug fixes to implement but I think that a language should be specified as regards it’s functionality and that is that.

I have a big problem on my hands. The company I work for has developed over 300 Drupal sites for clients.

Half of them are still running Drupal 5 and all of the Drupal 6 sites use modules that have 5.3 issues. A few of these sites are very active and use a great many modules.

We don’t work on clients sites unless they pay us and we can’t tell them to pay us money because our hosting environment is changing and I don’t think my boss will be happy if I told him that for a few weeks I have to work on all our completed projects for free because PHP is changing version.

We have a managed dedicated server and our hosting company uses Debian and they have a sticked policy of tracking Debian stable. I am very scared of the day they upgrade Debian. They also not wiling to run unsupported software. They gave us 6 months warning before they removed PHP4 as an option.

As mentioned, Drupal is compatible…But I wanted to add it runs faster under PHP 5.3. There were some benchmarks performed that show a very considerable performance boost thanks to PHP 5.3. So I really think it’s best for everyone to upgrade. It’s extremely important for slow, older, CMS’ like Drupal to get that performance increase when it comes to large scale sites. Remember many of our favorite CMS’ out there are still compatible with PHP 4 (well less on that) and many use procedural code and aren’t full object oriented. So if you don’t see the word “class” in Drupal, I’m not sure where people think the namespaces will screw it up…

Anyway, we shouldn’t let fear get in the way and it’s not like it’s something “new” to learn. It’s still PHP. There’s a few new things introduced but you won’t have any problem using it as normal.

But I digress…I think another major reason why it’s not on more shared hosts is because it’s not in some of the Linux distros yet. Wacky, I know, but take CentOS for example. There’s a kindly provided “remi” repository that has it but I think if it’s not in a package manager, then hosting companies are either A. going to be wary of the upgrade or B. going to be lazy about it because it’s not as easy.

An upgrade costs money and if someone selling something for $3/mo or $7/mo even can do less work, they’re going to. Money makes the world go round.

Post a comment