Tomas Votruba has a post to his site sharing some background on a migration he recently helped perform migrating an application from Nette to Symfony.

On the break of January/February 2019, we migrated whole Entrydo project from Nette to Symfony. It was API backend with no templates, but still, it wasn't as easy as I expected.

Many coffees and beers were drunk during this migration. 0 programmers were too frustrated to give up. Yet, you'd laugh if you knew what took us the most time.

He starts with some of the reasoning why they wanted to make the move and walks through the steps they took to get there:

• getting ready
• making a commitment
• automated migrations > manual changes

He also talks about some "WTF moments" they had along the way where code that should have worked wasn't (and the simple issue that caused them).

Tomas Votruba has a tutorial posted to his site showing you how to update your Symfony application to make all of your services use auto-discovery rather than hard-coded configuration settings.

Do you use Symfony autodiscovery services registration everywhere and your configs have no extra lines? Skip this post and rather read another one.

But if you have many configs with manual service registration, tagging, and autowiring, keep reading. I'll show you how you can convert them easily be new Symplify package.

He starts off by talking about a few e-commerce projects he's been working with lately that define service configurations manually. He then mentions a package that's been created to help convert these over easily to autodiscovery rather than having to change them one by one. He provides the instructions to use this package and mentions some of the things that could go wrong in the conversion process to keep an eye out for.

In a post to his site Tomas Votruba introduces something that can be helpful for those working with Symfony 4 and Flex to make the "zero-setup configuration" easier to work with: effective use of the Symfony Flex Loader.

Symfony 4 and Flex is heading in direction of zero-setup configuration - no bundles, no extensions, no configuration. You already know how to get rid of Configuration. Flex now loads services instead of Extension class.

But it has an extra price, a lot of new boilerplate code in Kernel. Today you'll learn how to keep your Kernel Flex-ready and clean at the same time.

He starts with an example kernel that loads an extra directory (defined by a "custom path"). He shows how to refactor these examples to "make them small again" making use of the Flex loader package that reduces the number of lines required to accomplish the same end result.

In this new post to his site Tomas Votruba shows how to configure a Symfony application without using the bundle or extension configurations.

Symfony Flex is moving towards of bundle-less applications. That doesn't mean you should create a monolith code in /src as fast as possible, but rather control everything via .yaml and .env files. It's takes few steps to remove extension and move to import of services.yaml.

But how would you approach a simple task as setup a account number parameter?

For those not familiar with "no-bundle applications" in Symfony, he starts with a link to the SymfonyCast course listing out the main points. Following this he covers what changes in the service registration and what changes in the configuration (with code examples). He then provides some options including keeping the extension, setting the parameter manually and binding the parameter, favoring the last two on his list as more maintainable.

Martin Hujer has put together a new post to his site sharing some of the PhpStorm plugins he considers essential for Symfony development, making your life easier as you create applications with this popular framework.

I've been using PhpStorm for quite a while and I'm still surprised now and then when it suggests an auto-completion for something I thought that's not possible.

But there are still many things - usually framework- or library-specific - that PhpStorm cannot do on its own. But there are plugins that can step in place and do the magic for specific framework or library.

Several of the plugins are more for improving PHP development in general but others are more Symfony-specific:

• PHP Annotations
• PHP Toolbox
• Symfony Plugin
• PHPUnit Enhancement
• PHP composer.json support
• Php Inspections (EA Extended)
• Twig Support
• .env files support
• .ignore

Each item in the list comes with a brief introduction to the plugin, links to find out more information, and, in some cases, animations of it in use in the editor.

On the Symfony blog they've made a post about a change in all Symfony versions around how .env files are handled and what prompted the change.

When Symfony 4.0 was released, the .env file was introduced as a way to set environment variables. The core of the system has not changed. But, thanks to recent updates to some core Symfony recipes, .env loading has some new features that can be enjoyed on any Symfony Flex project!

If you have an existing Symfony app (started before today), your app does not require any changes to keep working. But, if/when you are ready to take advantage of these improvements, you will need to make a few small updates.

The post outlines what changed exactly including the removal of the .env.dist, allowing a .env.local to override the settings and that the .env file is now pulled in for testing. The final point is the main reasoning for the changes to make testing much easier when it relies on these environment variable values. It doesn't require any changes to your current application but can be optionally implemented to take advantage of these updates.

In a new post to his site Tomas Votruba looks at autowiring Symfony services and parameters to make it even easier to integrate services into your application.

I love how Symfony caught up late autowiring integration in since Symfony 2.8. Then set a trend in Symfony 3.3 with service autoregistration.

That opens new possibilities to almost config-less registration, doesn't it?

He first looks at some of the "old" configuration handling, defining the services manually in the YAML configuration along with their arguments. He shows how this evolves with the addition of autowiring and autodiscovery, minus the parameters. He continues on to show how to integrate parameter handling into the services configuration via the bind option. He also shows how to improve this and use autowired parameters and call them directly in the constructor of your class and let the DI container do the rest.

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.

The TutsPlus.com site has posted another tutorial where they go in-depth with one of the components of the Symfony framework. In this new tutorial they cover the Symfony Event Dispatcher component including its basic use via events and subscribers.

Today, we're going to learn how to use the Symfony event dispatcher component, which allows you to create events and listeners in your PHP applications. Thus, different components of your application can talk to each other with loosely coupled code.

[...] The event dispatcher component provides three elements that you could build your app architecture around: event, listener, and dispatcher. The whole system is orchestrated by the dispatcher class, which raises events at appropriate points in an application and calls listeners associated with those events.

The tutorial starts with the command you'll need to get the dispatcher installed and examples of:

• creating events
• dispatching the events to subscribers
• listening for the events

The tutorial then covers subscribers, reusable listeners that can be added to the list for handling when an event fires. Code examples are included for all topics.

Alex Makdessi has a post on his Medium.com site kicking off a series of posts taking a deeper look into the Symfony DependencyInjection component. In this first part of the series he takes some of the "first steps" with the container.

this article, we’re going to dive into Symfony’s dependency injection component. We will use it from scratch, out of the Symfony framework, with the minimum of external dependencies. You can code along with me while reading this article, each steps will be detailed so you can easily follow.

He starts off the tutorial by creating a new project and including the DependencyInjection (DI) component via Composer (as well as symfony/var-dumper for debugging). He then starts in on the code showing how to make a ContainerBuilder instance to hold the object instance for reuse. With the container created, we now need something to use it. He creates a basic piece of functionality that works similar to the "voters" included with Symfony's security component to determine if a user has a certain role. He first creates this as a stand-alone tool but then refactors it so that the access manager and post voter objects are pulled from the dependency injection container rather than made manually.