PHP usage statistics

Every once in awhile I stumble across someone who is trying to find their way and decide what they  will do in their career.  As the organizer of a PHP user group I see many new developers passing through.  Of course I always speak of how strong PHP is in the web markets, and encourage new web developers to pursue PHP as a tool in their box of goodies.  Because as a web developer it would be a career limiting move to not have any knowledge of PHP.  Here is why:

Stats on website technologies

http://w3techs.com/technologies/overview/programming_language/all

In the link above we can see some enlightening metrics on PHP usage in websites:

  • PHP is used by 79.8% of all websites where the server technology is known.
  • The next closest competitor is ASP.Net at 19.8%.
  • Java is seriously trailing in web at 3.5%.
  • Ruby is hardly represented at 0.5%.

NOTE: A website may use more than one technology, so the numbers are not a perfect 100%.

I was a little shocked to see how high the numbers were when I saw them.  I mean, what about github, and Basecamp, and other sites using alternative technologies?  Well, after more thought I realized that while these popular sites do use non-PHP technologies, they are just single sites.  However when taken into account in the scope of the entire web, they only count as one.

Note on limited career moves

Now don’t take what I am saying totally wrong.  I am not so naive to think a web developers cannot survive without PHP in their toolbox.  I realize there are many developers using alternative technologies who have never touched PHP, and they are able to survive.  I am simply saying that if a web developer really wants to do well they will run into PHP more often than not, and it would be a shame if they were not able to play in that ballpark.

The 20.2% of websites not using PHP is still a very large number.  According to Netcraft there are around 672 million active websites at last estimation.  Which means there are around 139 million websites not running PHP.

PHP Versions

To get a little more fine grain, lets look at what version of PHP is being used:

http://w3techs.com/technologies/details/pl-php/all/all

In that link we see:

  • PHP version 5 is used for 97.1% of all PHP websites.
  • PHP version 4 is used for 2.9%

For those still using PHP 4, it is time to make solid plans to get updated.  It has been almost 9 years since PHP version 5 was released.  That is a very long time, and those old PHP 4 sites and applications need to be updated. (Aim for the current version 5.4)

Now within PHP version 5 there are many sub-versions, so to gain more insight into how this breaks down we look at the following link:

http://w3techs.com/technologies/details/pl-php/5/all

So:

  • PHP 5.2 and 5.3 make up the largest share with 93.2% of the overall
  • PHP 5.3 is 49.6%, which I think should be higher
  • Newer 5.4 is very low at only 4.1%.

I was sad to see version 5.3 was not significantly higher than 5.2, but it kinda makes sense.  Because 5.3 was such a drastic change in the object model introducing namespaces, late static bindings, and closure, many developers feel intimidated to update their servers from 5.2 to 5.3 even though the upgrade would most likely not break anything in their code.

I would encourage anyone running their code on 5.2 to try out 5.3 or 5.4 on a “testing” server, then if all is well plan to migrate in production as well.  Then they can take advantage of more speed and include some of the new technologies that came with 5.3 and 5.4 in their code.

We can clearly see how much PHP rules the web space.  But what about elsewhere?

Overall programming language usage

I thought I would share another stat about programming languages as a whole, regardless of where they are used.

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Here we can see PHP still ranks pretty high, and has been holding pretty steady for some time. While PHP rules where it was “intended” to be used (websites), it is versatile enough to still rank high overall.

In closing

So yes, there are many programming languages out there and I encourage all developers to learn as much as they can. But as professionals we cannot possibly learn them all and be good at all of them.  So I say pick one, and learn it very well while still dabbling with others.

There is nothing wrong with building a career around PHP, and it can be quite profitable since PHP is so wide spread.

Above all, live up to the title “Professional Developer” and always strive to learn more. And if you are a web programmer it would be a mistake in your career (in my opinion) not to know the most predominant technology in the space…PHP.

Installing mhash on RHEL 4 and PHP 4.3.9

Recently I had a customer that was receiving errors from an Authorize.Net web submit form in their shopping cart. The error simply stated:

“The gateway no longer supports the requested method of integration.”

While doing some digging I found that they were using a very old web submit method that Authorize.Net no longer supported. There were two ways to fix the problem:

  1. Change to AIM method of submission, which required an SSL certificate that the client did not have.
  2. Change to SIM method of submission, which required either PHP 5.1.2 installed to use the hash_hmac function, or for PHP 4.3.9 it required that mhash be installed on the server.

Since the client did not want to spend the extra cash for the SSL certificate, and I could not install PHP 5.1.2 because I had too many other clients on the server that were not ready for the upgrade, I decided to do some searching for a way to install mhash.

It turned out that the Red Hat repositories did not carry php-mhash for RHEL 4, so this meant I needed to look in other areas. After reading many different blog and BB postings saying that it required an install, then a recompile of PHP I started to get a little worried. I did not look forward to recompiling PHP.

Finally I found some posts that brought a ray of hope. There are RPMs available to install php-mhash without the PHP recompile, but it required that libmhash be installed first. Here are the steps I followed:

  • I went to http://dag.wieers.com/packages/libmhash/ and downloaded the newest version of libmhash for my server.
  • Then I installed using the following to satisfy dependencies of mhash:
    rpm -iv libmhash-0.9.1-1.rhel3.dag.i386.rpm
  • Next I downloaded the php-mhash by using:
    wget ftp://rpmfind.net/linux/sourceforge/p/ph/phprpms/php-mhash-4.3.2-19.ent.2.i386.rpm
  • I followed that by installing it using:
    rpm -iv php-mhash-4.3.2-19.ent.2.i386.rpm

After following those steps I created a phpinfo script to see that everything went well:

<?php
phpinfo();
?>

I could now plainly see that mhash was installed perfectly, and with further tests I confirmed it was working.

Upgraded a server to PHP 5 from PHP 4

Everything went pretty smooth while upgrading a server for a customer. I was moving them from Fedora Core 3 to Fedora Core 4. This also meant that PHP 5 was installed instead of PHP 4, and MySQL 4.1 was installed instead of MySQL 3.23. All was working smoothly except one of the websites on the server was having some major issues. The pages would not display, and $HTTP_POST_VARS and $HTTP_GET_VARS were not working correct.

I did not design the site, so I was not familiar with how the $_POST and $_GET were used within the code. After opening the files I quickly saw the problem. In the PHP.ini there is a new setting that, by default, only looks for the short forms of these predefined variables. In other words, it doesn’t know what $HTTP_POST_VARS or $HTTP_GET_VARS are. But it recognizes $_POST and $_GET with no problem.

After changing the setting in the PHP.ini all is working fine. Luckily the previous programmer did an ‘ok’ job.

The setting in the PHP.ini that needs to change is:

register_long_arrays = Off

This is located in the “Data Handling” section about 1/3rd of the way down the file. (If you followed the default installation of Fedora Core 4.)