April 29, 2007

So Many Untapped PHP Features

Posted at April 29, 2007 06:00 PM in PHP .

I love PHP as a language. It can be used for quick and dirty scripts. Or, you can harness the object-oriented features to make a project very structured. I've been doing the later almost exclusively for the past two years. The reason? I generally find projects are easier to maintain when functionality is encapsulated in classes. You never know when you might want to duplicate something, right? Its basically the list of benefits of object-oriented programming versus procedural.

Anyway, I have my heart set on creating a personal web site with blog, projects list, code repository, etc, much like what my friend Ben has done with www.benchodroff.com. The first step in creating your own web site is deciding what software will power it. I saw Ben was using WordPress. So, I downloaded a copy and glanced at the source. I immediately noticed:

  • No PHP 5 code
  • Similar functionality is denoted by function name prefixes, not encapsulated in classes
  • SQL statements don't use bound parameters
  • Very little distinction between model, view, and controller
  • XML generation is via print() or echo(), not via PHP's XML classes or functions

Many of these immediately triggered alarms. The lack of SQL bound parameters means it is harder to defend against SQL injection. The lack of MVC increases the likelihood of XSS. The lack of class usage means it will take me longer to understand the API. The lack of PHP 5 visibility keywords (private, protected, public), means it will be difficult to ensure forward-compliant code.

After confirming my suspicions of Wordpress's rough history via the National Vulnerability Database, I decided not to take my chances. The software may be easy to use and may work well, but I really don't feel like rolling the security dice. Besides, as someone who loves to evangelize PHP, why should I host my site on PHP software that doesn't utilize about three years of PHP language improvements?

Although I pick on WordPress for under-utilizing PHP, there are countless-- and many of them successful-- projects that do the same. Drupal, which I love because it is one of the few web applications that handles modularization and feature extensibility properly, only utilizes PHP 4 features. Although I love the design philosophy of the software from a 20,000m overview, when you start to hack away, you find that the API is very difficult to understand. There are no classes, so all functionality is provided via functions in the global namespace. And, the include files are named .inc, so Apache will serve the content at plain-text by default, so users can easily see what version you are running and cross-reference against known exploits (luckily a .htaccess is generated that prevents this for many, but not all installations).

Gallery, another commonly used PHP application also fails to fully utilize PHP, although they are more graceful about it. Gallery 2 uses classes for almost everything. Like Drupal, I love their design philosophy of separating features into modules. Unlike Drupal, they take the proper approach and contain similar functionality in classes. Sadly, there are no PHP 5 visibility keywords on class variables and functions, but at least their naming convention distinguishes between public and non-public.

I could go on listing applications with similar behavior, but why waste all day? The more interesting topic is why these applications have not made the jump to utilize PHP 5's features. Others have speculated, and I tend to agree, that application developers are worried that PHP 5 adoption is too low and requiring its use will turn away users. Now, considering the improvements of the PHP 5 engine, both from a performance and security standpoint, there is no reason in my mind why a sane system administrator wouldn't be running PHP 5.2.1 (most recent at the time of this entry). When PHP 5 was released almost three years ago, there was a compelling reason not to upgrade: scripts broke, albeit mostly the ones that were written improperly. Now, very few applications written in strict PHP 4 will break when running on PHP 5. If they do break, chances are they are built so poorly that security holes, not PHP version compatibility, should be a bigger concern.

Now, it is very easy to point to low PHP 5 adoption on servers and take sides with application developers for sticking with PHP 4. But I think there is more to it than just that. After all, if given a compelling reason to upgrade, you'll do it, right? (Sadly, security is not compelling enough to many running PHP 4. Oh well.)

I believe the biggest problem hindering PHP 5 adoption is ignorance. The average PHP "programmer" is ignorant of the features available in PHP. Because the PHP syntax is easy for new programmers to read (at least compared to Perl, C, and arguably Python (note to self, learn more Python) ) and because the barrier to entry for PHP is low (much easier to iteratively develop against a scripting language than a compiled language, such as Java), many PHP programmers learn the language in an informal process. Because of the popularity of PHP, most start learning PHP by examining existing programs. This is how I started (probably trying to get Netjuke to work properly). And, since PHP 4 is still statistically more popular than PHP 5, chances are your first exposure to PHP will be a PHP 4 program. Sure, there are some excellent PHP 5 applications out there (some of the best PHP is, IMO, part of the Zend Framework), statistically, you won't encounter it unless you've been using PHP for a while.

