Last week I started the journey of updating all the existing tutorial content from Symfony 2 and Symfony 3 up to Symfony 4.
I mentioned that I don’t plan on recording a video for every single migration.
I also mentioned that I would be covering the most requested content first. That’s why I started with the GitHut series, with which most site users who are brand new to Symfony take their first steps.
So far I’ve written 9000 words on updating from Symfony 3 to Symfony 4.
Nine thousand words.
I was staggered by this.
It’s left me wondering exactly who this content is aimed at? I can’t imagine a beginner taking a 6 video (7 including the bonus) course, and then thinking a further 6 videos on updating this small project to Symfony 4 is something that makes sense.
Also, the project is for beginners so I can’t imagine too many experienced developers using this as reference, either.
Anyway, I’ve started so I’ll finish.
As a heads up, whilst I’m updating these projects there are very likely to be a few weeks without some new videos. I have a limited amount of time per week to create new content, and the general consensus from support tickets is that updating existing content is preferable to new content.
Video Update
This week saw three new videos added to the site.
#1 – What happened to my Web Server?
This change happened earlier than in Symfony 3.4, but as we are using the GitHut project as the base of this series, we are impacted by this change.
If you aren’t aware, as of Symfony 3.3 the web server (available via bin/console server:start ) was extracted out into a separate bundle.
In hindsight this foretold the way that most things in Symfony would become – opt-in, rather than opt-out.
Anyway, removing the web server bundle is potentially unexpected, and adding it back in is the first in a list of tasks that we need to do to migrate from Symfony 3 to Symfony 4.
#2 – Fixing Generic Symfony Deprecations
Whatever your Symfony 3 application does currently, as soon as you upgrade to Symfony 3.4 you’re going to get a whole slew of deprecation warnings.
This is code that must be addressed by us as developers, if we are going to upgrade to Symfony 4.
Simply put, if we don’t fix these problems and then blindly update to Symfony 4 then our site will (most likely) just stop working.
A lot of these deprecation warnings sound complicated but are really just about adding in a speech mark here, or a new line there. Often if unsure, a quick Google is enough to see you right.
Even so, there are a bunch of these to cover and if you’re brand new to Symfony then this might not be a super easy task to complete. But don’t worry, this tutorial walks you through each fix, step by step.
#3 – Fixing Deprecations In Our Own Code
Whilst the previous video tackled problems that you’ll find in most every Symfony code base, in this video we look at specific problems to our own code.
It’s telling that even though the GitHut app is very simple compared to most real world projects, we still have a bunch of issues to solve. When I’ve approached this task on my own real world projects, the list of deprecations can be large and off-putting.
In this video we cover one of the most frequent problems you will encounter:
Legacy service definitions.
You may have already started using the new approach to Dependency Injection, and if so, you’re going to have a head start in this battle.
If you haven’t then now is the time to jump in and start learning some new stuff.
Ok, that’s it from me this week. Short and sweet.
Until next week, have a great weekend and happy coding.
Chris
