On the Zend Framework blog there's a new tutorial posted that wants to help you use Expressive for asynchronous request handling with the help of the Swoole extension.

When we were finalizing features for Expressive 3, we had a number of users testing using asynchronous PHP web servers. As a result, we made a number of changes in the last few iterations to ensure that Expressive will work well under these paradigms.

Specifically, we made changes to how response prototypes are injected into services.

The article starts by talking about the issue with the previous response prototype handling, mostly that, in an async world, all responses would be sharing the same instance rather than rebuilding a new one for each request. It then explains their reasoning behind even worrying about async support in the framework's response handling noting that the major reason had to do with the performance gain. The post mentions the Swoole extension and shows how to install it via PECL but you'll need to check out the project's documentation to see how to create a server that makes use of it.

The Zend Framework blog has posted their official announcement of the release of Expressive version 3, the latest major release for the Zend Framework-based microframework based around PSR-15 middleware.

Expressive 3 embraces modern PHP, and requires PHP 7.1 or higher. Strong type-hinting, including return type hints, make both our job and your job easier and more predictable. The ability to use all modern PHP features helps us deliver a solid base for your application.

Expressive 3 provides full support for the PSR-15 (Middleware and Request Handlers) standard. [...] Expressive 3 massively refactors its internals as well. [...] Expressive 3 provides more command line tooling and tooling improvements in order to make developing your application easier.

[...] Finally, we recognize that Expressive has changed massively between versions 1 and 3, while simultaneously keeping its primary API stable and unchanged. However, to help users find the information they need for the version they run, we have rolled out versioned documentation, with each version providing only information specific to its release cycle.

The post also lists out some of the new components including zend-expressive-session, zend-expressive-csrf and zend-expressive-hal. There's also links to more information about upgrading, community resources and a "thank you" section to several people that helped get the project to this version 3 release.

Phil Sturgeon has a new post to his site giving a brief overview of the state of the PHP-FIG, the v3.0 proposal that's been put out and sharing some of his own thoughts on both.

I was involved in the PHP-FIG since 2012, and I have seen every conversation, been part of every decision, and know the reasoning for a lot of stuff, regardless of the result and my person preferences. Being so involved with this group for so long, I have a fair bit of context that other people are lacking.

The latest of about four large conversations in the FIG is: whether or not a new organization should take its place. Seeing it framed in this way is odd, because I'm not sure anyone is literally proposing that.

Phil covers some of the background behind the PHP-FIG group including some of the original goals and how it grew well beyond the "framework" part of its name. He talks about some of the reasons he sees that the group has stayed around. Then he gets into the FIG v3.0 proposal - a relaunch of the group with a different structure and different way of getting things done (after learning from some of the mistakes in the current group). He also talks about the other elephant (elePHPant?) in the room: whether this new structure calls for a new group to be formed or if the PHP-FIG should just adapt and move on.

It will be interesting to see how this all shakes out in the end but the PHP-FIG group has, undoubtedly, helped to usher in a lot of the "modern PHP" work we see in the community now especially when it comes to things like Composer, logger structure and middleware handling.

On the Symfony Finland site there's a new article posted about the recently released v3.0 of the Bolt CMS and details about this Silex-powered, modern PHP-based system.

On Tuesday 10th of May the development team released a new major version of Bolt CMS. The Open Source content management system is a lightweight and easy to use tool for managing websites and blogs. In addition it's perfect for learning modern PHP development practises.

The third major version of Bolt continues on the path, being an evolution rather than a revolution. The CMS is built on the Silex microframework based on the Symfony PHP components.

The article talks about the "solid foundation" of Silex and good project management skills of the team behind it. They then get into the installation of the tool and some of the libraries that it uses to get the job done (including Twig and YAML handling). They also list some of the things that are new in the v3.0 of the CMS including:

• A new extensible Storage layer
• Backend UI refresh
• Improved tests / code coverage
• New documentation
• Web asset queues, and easier to keep files out of webroot

There's also mention of some of the things that were removed and didn't make the cut to be included in the release. The post ends with links to other resources where you can find out about Bolt, get its source and a few other articles about people putting it to use.