The differences between PHP 4 and PHP 5 are staggering. I consider them to be two separate languages. Therefore, it is of no surprise that the differences between PHP programmers are equally staggering. If you analyze the skills and abilities of PHP programmers and attempt to classify them, you will most likely encounter groups that correlate to the version of PHP they use. The greater the level of PHP understanding, the more likely that person is running the most recent version of PHP.

Although more people deploy than program PHP, we can attempt to infer the percentages of the skill level of PHP programmers by looking at the PHP version distribution. If I were to ask you what percentage of PHP programmers know about, much less use, PHP higher-version features, such as PDO, __call(), SimpleXML, SPL (DirectoryIterator, ArrayObject, spl_autoload_register() ), Filter extension, etc, what would you answer? From personal experience, I'd peg it below 10%. Remember, this is including all people who program PHP, whether it is a project lead working for Zend or some Joe Schmoe who made a module for Drupal. From the version distribution, we look for the upper 10th percentile, which correlates to PHP 5.1.0. Even though this graph maps PHP users, not programmers, I think it is safe to say my estimate is in the ballpark, although it appears to be a little high in terms of percentage. If 10% of PHP programmers used the advanced features enumerated earlier, then more than 10% (or 15% running 5.0.0 or greater) of the servers would have to be running PHP 5. So perhaps a more accurate estimate of PHP programmers who use advanced features is only around 5%? It is hard to say, and the correlation can be thrown off by numerous factors, including servers that don't expose PHP via HTTP headers for security purposes, something the smarter, advanced PHP programmers are probably more likely to do. I could speculate on percentages all day, but you can't ignore that there is a giant rift in both abilities and percentages between the top tier of PHP programmers and the rest. If nothing else, my personal experience can confirm this.

What does all of this mean? It depends on who you are. If you know how to use all of the "advanced" features enumerated above, good for you. You know your stuff and many companies would love to have you on board. If you are wearing a security hat, be worried. Since PHP 4 is missing intuitive features for security best-practice coding (private methods, DB layer with easy-to-use parameter binding (PDO), etc), chances are the PHP programs you have deployed aren't as secure as you would like. I'm not saying PHP 5 is a magic cure-all, just that if you take advantage of its features, programs are more likely to be secure and maintainable. If you need to hire a PHP developer, ask questions about advanced PHP features. Programmers who know that stuff are much more valuable, even if you don't use the advanced features.

What can be done about it? This is a difficult question and it has been addressed by many. To all the application developers out there, I would say to not be afraid of migrating your application to PHP 5. So your users might gripe initially. So it takes a lot of effort. I understand. Just think of it as part of the regular maintenance you perform on any application. If you are going to migrate, my tip is to migrate as part of a complete rewrite. Unless your code base is as well organized as Gallery 2's (you can just drop in private, protected, and public keywords in classes), you shouldn't attempt to migrate. You will just end up with a giant hack (MediaWiki, for example). If you perform a complete rewrite, you can also take advantage of some of the amazing PHP frameworks out there. Zend Framework has already been mentioned, but Symfony deserves a plug as well. If you use those frameworks properly, I guarantee you will get more enjoyment from working on the application then you do now.

