Nick Lewis: The Blog

@tie: about your comment: [...]Imagine the customer reaction when their PHP apps start breaking. When the shopping carts, and the CRMs stop working, because their developers have not yet released a PHP5-compatible version.[...] Could this be true? I will ask my hosting/provider firm if our online shops can be in trouble soon.

I totally agree with you.

Lovely article. Personally, I use PHP(5) for most of my projects, but I've been stepping into the RoR fields ever so slowly... TDD and the "ruby thinking" is new to me, so.. still not making any major projects in it, but.. :)

Upgrading isn't always bad, and I'd like to see some internal rewrites of Drupal code, even if tit makes it non-backwards-compatible.

_________
project honeypot

As usual, let me speak as a corporate/enterprise Drupal user.

We no longer support or develop for PHP 4. We also want to discontinue MySQL 4.x.

We especially want to leverage the features of PHP 5 and MySQL 5 with Drupal. Supporting older versions in Drupal core is a drag on future development. (We'd like to drop Apache 1.3, as well, but that's another issue.)

The support for PHP 4 is an issue for folks who don't own/run their own servers. The question is: which user base is more important? That's a tough question, but I'd agree with Rasmus' point at OSCMS that if the developers move to PHP 5, the shared hosts will as well.

FWIW, we also have a core Joomla! developer (Jonah Braun) on staff, and he is very interested in this topic. The Joomla! community is facing the same issue. Jonah asked if we might be able to coordinate Joomla/Drupal releases to both drop PHP 5 at the same time.

The logic here is that both projects fear losing users/developers if one drops PHP 4 and the other doesn't. So it might make sense to coordinate that specific versions of each will drop PHP 4 support.

I would even be so bold as to say that we should drop php5 for Drupal 7. I think your estimate for Drupal 8 landing in a year to 1.75 is unrealistic. I can't see Drupal 7 landing any earlier than Feb/Mar next year. If we are making Drupal 6 to run faster, and have more features on php5 than on php4, it would be fair to take the next step in Drupal 7 and drop php4 completely.

I'm sorry, but I find this whole situation a bit silly, from the perspective of an open source CMS developer.

One thing that's been thrown around a lot is that most PHP developers are not 'smart enough' to use more advanced PHP5 features and/or that they are lazy to convert their code. Especially outsiders poke easy fun at projects like PHPMyAdmin, that are widely deployed, but contain some truly horrifying code (3+ line global statement in a 700+ line function).

But what does PHP itself offer? Very little. Huge parts of PHP are bizarre, mutant interfaces which have gaping holes in some places, but contain oddly specific algorithms elsewhere. The String API is a perfect example... And if you want to do image processing, you better check for the availability of each external library you use and get ready to do some heavy lifting yourself. What the language does offer is wrapped up in confusing, inconsistent function names in a flat global namespace. Is it any wonder that the average PHP programmer doesn't aspire to improve their code?

Even more noticable is that large open source projects (like CMSes) each have to reinvent the wheel for features that are essential today. And even plug-and-play libraries like MagpieRSS have to come with their own cache and database back-end, to be useful. There is very little code re-use out there too, because too many basic functions are different in each platform.

There is very little happening to improve this situation. There are code repositories like PEAR and PECL, but in reality open source projects simply cannot use them. Their average user will either have a hard time installing such extensions, or will simply be unable to do so due to host restrictions. You often need to fiddle with php.ini and include paths.

PHP's efforts in this area are remarkably unambitious, and we find that years after we started making PHP applications, people are still having the same problems.

In Drupal, we noticed that designers were having problems coming to the platform, and we changed that significantly in version 5, and even more in 6. Less technical PHP knowledge is required to create themes, and Drupal is smarter in picking up templates automatically. We worked hard on this, and I think it will pay off well. PHP can surely make similar efforts to improve the quality of PHP as a platform, encourage better code, more re-use, etc.

What is worse though, is that the PHP team's ambitions in general are just low. Sure, PHP5 was a nice upgrade, and offered some sorely needed improvements (e.g. XML). But the majority of PHP code today still looks the same as before. Where is the stuff that really takes us to new places?

Libraries like jQuery are bringing waves of innovation, but can only exist in languages like JavaScript, where the programmer can alter the behaviour of pieces of the language to suit their purpose.

I experienced this myself when I ported jQuery's CSS selector parser for fQuery. The PHP version was more verbose and not as elegant. Also, in spite of PHP5's reference improvements, you still can't do the following: <?php foreach (my_function() as &$value) {} ?>

Heck, in PHP, you can't even redefine a function. And I recently asked Rasmus himself whether PHP would ever have closures (like JS), and he said he thought it was very unlikely, because most PHP users would not use them. In my opinion, that's short sighted: adding a functional flavor to the language is sure to open up cool new possibilities. It would make PHP more attractive in the eyes of the academic/comp-sci crowd and would steal some of Ruby's thunder too.

When will we see statements like foo = o.value || 'default value' in PHP?
Will we ever be able to change Form API to use SimpleXML's faux object/array mix syntax?
Will we ever get named function arguments?
How about string range subscripts like $string[0..-1] or $string[$begin..$end]? Same for arrays?
Will they ever add a native syntax for regular expressions that doesn't require quote escaping?
Will preg_replace/e ever be fixed?
What about arrays defined with [] rather than the bulky array(), which you can index immediately?
e.g. ['foo' => 'You chose foo', 'bar' => 'You like bar'][$var]
How about exposing information about ongoing file uploads through the session object, so you can perform parallel polling requests through AJAX?

The list goes on and on and on. As a platform, PHP is looking dated. Sure, we can slowly creep towards PHP5, but it only offers relief in some small sore spots. On a grand scale, Drupal will keep having to do what it always does: wrap native APIs to fix bugs, provide abstraction and unification APIs and generally cram a whole lot of concentrated ass-kicking in code that's slowly, but surely creaking at its seams.

PHP6 is a small twinkle on the horizon: proper Unicode support could convince some people to switch and can be used to make things like locale cleaner. However, since it needs to be enabled server-wide, it's probably going to be defaulted to off for quite some time, and we'll have just another flavor to support: PHP6 without native unicode (but with some extra APIs).

In light of this whole situation, I find the suggestion from the PHP team that open source projects drop PHP4 support a little arrogant and hypocritical. We're not about to drop a significant portion of our audience: that's the same argument they use for maintaining security patches for PHP4. If newer PHP versions can offer killer functionality, that makes life easier for everyone involved in the LAMP stack, it'll be much easier to convince hosts and users to upgrade.

PHP5 is like IE7: it improves things in a way that is badly needed, but in the end, it's still not that good, and you still have to support IE6 anyway.

+1

You speak well! I agree with you to 100%, and sincerely hope that we all in the Drupal community will listen to reason and drop support for PHP 4.

I never really understood why it's imperative to stick with php4, after all if Drupal N goes php5 only and you absolutely need php4 you can still use Drupal N-1. Maybe those interested could provide security support for Drupal N-1 for an additional lifecycle.