This is the last you will be hearing from me – newsletter wise, at least – for 2017.
With that in mind I’d like to take this opportunity to say firstly a very big and sincere thank you to you for your support this year.
Whether your are a subscriber currently, have subscribed to the site in the past, or will be subscribing in the future, your support means a lot to me.
I’m really pleased with how things have progressed with CodeReviewVideos.com this year.
I launched the new site version, which whilst still a work-in-progress (and likely always will be) now is in line with almost everything new I’ve learned in the last four years.
I share everything I know on CodeReviewVideos.com, and from the feedback I’ve had this year (thank you!) I know it’s really helpful to many of you, too.
This site is all about saving you weeks, months, or even years off the amount of time it takes to learn a framework as big and (potentially) complex as Symfony.
There’s other great stuff on here too, like learning how to use Docker in the real world, and another of my personal favourites, React with Redux and Redux Saga all connected to a Symfony JSON API.
This week saw three new videos added to the site.
We’ve fixed the issues with Symfony’s code.
We’ve fixed the issues with our own code.
Now we must fix the issues with any third party bundles we are using.
In our case we have just one bundle – eightpoints/guzzle-bundle.
The issue we have is fairly common. If a bundle you use adds ‘stuff’ to the sidebar in the profiler, then you are almost certainly going to need to fix this issue. Well, I say you. What I really mean is you will need to hope your bundle maintainer has updated their code appropriately, or you have a few options:
- Don’t upgrade
- Fix it yourself (which may take a while to get merged)
- Fork it, and fix it yourself (hoorah, now you’re in open source)
- Be lucky and have the bundle maintainer already have updated it for you
We all hope for number 4, right?
Fortunately on eightpoints/guzzle-bundle we get lucky. This is fixed for us… but:
Always a but. This will mean we need to be on at least PHP 7. Actually thought, Symfony 4 needs PHP 7.1, so yeah… either way it’s time to come kicking and screaming in to the modern world of PHP. Good.
The recommended approach for upgrading to Symfony 4 with Flex is to start a brand new Flex project, and then migrate code between the old project, and the new.
This brings a potential problem:
When you create the new Flex project you will, by default, get a git repo created on your local computer.
For the love of Mike, don’t do what I did and accidentally copy that git directory over your existing git directory. Whoops. I share for the comedy, and fortunately it didn’t cost me any, because that was during the write up, and I re-do the whole thing again for the video. I bet you don’t want to do things twice though 🙂
There’s a bunch of steps to work through, some easier than others. You won’t believe step 5! Ho, ho, a buzz feed style bit of link bait title nonsense.
No, but seriously, step 5 needs some extra attention so be sure to watch the video to learn what that is.
Finally we finish up the Symfony 4 migration by moving over the
src directory contents from the old Symfony 3.4 project to the new Symfony 4 Flex approach.
We then move over the Twig templates. There’s more work to be done here, and some of the problems we will face are not very intuitive. I guess it depends on how much you’ve been following the changes made in Symfony 4.
It really does feel good to have migrated a complete project, regardless of the project’s size, from Symfony 3 to Symfony 4. There’s some serious sense of satisfaction in seeing everything continue to work, even with such a massive amount of change behind the scenes.
Here’s to 2018
Whatever you are up to in 2018 I sincerely wish you every success.
Thank you and happy Christmas!