PHP

PHP Foundation launched

Mon, 22 Nov 2021 15:47:44 -0500

There is a common misconception that large open source projects are well-funded. In practice, many rely on a small group of maintainers.

The PHP programming language is one of them. Despite being used by 75%+ of the web, PHP only has a few full-time contributors.

That is why the PHP Foundation is launching. Its mission: The PHP Foundation will be a non-profit organization whose mission is to ensure the long life and prosperity of the PHP language..

Acquia is proud to support the PHP Foundation by contributing $25,000 to the foundation, alongside Automattic, JetBrains, Laravel and others. Our donations will help fund the development of PHP.

PHP is vital to the functioning of governments, schools, non-profits, private companies, public companies, and much more. If your organization relies on PHP, I'd encourage you to make a contribution.

Large open source projects like PHP need meaningful, long-term support. I remain very passionate about how to make Open Source production more sustainable, more fair, more egalitarian, and more cooperative. It will be interesting to see how the PHP Foundation develops.

The end of PHP 5

Thu, 08 Nov 2018 18:19:13 -0500

PHP, the Open Source scripting language, is used by nearly 80 percent of the world's websites.

According to W3Techs, around 61 percent of all websites on the internet still use PHP 5, a version of PHP that was first released fourteen years ago.

Now is the time to give PHP 5 some attention. In less than two months, on December 31st, security support for PHP 5 will officially cease. (Note: Some Linux distributions, such as Debian Long Term Support distributions, will still try to backport security fixes.)

If you haven't already, now is the time to make sure your site is running an updated and supported version of PHP.

Beyond security considerations, sites that are running on older versions of PHP are missing out on the significant performance improvements that come with the newer versions.

Drupal and PHP 5

Drupal 8

Drupal 8 will drop support for PHP 5 on March 6, 2019. We recommend updating to at least PHP 7.1 if possible, and ideally PHP 7.2, which is supported as of Drupal 8.5 (which was released March, 2018). Drupal 8.7 (to be released in May, 2019) will support PHP 7.3, and we may backport PHP 7.3 support to Drupal 8.6 in the coming months as well.

Drupal 7

Drupal 7 will drop support for older versions of PHP 5 on December 31st, but will continue to support PHP 5.6 as long there are one or more third-party organizations providing reliable, extended security support for PHP 5.

Earlier today, we released Drupal 7.61 which now supports PHP 7.2. This should make upgrades from PHP 5 easier. Drupal 7's support for PHP 7.3 is being worked on but we don't know yet when it will be available.

Thank you!

It's a credit to the PHP community that they have maintained PHP 5 for fourteen years. But that can't go on forever. It's time to move on from PHP 5 and upgrade to a newer version so that we can all innovate faster.

I'd also like to thank the Drupal community – both those contributing to Drupal 7 and Drupal 8 – for keeping Drupal compatible with the newest versions of PHP. That certainly helps make PHP upgrades easier.

Why the big architectural changes in Drupal 8

Mon, 09 Sep 2013 13:33:02 -0400

There has been a lot of chatter about Drupal 8. Will Drupal 8 be performant? Will Drupal 8 be easy to develop modules for? Will I have to learn Symfony? I want to address these concerns and explain why Drupal 8 introduces such big changes.

Lessons from the past: the pain before the gain

The reason Drupal has been successful is because we always made big, forward-looking changes. It's a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.

The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to this change. I first wrote about it in 2006 when trying to get Drupal 4.7 released:

So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off.

We decided that big changes were required

Drupal 7 is a fantastic CMS, but at the same time there are some fairly big limitations, including an incomplete Entity API, a lack of separation between content and configuration, leading to deployment challenges, a lack of separation between logic and presentation in the theme layer, and more. We created solutions for those challenges using contributed modules, but those solutions were in many cases incomplete. In Drupal 8, we decided to tackle a lot of these problems head-on, through the Configuration Management Initiative, the Twig templating layer, and a complete Entity API.

The web landscape has also dramatically changed around Drupal since January 2011, when Drupal 7 was released. Mobile browsing is ubiquitous, and so are third-party services that people may want to integrate their Drupal sites with. Web site users expect a much higher bar when it comes to ease of use. We anticipated these trends and as a result, we spent the past 2.5 years working on Drupal 8's mobile features and user experience improvements.

But are all these great improvements enough?

We need to modernize Drupal 8

One of our biggest challenges with Drupal, is that it is hard for organizations of all sizes to find Drupal talent (developers, themers, site builders, etc). Drupal 7 didn't address this problem (e.g. we held on to procedural programming instead of object-oriented programming), and in fact made it a bit worse with the introduction of even more "Drupalisms" (e.g. excessive use of structured arrays). For most people new to Drupal, Drupal 7 is really complex.

