The Digital Ocean blog has posted a guide to help you get ready for PHP7, the next major release of the PHP language. There's a lot of new functionality and changes coming with the release along with plenty of performance and consistency improvements.

2015 has been an important year for PHP. Eleven years after its 5.0 release, a new major version is finally coming our way! PHP 7 is scheduled for release before the end of the year, bringing many new language features and an impressive performance boost. But how this will impact your current PHP codebase? What really changed? How safe is it to update? This post will answer these questions and give you a taste of what’s to come with PHP 7.

They start with a brief look at some of the overall performance improvements PHP7 will introduce and a few things to watch out for that may break with the upgrade (like deprecated features and engine exceptions). From there they get into some of the new language features:

• New operators (spaceship, null coalesce)
• Scalar type hinting
• Return type hinting

They each have brief code examples showing how they'd be put to use but there's also links to other resources with more information if you need them.

In his latest post Phil Sturgeon makes a request of the PHP community - to "send PSR-0 to to Standards Farm in the Sky". Or, to put it another way, deprecate it in favor of the more recent autoloader handling of PSR-4.

This article attempts to convince you that deprecating the PSR-0 auto-loading standard in favor of the PSR-4 auto-loading standard is not only a good idea, but a problemless wonderland of happy benefits, in the hope that when I try to get this done on the FIG mailing list, people will be happy about it instead of sad or rage-mode. [...] I believe it was talked about as an alternative at the time because we knew that the PHP community would drop their collective bricks if we tried to pull PSR-0 out from under them, right as they were just slowly getting used to using it.

He covers a few different topics and his opinions on each including the "hate" for PSR-0 (for wanting to get rid of it) and why it should even be considered for deprecation in the first place. He also reminds readers that he's advocating the deprecation of PSR-0, not the removal of it as a standard. It can still exist and be used but it will no longer be the "moving forward" method of autoloading (in favor of PSR-4). He also comments on the large user base out there on PHP <=5.2 that wouldn't be able to make the update to PSR-4 and a suggestion to projects wanting to encourage the migration.

Fabien Potencier has a new post to his site today talking about a recent trend in the PHP community around dependency and package management, the rise of Composer and the fall of PEAR.

As a good package manager to let user easily install plugin/bundles/MODs was probably also a big concern for phpBB, I talked to Nils about this topic during this 2011 hackday in San Francisco. After sharing my thoughts about libzypp, "..., I [Nils] wrote the first lines of what should become Composer a few months later". [...] So, what about PEAR? PEAR served the PHP community for many years, and I think it's time now to make it die.

He goes on to talk about how he personally has used PEAR in the past and when he stopped work on Phirum, a simplified PEAR channel manager. Based on some logging results, he found that most dependencies on his channels were related to PHPUnit's needs. When Sebastian Bergmann announced the move of PHPUnit away from PEAR Fabien decided to make his own move to deprecate and eventually remove new releases from the PEAR sources.

There's been some rumors floating around about the possibility of PHP's MySQL support going away in upcoming versions of the language. In his latest post Johannes Schlüter tries to bring a bit of clarity to these rumors and what's actually being removed.

Over the last few days different people asked me for comments about PHP dropping MySQL support. These questions confused me, but meanwhile I figured out where these rumors come from and what they mean. The simple facts are: No, PHP is not dropping MySQL support and we, Oracle's MySQL team, continue working with the PHP community.

He suggests that the confusion might have come from the recent changes to "soft deprecate" the oldest ext/mysql functionality and warn users against using it in their applications. He talks about the history of MySQL support in PHP and one project that removing it could adversely effect (WordPress).

Related to a recent discussion on the php.internals mailing list, Chris Jones has posted about moving away from the MySQL extension in favor of the MySQLi functionality and the effort bubbling up to make the old functionality deprecated.

An important discussion on the PHP "internals" development mailing list is taking place. It's one that you should take some note of. It concerns the next step in transitioning PHP applications away from the very old mysql extension and towards adopting the much better mysqli extension or PDO_MYSQL driver for PDO. This would allow the mysql extension to, at some as-yet undetermined time in the future, be removed.

He links to a RFC that's been posted to help promote and push this idea forward with mentions of the "carrot" and "stick" methods for pushing users towards mysqli.

As always, there is a lot of guesswork going on as to what MySQL APIs are in current use by PHP applications, how those applications are deployed, and what their upgrade cycle is. [...] I want to repeat that no time frame for the eventual removal of the mysql extension is set. I expect it to be some years away.

In a new post to DZone.com today Giorgio Sironi asks developers what new feature of PHP 5.4 is the most important to you and your application development?

Recently, the voting process for PHP 5.4 open to committers and users have been closed. We now have a clear picture of what will make the release and what will be left out. Some of these features (traits, web server) were already in, while other have been just voted and will be completed before the general availability of the release.

He lists out some of the major changes that'll be coming in the 5.4 release including traits, dereferencing, the built-in HTTP server, closure type hinting and the upload progress feature previously only in an extension. The end of the post includes a poll for you to give your feedback on what you think is the most important. As of the time of this post, the array dereferencing has pulled into the lead with traits coming in second.

According to this new post to the PHPClasses.org blog today, the core PHP development team has put plans in motion to try to remove the original MySQL extension from the default PHP installation.

PHP core developers are planning to kill the PHP original MySQL extension. If you are using MySQL in your PHP applications for a long time, this may seriously affect you.

Right now it's just in the proposal states (as suggested by Philip Olson) but, if fully acted upon, could have large implications on a number of PHP applications currently using MySQL. For now, though, Philip is only suggesting an education of the PHP user base that they should migrate to either pdo_mysql or mysqli for the future of their apps. Most of the comments following in the mailing list thread are supportive of the effort. They note that it won't be an easy task and, in the end, will still be a "bitter pill" for developers to swallow when the switch is finally thrown.

For the full thread of this discussion, see here and keep clicking through on the "next in thread" link.

According to a new post to the CodeIgniter.com blog, there's been even more changes in the 2.0 version of the framework - including dropping PHP4 support all together.

A few days ago a new repository popped up on our internal Mercurial server. We’re not particularly creative with our naming, so it was simply CodeIgniterNoPhp4. [...] With only a handful of significant changes to its codebase, the release was pushed along. We want to make CI 2 worth its name, so starting today, we’re requiring PHP 5.1.6 on our master branch.

They include a few things to watch out for including naming conventions, the change to __construct, a cleaner model object interface and chaining added to the email and validation libraries.

On the SitePoint PHP Blog, there's a new post from Harry Fuecks pointing out an extension for PHP that allows it to use the Cairo graphics library.

Cairo is the "next generation" vector graphics library for Linux and very cool to have it available in PHP. Also cool about the extension was created using PEAR::CodeGen_PECL, which Hartmut describes here: look Mum - no C! (well almost).

Harry also asks if, with the rise of new technologies like this, if it's time to make the move to deprecate GD from normal PHP use - at the same time, removing another hurdle in PHP's path towards being thread safe.

On the SitePoint PHP Blog, there's a new post from Harry Fuecks pointing out an extension for PHP that allows it to use the Cairo graphics library.

Cairo is the "next generation" vector graphics library for Linux and very cool to have it available in PHP. Also cool about the extension was created using PEAR::CodeGen_PECL, which Hartmut describes here: look Mum - no C! (well almost).

Harry also asks if, with the rise of new technologies like this, if it's time to make the move to deprecate GD from normal PHP use - at the same time, removing another hurdle in PHP's path towards being thread safe.