In this new article on the PHP-DI project site they've shared one of the latest tools they've created to make it easier to integrate PHP-DI with the latest version of the Slim microframework (v3).

Slim 3 was released 3 months ago and it was significant. It is one of the first frameworks to integrate the latest standards and concepts in its core.

[...] While PSR-7 and middlewares are very interesting, what's more useful for us is the use of container-interop. That means Slim 3 can work with any dependency injection container. It is very easy to replace the default container (Pimple) with PHP-DI, but today we are releasing a "PHP-DI - Slim" bridge that goes a little further.

They then show how to use their new bridge to create controllers as services in the container and pass them parameters. The post ends with the instructions on getting the PHP-DI bridge installed and how to use it to replace the default AppSlim creation of your application.

As announced on the Symfony blog today, the next major version of the framework has been released - Symfony 3.0.0.

Symfony 3.0.0 has just been released. [...] You can read more about this new on the BETA1 announcement and by reading the Living on the Edge articles on this blog. Also read the UPGRADE guide for Symfony 3.0.

Want to upgrade to this new release? Fortunately, because Symfony protects backwards-compatibility very closely, this should be quite easy. Read our upgrade documentation to learn more.

The post also includes a (long) list of updates since the previous beta version with links to each issue on the main Symfony GitHub repository.

In this new post Leonid Mamchenkov looks at the latest version of a PHP framework that's been around since the PHP4 days, CakePHP, and some of the improvements that will come with version three.

Currently, I am at the start of a couple of projects, which require a bit of the future support. CakePHP 2.x can handle the job now, but I’m looking more into the next 3-5 years. And that’s why I’m looking at CakePHP 3, which is still in the early development stage, with an alpha release coming not too long from now (have a look at the CakePHP 3 roadmap document). Let’s have a look at the high level goals for CakePHP 3.

Among the items he mentions are things like:

• The adoption of broader PHP community standards
• An increase in modularity
• Developing for PHP 5.4+
• Composer support (and using PSR-4 autoloading)
• The removal of some more complex, brittle code in favor of simpler, easier to extend options

Check out the roadmap and migration guides for full information.

The HHVM blog has an exciting new post for those using the HHVM and Hack language - they've officially released version 3.0.0 with complete Hack support.

At our last major version bump (2.0.0), we basically became a whole new project. We switched from a “PHP -> C++” translator to a virtual machine. This version bump (3.0.0) is a much less dramatic code shift (we’re still a VM, don’t worry), but this time the big announcement is that we support a new language, Hack.

They take a step back in time and look at the changes since 2.0.0 in organization, technology and community involvement. From there, they get into "the business" of what's in this new release including:

• The old webserver is gone. If you get something like Uncaught exception: no factory for server type "libevent", you need to switch to fastcgi.
• We are moving from .hdf config files to .ini.
• Our most requested extension, mysqli is now in. (there's currently a bug, but the fix will be in 3.0.1).

You can find out more about the HHVM on the project's main website.

In a recent post to his blog Jeremy Kendall has posted a guide to deploying a PHP application with Capistrano. There's been enough changes in recent versions of the tool where information and configuration was difficult to find.

I spent quite a bit of my day yesterday trying to work out a painless, scripted, idiot-proof deployment process with Capistrano for my photo-a-day website. I’ve been doing a lot of work on the site lately, which means a lot of deployments, and I’ve been very unhappy with myself for implementing what amounts to “deployment worst practices” when it comes to my personal projects. The last time I worked with Capistrano was about two years ago, and a lot has changed since then. Capistrano v3 was released in June of 2013 and brought with it a lot of great changes, but for a guy who doesn’t know ruby and relies on tutorials and Stack Overflow questions for help, the version bump brought a lot of pain as well.

He starts with a list of some of the immediate challenges he hit against including that every tutorial is wrong (because they're for v2) and that the Capistrano v3 official documentation is lacking. From there he shares the steps he followed to get the whole process working:

• Installing Ruby and Capistrano
• Preparing the configuration files for the deploy
• Server configuration/SSH forwarding
• Getting Composer to work on deploy (with a Ruby gem)

There's also a few other random helpful hints around linked files/directories and variables.