The most effective way to address the Drupal talent issue, as well as the complexity issue, is to bring Drupal in line with modern frameworks and platforms, so there is less Drupal-specific knowledge to learn in order to become proficient. We decided to adopt modern PHP concepts and standards, object-oriented programming, and the Symfony framework. While a lot of the Drupal concepts (Fields, Views, Entities, Nodes) continue to exist in Drupal 8, they are now implemented using object-oriented programming design patterns.

The advantages and disadvantages of object-oriented programming are well-understood. The disadvantages are size, verbosity, the amount of work it takes to write (including the design planning that goes into it) and slower performance. For people new to object-oriented programming there may be a steep learning curve; some of the key programming techniques, such as inheritance and polymorphism, can be challenging initially. The advantages are encapsulation (both to hide implementation details and to avoid tampering with internal values), faster development thanks to re-use, extensibility, and better maintainability. Compared to procedural programs, object-oriented programs are easier to maintain, extend and refactor. So although a lot of work is spent to write the program, less work is needed to maintain it over time.

For Drupal 8 this means that the code will be more abstract, more verbose, and slower, yet also be more maintainable, more modular, and more accessible to non-Drupal developers. The end result is that Drupal 8 should help us attract new people to Drupal in a way Drupal 7 didn't.

This is exactly what happened with other projects like Symfony; Symfony 2 was a complete rearchitecture of Symfony 1. A lot of people were alienated by that, yet at the same time Symfony 2 took off like a rocketship. The same thing has happened with the major releases of Drupal as well, despite how much change each one brings.

Change is scary for the existing Drupal developers

However, as we get closer to the release of Drupal 8, existing Drupal developers have become increasingly aware of the massive changes that Drupal 8 will bring. This has resulted in some fear; some people feel like they have to re-learn everything they know, and that developing for Drupal 8 has changed to the point where it's no longer fun. This fear is completely understandable. Change is hard, it can be scary, and often takes a long time to be absorbed.

But even if we completely streamlined the Drupal 8 developer experience, Drupal 8 will still look and work radically different under the hood. As mentioned, there are advantages and disadvantages to object-oriented programming and modern design patterns. But if we care about the long-term success of Drupal, we can't preserve the past. The risk of sticking with the old Drupal 7 architecture is that we won't be able to attract many more Drupal developers, and that over time, Drupal will become the odd one out.

There is a lot of work left to be done

Part of the fear out there is well-founded because in the current state of development, Drupal 8 isn't good enough. While there are many things to like about Drupal 8, I'm also the first to admit that we have work to do on the Drupal 8 developer experience (as well as performance) before Drupal 8 can ship. Creating a well-designed object-oriented application takes more time and design work than creating a procedural one. Some major improvements have already landed, but we're still working hard on improving the developer experience. We need more help, especially from Drupal 7 developers, on how we can make Drupal 8 more approachable for them. I'm not afraid to make major API changes if the developer experience improvement is suitably large. So if you have concerns about Drupal 8, now is the time to step up and help. In return, I promise we'll work on Drupal 8 until it is ready. Thank you!

Staking our future on PHP

Mon, 11 Apr 2011 11:22:32 -0400

I believe that the growth of PHP depends increasingly on applications like Drupal, Joomla!, WordPress, phpBB, Typo3, ezPublish and similar systems. Specifically, I believe that most organizations adopt PHP primarily because they want to use one of these popular applications which have PHP at their core. Fewer organizations adopt PHP because they want to build from scratch their own PHP applications. Hence, more than ever, the future of PHP depends on popular PHP applications that have emerged over recent years.

Conversely, the future of Drupal depends on PHP. Moreover, many of us are staking our future, and that of our businesses, on Drupal and, by extension, on PHP. The same is true for those who make their living with Joomla!, WordPress, phpBB, vBulletin, Typo3, and ezPublish.

It seems that we have arrived at a point in which there is a symbiotic relationship between PHP and the most popular PHP applications. A relationship that did not exist when PHP was created. Symbiotic relationships are obligatory: we depend entirely on each other for survival. And yet, I feel like we've been living apart. It makes sense for us (i.e, application developers) to contribute to the development of PHP, and for the PHP core developers to work more closely with the developers of the most popular PHP applications.

Having spent ten years of my life developing Java Virtual Machines and run-time systems, I feel that I'd be able to contribute to PHP. Unfortunately, I don't currently have time for it. Maybe when Acquia is a bit larger, we'll hire a full-time engineer to contribute to PHP's development. Maybe other organizations will consider doing the same, or more people will find the time to be active in more than just one project. It seems as though our future would really benefit from such people.