If you are newcomer to PHP, I recommend you to NOT learn PHP from existing programs, unless that program is a reputable framework (as mentioned above). These frameworks are varied enough that you can find all common aspects of PHP in them and you will be exposed to proper practices in the process. For language reference, the official manual on php.net is a great one-stop shop. But only use it for quick reference. If you are looking for how to do X with PHP, check out the Zend Developer Zone, or follow the practices encouraged by a framework. (You can tell I really like frameworks, can't you).

In conclusion, there are currently two PHP programmer "camps" that are vastly different in terms of size and skill level. Only a handful of PHP programmers actually use the time-saving (and often security best-practice) features of higher versions of PHP. PHP 5 is not a magic cure-all, however. Bad programmers are bad programmers. I feel that PHP 5 is more conducive to good programming practices than PHP 4. Unfortunately, PHP newcomers are more likely to be initially exposed and hooked to the PHP 4 mentality. Furthermore, there are few resources available that encourage and evangelize PHP 5. Until this changes, I don't see PHP 5 mass adoption happening any time soon. The silver lining in all of this is that hiring PHP developers is relatively easy, as a candidate who knows how to used advanced PHP features is probably head and shoulders above every candidate that doesn't.


You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/12853 .


Buddy, did you ever write or support a commercial script, or free script for masses? I see you did not.
If you'd do that, you would be shocked how many webhosts still use PHP4, and how many potential clients would prefer to choose another script instead of transferring to new hosting.

Posted by Alex at April 29, 2007 06:44 PM

The lack of PHP5 usage is really annoying.

There is no reason to stay with PHP4... however so many people do. Part of the reason i think this is the case is many PHP 'programmers' are (hence the quotes) not programmers. They come from a design background or something else and hack away at code until they get what they need. They are not disciplined in the programming arts as I like to call it. OO theory and so on.

They worst part is when you come across this code and need to work with it.

Posted by Dougal Mathews at April 29, 2007 06:55 PM

In response to the first comment:

1) Yes, I have written PHP scripts for the masses. The ones associated with my name are usually free. A simple web search will reveal this.

2) I am not shocked how many hosting providers still use PHP 4. The statistics linked in this post show the current overwhelming majority of PHP 4.

3) If people need to transition hosting to use PHP 5 apps, that is their problem. Personally, I only trust hosting to myself. Unfortunately, not everybody has the luxury of running their own hosting environment. I don't disagree that finding PHP 5 hosting can be difficult though.

Posted by Gregory Szorc at April 29, 2007 06:55 PM

response to these:
* No PHP 5 code
-Not all hosting using PHP 5 and that's it. This system is build for 99% of the people.
* Similar functionality is denoted by function name prefixes, not encapsulated in classes
-Umm...what's wrong with no classes? I don't see the reason of making a static class just for the functions.
* SQL statements don't use bound parameters
-right about that
* Very little distinction between model, view, and controller
-There is more than one pattern in the world... not everyone should be using MVC for everything
* XML generation is via print() or echo(), not via PHP's XML classes or functions
-First, it's some capability issues...
2nd.. it is faster.

I believes go with the newest technology does not result the best program

Posted by Mgccl at April 29, 2007 07:32 PM

http://asmallorange.com ... PHP 5 hosting, reasonably priced, with excellent tech support.

Posted by Matthew Turland at April 29, 2007 08:25 PM

Hrm, my only comment is the mention CakePHP's PHP4 support.

Not to say that it's bad software, but it's still "software that doesn't utilize about three years of PHP language improvements". It has, however, utilised recent philosophies and design principles. I guess if you *have* to code with PHP4, then use something like Cake or Code Igniter. Personally, I'll stick to PHP5 with symfony any day.

Posted by Joshua May at April 29, 2007 10:31 PM

Opps! I thought Cake was PHP 5. Since it doesn't fit into the whole theme of the post, I have removed mention of it. This isn't saying CakePHP or any other PHP 4 applications don't get the job done, however.

Posted by Gregory Szorc at April 29, 2007 11:56 PM

My personal preference of PHP5 frameworks is eZ Components.
What makes me wonder is the low awareness of the components which is antiproportional to its quality. There are many mentions of ezc in the PHP media and eZ Systems is a big number in the PHP world.
So how does it come, for example, that you've not tried them yet?

Posted by Thomas Koch at April 30, 2007 06:53 AM

Greg, excellent post and I agree with you on nearly all of it, but I am curious to your reasoning behind this statement: "The lack of MVC increases the likelihood of XSS."

Using a View pattern doesn't do any specific thing to decrease the likelihood of an XSS vulnerability sneaking into your code. It could be argued that the vulnerability is lessened by someone who's implementing that sort of a pattern simply because they've probably spent more time working on their craft and know a thing or two about best practices in general; but in this case the pattern just gives a clue to the probability of an XSS attack, not an indicator as to whether it actually exists.

Regarding the PHP 5 upgrade, this is a classic catch-22. The vast majority of coders (not programmers) out there really don't care about the technology powering their site. They want something that works and they can tinker with. If it is provided by PHP 5, then that's what they would use, but currently this need is filled by programs written in PHP 4. Programmers, such as Alex above, continue to cater to PHP 4 as that's what the users are using, but if the programmers started delivering code in PHP 5 the coders would switch.

