The Three Devs & A Maybe podcast, hosted by Michael Budd, Fraser Hart, Lewis Cains* and Edd Mann, has released their latest episode where they talk with guest Nicolas Grekas about the Symfony ecosystem.

In this week’s episode Edd and guest co-host Neal Brooks chat to Nicolas Grekas about all things Symfony. We start off discussion with how he got interested in programming, his introduction to Symfony, and his journey to now working on the code-base almost daily. This leads us on to talk about how he helped build the performance profiler Blackfire, and the importance of quantitative measurements whilst making performance improvements.

From here we highlight managing pull requests, the social factors when leading open-source projects and Symfony’s continuous migration path. Finally, we touch upon the recently released Messenger component and upcoming Symfony Contracts initiative.

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 directory for listening offline. If you enjoy the show, be sure to follow them on Twitter and subscribe to their feed to be notified when new shows are released.

Terry Chay has posted the answer to an interesting question about the PHP language that asks what is something very few know about PHP. The original answer was shared on Quora but he's copied it here for more visibility.

Question: What’s something very few people know about PHP? Answer: It is mind-bogglingly popular for web development. That popularity hasn’t diminished even though conventional wisdom says otherwise…

Over a decade ago, I said about 40% of the top 100 websites use PHP. [...] Overall, almost 80% of the internet is powered by PHP, and that has held steady for years! Newer web languages such as Ruby or NodeJS have only grown at the expense of other languages such as ASP, Java, or Perl.

He also shares some about the role of WordPress in these numbers (a big chunk at 30%) and a guess at how many PHP developers there are in the world right now.

Matthew Weier O'Phinney, (former) lead developer on the Zend Framework and Expressive projects, has a new post to his site looking at the future of the Zend Framework and how priorities have shifted.

For the past thirteen years, I've been either consuming Zend Framework or directly contributing to it. Since 2009, I've operated as project lead, and, since then, shepherded the version 2 and 3 releases, added Apigility to the ZF ecosystem, and helped bring middleware paradigms to the mainstream by assisting with the creation of Stratigility and coordination of the Expressiveproject.

[...] In the last three years, I have performed this work under the umbrella of Rogue Wave Software, who acquired Zend in 2015. However, Rogue Wave has recently made a strategic decision to focus its efforts on the Zend Server product of the Zend portfolio.

He also points out that the team largely responsible for the framework and building it over the years (himself, Enrico Zimuel, Zeev Suraski and Dmitry Stogo) will be leaving Rogue Wave and looking for other employment. Don't worry Zend Framework fans - they're going to do everything they can to keep the framework and its ecosystem alive! They're already looking for other sponsors (corporate or otherwise) so let Matthew know if you might be able to help!

Tomas Votruba has posted the second part of his Reactor series on his site today. In part one he covered some of the basics of the Ractor package (a CLI tool that provides some handy helper functions for Symfony applications). In part two he covers some of the "founding fathers" and packages that he built the package on top of.

You already know What Rector does and How it works from part 1.

It's not that PHP didn't need to be updated until 2017. I surely could delegate hundreds of upgrade-hours for my whole career. So why Now?

The post then talks about the idea of "codemod" functionality like the PHP CS Fixer that changes code to bring it up to PSR-2 compliance. It then covers the package that's one of the keys to the Reactor project, the nikic/PHP-Parser package. He talks about the read/write functionality, an example of a change it might make and finishes by thanking the "founding fathers" that made those packages available.

On the Hackermoon site there's a new post from developer advocate Mickaël Andrieu sharing a few reasons why he thinks you should learn Symfony in 2017 if you haven't already.

In 2011, when I started my studies in computer sciences I learned the PHP using symfony 1.3, and I realized my very first student project on the beta of Symfony 2. At the time, we were moving from a fully integrated full stack framework with a back office provided to a framework that followed what was found in the Java community: besides, many components of Symfony2 were strongly inspired by JEE.

PHP 5.3 had just come out and with it the ability to start designing object-oriented correctly. [...] Large Open Source projects have started to migrate on Symfony components: if it was not first, SensioLabs has talked a lot about Drupal8 because it is one of the biggest CMS on the market. EzPublish, PHPBB, PrestaShop and many others followed, some with a full stack framework approach and others by incorporating only a few software bricks.

He then talks about the "vibrant and mature ecosystem", listing some of the packages that use Symfony components. He also looks forward to the next major iteration of the framework: Symfony Flex. He ends with his reasoning why you should learn Symfony if you haven't worked with it (or at least how it handles common things like requests and services).

The BugSnag blog has posted a tutorial from a guest author, Graham Campbell, introducing you to Packagist and the PHP ecosystem continuing on from the previous post introducing the Composer tool.

