Upgrade to Symfony4 and Flex!

Awesome, waiting for this.

Well, I am not sure this is the right place to share (KNP team - please delete the comment if not) however I struggled to create a dockerized development environment to run Symfony 3.4 & 4.0 for a fairly long time. Because Vagrant has some fallbacks based on file count and definitely issues with permissions. Finally I ended up with an automated solution. That's why I want to share it with Symfony community by hoping it helps to Symfony Lovers: https://github.com/yahyaert...

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!

Hello Ryan,
Just a quick message to say thank you for this tutorial, I've just upgraded my app from SF3.4 to 4.1 and you made it super easy.
Awesome job!

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

Hi, i have an app in production with multiple bundles in symfony originally in 2.8, after i updated it to 3.4.15, but a will like migrate to symfony 4 but don't know how make this transition without pain. Thanks

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!

Great course and really important because migration to Symfony 4 is by no means trivial. Just two comments:
- Ask yourself how a visitor of the main page of knpuniversity can find this tutorial? - try to do this. I think you should somehow expose recent tutorials.
- As for migration to 4, I had a problem with injecting twig/template service. In Symfony 3.4 I did it via 'EngineInterface' but this stopped working in Symfony 4 (even after installing 'templating' component). I think this should be mentioned in the tutorial since it may look like a backward compatibility violation (there were no deprecation notices in 3.4). What is the preferred way to inject twig service? I do it now via '\Twig_Environment' but probably this should be done via some interface?

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!

Our team has an existing Symfony 1.4 project that contains multiple apps (Frontend, Backend and API) within one project. We just cleared our next 6+ months to look at rebuilding in Symfony 3.x, and were initially thinking about building the project using different kernels for each app. Looking at 4.x, and flex, that doesn't seem recommended any longer we're not sure what the best structure for our project might be if we try to base the new design on 4.x. Would love to hear any thoughts on updating a project with the structure we have, whether there is a best practice or if we'll have to go against convention, or possibly re-conceptualize the structure of our project.

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 :)

I have one more question about the last chapter, where Ryan shows how to inject repositories instead of EntityManager. Is this method immune to the problem of 'closed entity manager' as described by Matthias Noback post (google for: Inject a repository instead of an entity manager)? I guess this is the case, since we inject ManagerRegistry, but it would be good to be sure.

And by the way, another remark is that one has to be careful when moving credentials from .env files to for example apache vhost files, because then all this data is visible via phpinfo. So for example all credentials are visible in admin panel of phpbb (if you mix it with Symfony app); they are also visible in Symfony dev panel and many other admin panels. This may create some security issues for inexperienced users. Personally I tend to stay with .env file even in prod environment.

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!

oh my god, upgrade to sf4. what a tedious job.

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!

Hi, can you tell me when is this course ready? I want to create a new project but don't know which version I should be used 3.4 or I should wait for Symfony 4.

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!

Looking forward to renew my subscription as soon as it's released :)

Hey Ryan, Victor,
I am in the middle of the Symfony 3 track.
Should I follow this and upgrade the "our beloved Aquanotes" now and continue the track or leave it like it is, finish the current track then advancing to the Symfony 4 track and updating the Aquanotes?

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.