Posted by Travis Swicegood at April 30, 2007 11:29 AM


My passage on MVC and XSS is a little unclear. The angle I was going for was that by separating out the view into a separate, independently maintained component (via individual template files, for example), it is easier to audit all content that goes to the browser and thus easier to identify variables that are not escaped, etc. When you have your print or echo statements sprinkled throughout the business logic, it is almost impossible to trace the source of every line of output. The same logic can be applied to input validation.

I also completely agree with your observation that patterns are not sufficient indicators of proficient code. Oftentimes, people throw around patterns as buzzwords and magic cure-alls, and that just irritates me. You can have a separate view component all you want. It only takes one unfilted or unescaped variable to create a possibility for XSS.

Posted by Gregory Szorc at April 30, 2007 12:02 PM

Hi, Gregory. I'm the founder of the Gallery project and one of the main developers on Gallery2. I feel your pain, but I think that it's important for you to draw the distinction between creating a product and a service.

When you're building a service, you have near total control over your environment and you can choose to optimize in a variety of ways. The version of the language that you choose to use is a huge factor. At that point, you may not be deciding between PHP4 and PHP5, you may be thinking of using Java for it's fantastic refactoring tools like IDEA and Eclipse. Or you may be optimizing for an environment that gives you more persistence across requests (easy with Java, maybe you want to use memcached with PHP). In my day job, I work on a highly specific HTTP-speaking application that's written in C++ for flat out speed. In the service market, you get to make these decisions.

But in the product market, you can't afford to make those decisions. If you choose a platform that < 80% of your customers use, then you lose customers linearly. We keep a careful eye on those stats. Here's a recent post on this topic I made to our development mailing list about 3 weeks ago, drawn from the same stats:


If those stats are accurate, then PHP5's market penetration is 16%! We cannot afford to put out a version of our product that is so poorly supported.

Gallery2 simulates exceptions with return calls and error checking. Last time I checked this was roughly 4% of the code. I would *dearly* love to delete 4% of the code and use the much more efficient exception handling in PHP5. I'd love to actually be able to mark our variables private and our helper methods static. Unfortunately, as soon as we start doing any of that, we no longer support PHP4 and are up a creek.

I agree that if there's a compelling reason, people will switch to PHP5. But we are not willing to be a compelling reason all by ourself. We fear that we'll wind up only running on

I propose this solution: Gallery, Drupal, WordPress, etc -- we band together and form a coalition. We make a highly publicized deal that we are only going to support PHP5 starting with our next major release (say January 1, 2008). We give all major ISPs warning that their customers are going to be very unhappy if they are unable to run these popular applications. I think that if we get enough projects to join in, we can achieve critical mass to demonstrate to ISPs that moving to PHP5 is now a necessity and that they will lose customers to other ISPs if they don't get moving.

Posted by Bharat Mediratta at April 30, 2007 02:14 PM

Another Gallery developer here, but I choose to speak primarily from my day-job perspective where I work very extensively with XML in PHP.

Your (seeming) assumption of "it's there, so it must be used" is flawed. There many are reasons why people choose not to use PHP-internal functionality. As others already covered, version support is a very big reason. The biggest reason other than that is that some of PHP's functionality is severely impaired and/or flawed in its design.

"SimpleXML" may be simple to plug in, but it's exceedingly difficult to code to. SimpleXML is just a front-end for PHP's regular XML engine. PHP's XML module sucks. Flat out. It's unwieldy and unyieldingly strict. Much like SMTP, in XML (and more specifically RSS) you need to be incredibly lax in what you accept and strict in what you produce. The XML module is like a catholic school teacher with a ruler in one hand and a switch in the other; ready to dole out punishment for the slightest error.

We chose to write a custom XML processor and spent considerable time and effort to do so based on many technical and business decisions.

Posted by Jay Rossiter at April 30, 2007 02:39 PM