If you could contribute to PHP core, what would you change?

PHP4 is dead ... or maybe not

Fri, 08 Aug 2008 17:56:51 -0400

It is 08/08/08 today. The day they took PHP4 behind the barn and shot it through the head. The date of the official discontinuation of PHP4 – even for security issues.

Unfortunately, as I predicted in April 2007, PHP4 is still more widely used than PHP5 is. According to the latest Nexen data, PHP5 has only a 33% install base after more than four years.

Drupal's success depends on that of PHP, and PHP5's slow adoption rate has certainly been annoying. Hopefully, we can all move forward together now. Drupal is ready for it.

If you still haven't upgraded to PHP5, today would be a good day.

PHP is dead ... long live PHP!

Tue, 08 May 2007 06:46:38 -0400

People are getting increasingly worried about PHP5's adoption rate. And rightly so. PHP5 has been released more than two years ago. If you look at the adoption rate in the graph below, you see that after more than two years, PHP5 commands for less than 20% of PHP's install base. With the current adoption rate (even if it is assumed to be exponential), PHP6 is dead before it is even born.

PHP5's adoption rate based on data from Nexen.

A naive forecast of PHP5's adoption rate. As the major Linux distributions (RedHat, Debian and Ubuntu) started shipping PHP5 recently, I was optimistic and assumed PHP5's growth to be exponential. Based on data from Nexen.

As Nick Lewis pointed out: PHP is dying, and if we don't migrate to PHP5, the Drupal project will die along with the PHP project. It won't happen overnight, but it might happen several years down the road ... The point? Drupal's success depends on that of PHP.

Part of the problem is that the PHP team has their target audience wrong. If they want to drive PHP5's adoption, they need to make PHP5 attractive to ISPs and end-users, and focus less on application developers.

Many websites use a content management system, a forum or a blog tool and these systems work with both PHP4 and PHP5. And for a long time, they've worked better with PHP4 than with PHP5. I can only talk about Drupal, but from what I've seen, very few Drupal users show incentive to upgrade from PHP4 to PHP5. They are pretty much ignorant to what version of PHP they use, as long Drupal works well.

Isn't the Drupal team interested in using PHP5's new functionality? Sure we are. We'd love nothing more than to drop PHP4 support and to use PHP5's new functions. Unfortunately, we are dependent on our users too, and these users don't care about better OOP support, SimpleXML, PDO, DOM, etc. The only things they care about are performance, stability, compatibility and security.

If the PHP team would show that existing applications run faster by upgrading from PHP4 to PHP5, ISPs and end-users would have a strong incentive to upgrade. However, last time I checked, PHP5 was slower than PHP4. For anonymous users, Drupal is 13% slower with PHP5 than with PHP4. For authenticated users, this difference is only 4%. In other words, this gives them a good reason not to upgrade to PHP5.

If the PHP team would show that PHP5 is more stable than PHP4, people might start to care. Unfortunately, PHP 5.0 was rather buggy and less compatible than hoped for. Even today, PHP5.x+APC feels less stable than PHP4.4+APC.

Anyway, it is all about targeting the right users, and giving them a compelling reason to upgrade. Convince the ISPs and the applications' users to upgrade, not only the application developers. It would help us break out of this chicken-and-egg problem.

That said, the Drupal project can't just stand here and watch. Drupal's success depends on that of PHP, and PHP5's slow adoption rate is becoming annoying. So let us help the PHP project by giving Drupal users a compelling reason to upgrade to PHP5: With every Drupal release, let us make some of the new (non-critical) features PHP5-only, and gradually drop support for PHP4.

For example, let us start with making the module update notification feature, scheduled for inclusion in Drupal 6, depend on PHP5's SimpleXML parser. It is likely to upset some of our users and developers, but by giving back to the PHP project we help serve a bigger cause. After all, we really want PHP to shine.

And if projects like Wordpress, Joomla!, Typo3, phpBB, Gallery and phpMyAdmin would do the same (if not already), we can help drive PHP5's adoption before it might be too late ...

Why PHP (and not Java)?

Fri, 28 Apr 2006 05:42:32 -0400

Almost every week or so, someone asks me: Why PHP? Apparently, you are doing Java too. So why not Java? Do you regret the fact that you wrote Drupal in PHP?

The answer?

No, I don't regret the choice of PHP. Both languages will get the job done, but Drupal's main target audience are not conservative verticals (government, healthcare, banking).

The web is built by millions of individuals, many of which are amateurs. They continuously update, tweak and rebuild their websites. Scripting languages like PHP lend themselves to that, and are widely available at affordable cost. Sun, on the other hand, failed to make Java accessible to amateurs.

It would have been very difficult to get critical mass if Drupal was written in Java.