Upgrade to Symfony4 and Flex!

Hey Yahya,

Thanks for sharing your solution with others. I'm not a Docker expert to say how cool is your solution and actually don't use Docker for virtualization on my laptop, but I think it'd be helpful for someone.

Cheers!

Woohoo! Super glad the tutorial was helpful. But congrats to your hard work Nicolas ! :)

Hey Fabio,

So, you're already on Symfony 3.4 - great! Then this screencast is for you! Here we upgrade our legacy application up to Symfony 4 with some bundles, so you can see the whole process. Symfony do their best to make developer's life easier so that they can upgrade without a lot of pain, but yeah, changing major release means that you will need to do some extra work during upgrading. So, go with this screencast to know how exactly upgrade your application :)

Cheers!

Hey Antol,

1. Good question! For registered users we have "course updates" page: https://knpuniversity.com/p... if you're logged in - this page shows you recent updates. If you're a new user, you may not be interested in recent tutorials only. Anyway, we deployed a new search page yesterday, which includes a feature to see newest ones: https://knpuniversity.com/c...

2. If you look into "Twig_Environment" class: https://github.com/twigphp/... - you'll see it implements nothing and extends nothing. So there's no other way to inject this service - only typehint it with actual class name. Yeah, I think it worth to be mentioned in the course, thanks!

Cheers!

Thank you very much for your answers! I successfully migrated my project to Symfony 4 and this wouldn't be possible without this tutorial. Now I agree that the new directory structure and flex recipes are really nice refreshment to the framework.

Hey Antol,

Congrats with migrating to Symfony 4! Yeah, it was not a trivial upgrade, but it's definitely worth to be done ;)

Cheers!

Yo Geoff Maddock!

Wow! that's really exciting! Let's talk about the multiple kernel thing first. It's only *not* recommended because it basically adds technical complexity that very few projects really need. But, there's nothing wrong with this approach. There is only one benefit to it: performance. By separating kernels, your admin kernel only contains your admin routes/services, nothing from API, for example.

However (and I have no hard stats to back this up). thanks to some container optimizations in Symfony 3.4, Nicolas Grekas tells me that the performance advantage of multiple kernels is now greatly reduced. Specifically, having a "smaller container" no longer makes a difference. You *will* still have some performance differences because you will have less routes, and API-related event listeners won't need to run for the admin. But the point is: the performance cost is now lower, so you need to look at the multi kernel decision carefully. The added complexity is real: your app will look and behave a bit differently than a normal Symfony app. But, it's still a valid approach.

Another thing you guys will need to think about is whether or not you use a Flex directory structure (it works fine on 3.4). The advantages or many: it's the new way of doing things, and upgrading to 4.x will be easier later (and your project will look like the current documentation). The only disadvantage is that, since Flex is just out, there are less resources, and a few minor things may change. Basically, you're a bit more "cutting edge". Without knowing anything about your project, I would nudge you towards Flex. It will also be at least a little bit faster (since you control your dependencies more), if that's important.

Cheers!

It's all pretty new to us, since we were sort of "stuck" on a 1.4 app for many years. We didn't have a ton of development resources to do a major update until now, we only recently started learning the 3.x way of doing things. However, we're also not stuck doing things that way, as we're still early in our redesign process.

If we did go the flex route, it didn't seem like we could combine that with multiple kernels. And if so, it wasn't clear how we'd rebuild our app within one kernel. Currently all of our apps share the model and business logic, but use different routing, templates and authorization rules. If having a smaller container per app (kernel) is less of an issue now, then I could see us trying to put it under one kernel and flex. Still need to learn more about it in detail.

Hey Geoff Maddock!

Yea, I wish I could give you a perfect recommendation :). Since you share the model and business logic, that basically means you already share classes and services between your apps. That means it's a good fit already to a "single kernel" situation. The negatives of the single kernel are that routes are shared (not actually a big deal, but small performance hit to be sure) and you will also only have one security system. However, you could use one firewall per "section" of your site. A firewall is basically a "security system", so you would be able to effectively have 3 independent security systems with different users (if needed) and different ways to authenticate per firewall.