I am intrigued by your comments regarding PHP's XML module. Could you be more specific on why you believe the XML module "sucks flat out?" Is it a problem with the underlying library (LibXML), PHP C-level interface to LibXML, or the PHP-land interfaces (SimpleXML, DOM, etc)? If the latter, is the problem in the C implementation or on the PHP side? How exactly is the implementation "unyieldingly strict?" Isn't XML supposed to be strict by definition? The spec clearly states that XML processors MUST report violations of well-formedness. I'd argue that if parsers weren't strict, then people wouldn't have an incentive to produce proper XML and we'd be in the same boat we are in now with HTML.

Also, which parts of the XML module are unwieldy? 80% of the time SimpleXML works great for me. For the rest, I can usually use DOM, which is definitely cumbersome to use, but gets the job done. And, if neither of those work (I am reading a really large file, for example), the expat-based event-driven parser does the trick.

Posted by Gregory Szorc at April 30, 2007 10:40 PM


I haven't dug that deeply into the libraries used. I have a C/C++ testing and development background, but it's been several years since I've really used it.

I will elaborate on my statements. The XML module doesn't "suck. flat out" for every purpose. My main consideration for this statement is that I work with user-input generated by any number of malformed scripts, both commercial and open-source, or Joe Blogger's homebrew/hand-coded XML.

I live in the world of RSS. RSS data is badly formatted on its /best/ days. On its worst, it's simply unparsable, even by hand.

SimpleXML will silently strip pieces of user-data that it feels are invalid. For instance, a CP1252 ndash character (HTML Entity #151) in a UTF-8 XML document (not inside CDATA). Even better, the same character in binary (non-encoded) causes a fatal processor error which causes SimpleXML to fail (silently, no less).

The file is unreadable to PHP XML. There is no recovery method. Even using the raw XML subsystem doesn't allow recovery from this error as it occurs before the data is even handed off to the user's defined functions.

Like it or not, users insert invalid data in XML. I hate it, to be sure, but no one who is in a customer-driven industry can lay down the law and refuse to process that invalid content, because invalid content makes up _most_ of the content out there. Not Google, not Pheedo, not FeedBurner...

Hence my comparisons to SMTP.

Other issues which make dealing with XML difficult using PHP - namespaces. SimpleXML's support is nearly non-existent. You simply have to resort to DOM and Xpath.

SimpleXML's handling of CDATA leaves a lot to be desired. Unless you have spent a lot of time dealing with it (and possibly ripping your hair out), you simply don't know that you have to cast the SimpleXMLElement object as a string to see the contained data.

So - I will amend my statement. PHP's XML processing works, assuming you are using strictly validated documents. Most people just don't have that luxury.

I'd be glad to continue this in email, if you'd like.

Posted by Jay Rossiter at May 1, 2007 03:00 AM


Thanks for responding. Those are interesting points you made about SimepleXML stripping parts of XML. I can't say I've ever encountered them, but then again, I haven't used SimpleXML for that much processing of RSS or ATOM. I'll definitely take a look though!

I agree with you wholeheartedly about namespaces and SimpleXML. I bet at some point the PHP developers had a discussion of where to draw the line for the "simple" XML interface and namespaces support was very close to it. I too have torn out my hair on a few occasions trying to get it to work as I wanted.

It is unfortunate that we live in a world where all XML isn't well-formatted. An interesting question is raised: who is to blame? Do we blame the browsers and XML consumers for parsing invalid XML? Do we blame application developers for not providing robust enough XML generation? Do we blame programming language support for not making it simple enough to generate XML? Do we blame everybody for not providing adequate tools to validate XML?

The finger pointing exercise outlined above could go on forever. To top it off, there is no solution that appeases everybody. Personally, I try to abide by the specifications set by the standards bodies and encourage others to do the same. But in a customer-driven world, as Jay pointed out, this would sacrifice the well-being of the customer, and that is a very difficult pill to swallow.

Thank you for responding, Jay!

Posted by Gregory Szorc at May 1, 2007 03:33 AM

"[...] considering the improvements of the PHP 5 engine, both from a performance and security standpoint, there is no reason in my mind why a sane system administrator wouldn't be running PHP 5.2.1 [...]"

You clearly have no experience working with commercial web hosting providers. ;)

I can speak with authority on this issue. I worked for a commercial web host for three years. Servers hosting customers, once installed, are *never* upgraded to non-bugfix versions. Never. Never ever. Why? Because every time you do, you break someone's site, and get whined at.