In our last blog post we saw the basics of Composer, but skipped over where it actually finds its packages, and how to publish packages of your own. In this blog post, we will be looking at exactly this, plus some security considerations when using composer in your application.

The post starts off by introducing Packagist and how you can distribute your package there. There's a section that covers Open Source licenses, a few of the different types and how to list licenses of your currently installed packages. Following this the post talks about using branches and aliases to pull in the code you need (not just the latest release). The tutorial wraps up with a look at some of the security concerns around using packages and how to keep on top of new versions with new bugfixes.

On his site Fabien Potencier has posted an article about the next major release of the Symfony framework - version 4 - and how it will allow for the "composition" of your applications rather than some of the current methods.

Symfony 3.0 was boring, a cleaned-up version of the Symfony 2.8 version. Symfony 4.0 will be different: Symfony 4.0 = Symfony 3.4 - deprecated features + a new way to develop applications

There is another way to think about a new major version though: Symfony 4.0 = Symfony 3.0 + all features added in 3.x - deprecated features + a new way to develop applications

He goes through some of his thinking process around some of these changes and the "day-to-day experience" of managing a Symfony application. Specifically he suggests that:

• Installing a Bundle is too cumbersome
• Removing a Bundle is even more cumbersome
• The Symfony Standard Edition is not good enough
• No Distribution Ecosystem

He ends the post with a look at what he sees as the ideal ecosystem for the framework and where Symfony Flex fits into the picture (example project here).

Symfony Flex is going to be the default way to manage Symfony 4 applications. But Symfony Flex will be available as an option to manage Symfony 3.3 and 3.4 applications as well! That said, we might need to break backward compatibility between now and the launch of Symfony 4. Consider Symfony Flex as alpha before Symfony 4.

On the Laravel News site there's an announcement posted about a new tool coming to the Laravel ecosystem - Laravel Dusk. Dusk is a browser testing tool that makes it easier to test Laravel-based Javascript-heavy applications.

When you write end-to-end tests, Laravel provides a set of useful helper methods which make it easy to click a link, fill an input field, or submit a form. Under the hood, Laravel uses the Symfony BrowserKit component to simulate the behavior of the web browser. However, if your app uses JavaScript and AJAX to load the page, BrowserKit will not work for you.

Laravel Dusk is a new tool that will be introduced in Laravel 5.4 to solve this problem.

The post goes on to talk about the tool and what kind of functionality powers it - a combination of ChromeDriver and the Facebook PHP-Webdriver packages. The testing process is claimed to be faster than normal Selenium tests and feels more "natural" than BrowserKit testing. Dusk will save screenshots of failures automatically and comes with helper methods, multiple window support and a Dusk-specific environment file.

In a new post to the Liip blog Lennart Jegge shares a "quick look" at the current state of the Drupal 8 project and some of the issues some people are having making the transition.

Eight months ago Drupal 8.0.0 was released. Exciting news for drupalists. Since then comparing D8’s features to its predecessor is a topic in daily business. "Can drupal 8 do what we can do now with 7 today?". After playing around with D8 i get the feeling some crucial features are missing.

He shares some of the features he sees as still missing (a Top 10 wishlist) and how it seems difficult to get a good overview of the Drupal 8 ecosystem. Some modules have yet to be updated and rewrites can be difficult given the major "under the covers" changes to Drupal itself.

In the end the importance of a variety of mature modules that play together nicely is crucial when it comes to efficiency, maintainability and stability of a project

On the Liip blog they've taken a look back at the impact that the Symfony project (and related projects) have had on the PHP community and ecosystem.

As we were preparing the news about becoming a [Sensiolabs Silver Partner](https://www.liip.ch/en/news/archive/2015/10/15/liip-now-a-sensiolabs-silver-partner.html), I brought back a bit to the history of Symfony here at Liip. We did do a few symfony v1 projects at Liip but things only really took off with Symfony2. Back in 2009 Fabien came to Zurich to discuss some of the Symfony2 components (still PHP 5.2 compatible at the time) he had just released as well as a few he hadn’t yet released. Jordi, who was working at Liip at the time, and I integrated all of them into our company internal framework over the following months which we later presented at the Symfony Live. This means Liip in fact build the [first Symfony2 framework](http://www.slideshare.net/lsmith77/okapi-meet-symfony-symfony-meet-okapi), even before there was the official Symfony framework.

He goes on to talk about the early days of the Symfony community and the work that was done on several bundles outside of the framework itself. He touches on the Symfony ecosystem and its growth during this time and the influence it has had on the PHP community.

All and all I believe that Symfony has really commoditized the concept of a framework for PHP applications. Reusing an existing framework is now the standard when building new PHP applications. Any project that wants to stay alive will in the long run have to refactor on top of a framework.