About Flex and multiple apps. It's quite possible... we just need to think through the process :). Currently, the Kernel class (in src) is programmed to automatically load all the config and routes from the config/ directory. But it's not magic: you can see all of the logic right inside that class. In theory, you could keep the Flex structure, but create kernel-specific configuration directories (e.g. config/admin/), and program the kernel to load the normal config, and THEN load anything in that directory after. Heck, you could even do this with one* Kernel class: override the constructor and add a 3rd constructor argument (the "app" name). So, in index.php, it would look something like new Kernel($env, $debug, 'admin');.

Ha! So there's some good information... but I'm not sure it will help your decision. I think both options are very solid. And you are not prohibited from multi kernels in Flex.

Cheers!

Well a small addition from an end-user, it might be good to mention that Symfony 3.4 has long-term support, literally till the end of Nov 2020.

Ah yes, that's a VERY good thing to mention indeed. If you use 4.0, you'll need to upgrade to 4.1, 4.2, etc a bit more quickly. But, Flex *does* work on 3.4 :)

Hey Antol_F!

GREAT question. The answer is.... no, it's not a problem anymore :). Actually, I'm only about 90% sure about this - it's quite technical. The reason that it is not a problem anymore is explained here: https://github.com/doctrine.... This "entity manage is closed" was never a problem I ran into, so I can't verify that it's fixed now, but I believe it is. Even if you inject the repository, internally, the repository calls out to an EntityManager that it has internally. So if the entity manager is actually a proxy, and Symfony is able to replace it with the new entity manager when things become closed, the repository should automatically continue working :).

Cheers!

Oh, and let me also reply about .env :). Yes, you need to be quite careful when setting environment variables. Honestly, setting environment variables is different on every setup (Apache, Nginx, PaaS, etc), and I think that as a community (Symfony), we will better-document and discover the best practices for all of this. And even though the .env file is not meant to be used in production (the parsing of it is not cached, and so therefore not optimized), I expect a somewhat significant percentage of people to continue using it in production. And honestly... I don't see a HUGE problem with this (I doubt the performance hit is noticeable, and you can always use Blackfire to profile).

So, thanks for this comment!

Cheers!

Hey Bruno Z.!

Yea, it is some serious work for sure. Technically, upgrading to Symfony 4 (like upgrading the vendor libs) is no problem. But getting things into the Flex directory structure (which is technically optional) takes some time. Hopefully we won't have anything like this from 4 -> 5 :).

Cheers!

Hey Sebastian Majchrzak!

Actually, you can click the "Notify me when course is available" button above and we'll email you when it's ready (hopefully very soon!). But to answer your question, once Symfony 3.4 and 4 is released (which is literally happening at this moment!) you can use either! But, you should *definitely* structure your project using flex - that is 100% for sure! I would recommend using Symfony 4, as 3.4 and 4 have the same features (so why use Symfony 3.4?). But, there is one reason that 3.4 *might* be better during the short-term: we are still waiting for community libraries and bundles to allow Symfony 4. So, if you use Symfony 4 immediately, there may be some libraries & bundles you can't use right away.

Somewhat related: Symfony 4 is going to be AMAZING! :D

Cheers!

Hey Robertino,

Good question! Hm, I'd say it's up to you. Well, if you upgrade to Symfony 4 now, then you'll have a bit different file structure than we show in our screencasts. If it's not scary you and you're ready for this challenge, go for it! Anyway, practicing with Symfony 4 is more interesting I think :) But you can totally postpone this upgrade and continue the track with Symfony 3 app.

Cheers!

I would recommend staying on the Symfony 3 track and first gain some experience with Symfony framework. After that migration to Symfony 4 should be easy (with this tutorial). On the other hand, if you don't have much experience with Symfony framework, migrating the Symfony 3 tutorial to Symfony 4 may be quite frustrating.