I can think of a prime example. In addition to coding, my employer also sold commercial software that could run anywhere, written in Perl and PHP. When PHP5 was released, we had a grand total of two adopters in the course of a year. We know this because only two people ever complained about a bug our software had that only manifested in the then-current version when run under PHP5. While we fixed the bug immediately, there are still hundreds of instances of this old, buggy software out there that would break when the host upgraded the system software.

This goes beyond just buggy end-user software. We never, ever trusted PHP in-house. It seemed so early on that every other release not just introduced new features, but broke old ones, and seemingly silently changed behavior on others. How were we supposed to trust any point upgrade to not destroy our customer's sites?

Only very small hosts, and very intelligent, competent hosts can get away with system-wide upgrades, because they can have the time and resources to ensure that their customers won't suffer. The vast majority of hosting providers fail to fall under those criteria.

Until PHP5 is out there in the wild, there is no way that any project that wishes for their software to be usable by the masses can get away with using PHP5-only features. It's that simple.

And that won't happen until hosting providers begin migrating to new hardware and installing more up-to-date distributions by default. Those distributions are only now being released -- RHEL5, for example, includes PHP 5.1.

Realistically, we might see 50% market penetration of PHP5 within a year or two, but PHP6 will be out by then, and the cycle begins again.

Posted by Charles at May 1, 2007 01:18 PM

I find this post particularly interesting as a someone who has been trying to find a developer to hire to write an application (service) in pure PHP5 using all of its OO'ness. Whilst some have come back to me with "I think I can do that", many have replied to the project brief with "I don't really see the value in OO/PHP5", or some variation on the theme of why there's really no need to go overboard. Could it be that there is not only an issue of market penetration of PHP5 hosting etc, but also a shortage of people to write pure OO PHP5 code?

Are they mutually exclusive??

Posted by CantFindCoders at May 1, 2007 04:16 PM


I would agree with your statements, however I would disagree in one way. Many (larger) hosts offer the ability for the user to choose whether they would like to run PHP4 or PHP5 via control panel. Since secure webhosts are generally running php-cgi, it's easy for them to allow this per-user configuration. Some hosts will go so far as to relocate your pages to dedicated php4/5 servers if you want to use one or the other.


It's definitely true that a lot of people refuse to go to the 'effort' of making OO PHP code. It's not universally true, however. Both in Gallery and in my day job we use OO code primarily. While Gallery's code doesn't necessarily follow complete OO due to the PHP4 compatibility requirements, it's as close as it can get.

For some projects, full-blown OO is unnecessary. We are dealing with, for all its complications, nothing more than a scripting language. There's nothing wrong with procedural code if it gets the job done effectively.

Posted by Jay Rossiter at May 1, 2007 04:52 PM

Hmm. I'm trying to do something similar, creating a site from scratch and all. I've always tried to think towards the future while supporting the present. In part because my web host hasn't switched to php5 yet. In any case, I didn't realize that so many hosts weren't supporting it.

Posted by cocoliso at May 1, 2007 10:41 PM

I have not found anything more stupid, heavy and inflexible than drupal, you shouldn't have said you love it :). Don't use it, it is some mistake in my view. Real programmers always write their code on their own without using any bullshit. For an year and counting I have been developing my own framework in php5 and I'm really happy with its speed, productivity and scalability. Its resembles a C++ program, fully MVC integrated, and completely OOP designed. I still have a lot to add to it, but even at that stage it is working right for me.
One piece of advise: Write on your own - it's the better way ;)

Posted by Emo at May 2, 2007 04:24 AM

First of all.Why abstract since you really didn't need one.Why everything you must put in class.To me class are for reusable.This is not java or vb.net application.The truth fact why php are famous you can do procedural or class for reusable object.Look again at VB.net lalal friend final or so whatever.When your customer find you.Did you have the time to write final,friend or your job becomde 3 years coding classes or 6 month delivery by combining procedural and classes together.

Posted by hafizan at May 3, 2007 03:06 AM

What was the uptake from PHP3 and PHP4? Much much faster than the uptake from 4->5. What are the factors impeding PHP5 adoption?

I submit three reasons:

1. No way to run both versions at the same time. Perhaps if there was a standard way of running both PHP4 and PHP5 together (as modules) in the same Apache instance (as there was for PHP3 and PHP4) the adoption rate would have been much higher. Developers would have been able to migrate their code over slowly, testing out new features without sacrificing backwards compatibility. Expecting people to set up proxying or to run mod_php and php as cgi as workarounds to this migration problem *obviously* has not worked.

2. Functionality. 4 offered a lot of extra functionality over 3, and there were few breaking changes upgrading to 4. 5 offers more functionality over 4, but at the expense of backward compatibility, even (especially?) within just the 5 series. The 5.1 'date' fiasco and 4/5 DOM changes are just a couple examples of the perceived instability of 5. 4 had some of these issues as well, and already made people wary of the backwards compatibility issues with PHP - the 5 issues exacerbated the issue. I was just recently told about a behaviour change in the PHP5 series with strtotime - "Returns a timestamp on success, FALSE otherwise. Previous to PHP 5.1.0, this function would return -1 on failure.". There have been dozens of small changes like these over the years, many of which were undocumented or underdocumented, which doesn't help the image of PHP as an 'enterprise' (or even 'stable') platform.

3. Size of community and projects. There are vast numbers of more people depending on PHP these days than there were in 2000, and often their needs are business oriented and have a lot of time and money invested in operating platforms. "If it ain't broke, don't fix it" springs to mind in many cases. For individual developers wanting to add blog plugins, wanting to use PHP5 may be understandable. For companies running millions of dollars on a PHP4 platform, upgrading to PHP5 is a daunting task not to be undertaken lightly. I'm not saying there's no benefits to upgrading, but there's much more at stake, and the process needs to be approached with more caution. There are still many shops running Java 1.4 in production, and Java has far fewer backwards compatibility issues than PHP has.

Posted by Michael Kimsal at May 3, 2007 09:09 AM

I believe http://api.drupal.org/api/5/file/developer/topics/oop.html would be a good read for you.

Posted by chx at May 6, 2007 12:42 PM

I create a lot of sites and without php knowledge it is a challenge - I dont even know what I am missing and am reliant on 'for sale' scripts. I am going to give Teach Yourself PHP 4 in 24 Hours 2000 a shot and hope its worth it.

Posted by martial at May 6, 2007 05:13 PM


Posted by ???? at May 8, 2007 05:00 AM

lcgw samz icxtg zalcwgxfy uvhd spryz uwkea

Posted by swthvrp derzukos at May 12, 2007 04:42 PM

lcgw samz icxtg zalcwgxfy uvhd spryz uwkea

Posted by swthvrp derzukos at May 12, 2007 04:42 PM

I love PHP as a language but 5 is a crap. I have many problems with server using php 5 :(

Posted by Gsm Games Maniac at May 13, 2007 06:22 AM

That's right - i have many problems with php5 to, so i use php4 :)

Posted by Logos at May 14, 2007 05:53 AM

I create a lot of sites and without php knowledge it is a challenge - I dont even know what I am missing and am reliant on 'for sale' scripts. I am going to give Teach Yourself PHP 4 in 24 Hours 2000 a shot and hope its worth it.


Alternative Medicine

Posted by alternative medicine at May 14, 2007 01:54 PM

Most of my websites are php also and seems that even the search engines like them that way as well as having css. Anyway your website you made with it looks very nice.

Posted by social network at May 16, 2007 01:11 PM

I know for a fact that PHP4 is better (at least at this time) until all of the bugs are worked out of PHP5. Just like any other script, software etc. it takes time to work out all the bugs. As of right now our website contains about 800 professionally designed and written PHP scripts however even our programmers, coders know that majority of the scripts will work the best with PHP4. That is not to say that we dont have some that will work with both however usually coding or "tweaking" them to work with both costs us too much development time.

So, for now. IMHO stick with PHP4 until all the bugs are worked out of PHP5, then go for it.


Posted by PopScript at May 18, 2007 02:44 PM

Davenport Vacation Rentals
wants to wish you all a great year. We love the school and the blog.

Posted by Davenport Vacation Rentals at May 19, 2007 03:35 AM

I have almost 15 sites all on php, mysql basically it is so simple also there are tons of resources for php and mysql on internet.

Posted by Affordable web hosting at May 24, 2007 11:43 AM

Post a comment

Remember personal info?