The First Symfony 4 Tutorial Is Here

This week saw six new videos added to the site.

These are the final four in the Docker Tutorial for Beginners series, and the first two in the Beginners Symfony 4 Tutorial series.

A tutorial on Symfony 4 has been highly requested since it released on 30th November 2017.

Since then we’ve had three patches, so we’re now on Symfony 4.0.3.

Have you tried it yet?

I Had My Doubts

I will be completely honest, for the longest time Symfony 4 scared me.

We switched from the Symfony 2 / Symfony 3 Standard Edition, to the Symfony 4 skeleton. From a nice “full stack” to a minimal, bare bones starting point.

The first time I used Symfony 4, I just couldn’t wrap my head around why they would remove most of the very useful things:

  • Monolog
  • Twig
  • Routing…

And then the more I read, the more I thought that the symfony/skeleton was taking Symfony to become a replacement Silex. And whilst I have used and quite like Silex, I preferred the Symfony Standard Edition / full-stack approach.

I also went into a panic as I thought pretty much everything on the would be obsolete.

Moar Skellingtons

Thankfully, all my fears were eliminated when they released the  symfony/website-skeleton.

For me, this is perfect.

All the benefits of why I use Symfony for all my web projects, with all the added new features and bug fixes.

And a bare bones edition for my command line apps.

My Favourite Video

Even though this is a Symfony 4 beginners series, the last two videos get a little geeky. I can’t help myself.

There’s a really interesting change in Symfony 4 with the way we use controllers.

It’s useful to know as a beginner, and hopefully it sparks your curiosity into knowing more about the “how” and “why” of Symfony generally.

This one should be useful even if you’re not a beginner.

Other Stuff

There’s a lot of other change in progress at the moment, particularly on the back end of the site.

I’ve been putting some of the front end tweaks live this morning, and these take on board the suggestions I’ve had from site visitors. Thank you for all your feedback I really appreciate it.

There are still 15 or so videos to come from this batch. I’m currently taking a break from editing to write this.

Ok, on that note, have a great weekend, and happy coding.

Chris –

Merry Christmas and a Happy New Year for 2018

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 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, 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.

Video Update

This week saw three new videos added to the site.

#1 – Fixing Third Party Bundle Deprecations (Indirectly)

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:

  1. Don’t upgrade
  2. Fix it yourself (which may take a while to get merged)
  3. Fork it, and fix it yourself (hoorah, now you’re in open source)
  4. 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.

#2 – [Part 1/2] Migrating to Symfony 4.0 with Flex

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.

#3 – [Part 2/2] Migrating to Symfony 4.0 with Flex

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!


Symfony 4 Tutorial Content Update

Symfony 4 has caused me a few headaches this week. In between the usual site work, I’ve been tackling a noticeable up-tick in support requests regarding video content.

There are a number of reasons why this is, some of my own making.

Anyway, though I had planned to work on finishing each of the currently in-progress courses, I am instead switching to updating every existing Symfony related course on the site to use Symfony 4.

I’m honestly not sure how much work this will involve at this stage. I’m expecting it to take a few human days in total, which I unfortunately don’t have in one large block.

What this will mean is for each course I will pull the code from GitHub, and add a new branch, or branches, to enable support for Symfony 4.

I don’t expect, nor plan to have to update every video.

I do expect to have to record some new video content around updating some of the bigger projects.

I’m going to work on the courses based on the volume I’ve been receiving in support requests.

I’ll know and share more on this next week.

Video Update

This week saw three new videos added to the site.

#1 – Simple Backup Shell Script Linux

Backing stuff up is a real chore.

During development it’s not that big of a deal. Sure, if we accidentally destroy the DB it *might* be a pain, but it’s unlikely to cost us our jobs, or make national news (or, at least, hackernews).

Once we hit production however, backups are up there with the toppest of top priorities.

I guess we could do manual backups. It’s a good way to waste 30 minutes every day by following some regimented process.

A better way is to delegate to our robotic helper: the computer.

In this video we cover a basic but “good enough” (for me, at least) method of backing up pretty much anything, and keeping only the last X backups (where X may be 7 days for example).

We’ll cover how to write a backup script using Bash shell scripting, and how to automate running that script using a cronjob.

#2 – How to change the DB with a Phoenix Migration

Most every application I work on involves the database in some way.

When starting a fresh application it’s fairly easy to remember how and why the database schema ended up the way it is.

Then, after chopping and changing between four other projects, I come back to this “small” project and I’ve forgotten everything about it. Including why one of the fields is inexplicably an integer when a boolean seems like it might have been a better choice.

Fortunately, if you’re using database migrations, you can easily check back through the Git logs and figure out just what was changing in the code when you made such an interesting schema change.

I once read, somewhere, that having database migrations is effectively like adding version control to your database. I’m not entirely convinced by this, but they are helpful, and have proved worthwhile for me over the last few years.

Whatever your opinion, database migrations are available to us right “out of the box” with Phoenix, so using them is a no-brainer.

#3 – Database Schema: What and Why

In the previous video we covered how to tell the database about our changes, be it adding a new table, editing an existing table, adding or updating an index, and so on.

In order to work with that table we must write some Elixir code that represents that table.

A schemer

This code is called a Schema.

In this video we cover how we can generate a Schema for any particular table, and what the generated code is doing for us, and why.

Once we have a Schema, in this case for our “Contact”, we can start adding new records to the database. And we will do just this by making use of the REPL.

There are some interesting extras included in this video, such as touching on the purpose of alias, working with dates and times, and our first encounter with Pattern Matching.

That’s a Wrap

Ok, that’s it from me this week.

Until next week, have a great weekend and happy coding.


This Is What My Brother Found When Trying Symfony

My brother recently tried to get up and running with Symfony. His theory was that learning Symfony (out of all the available PHP frameworks) seemed like a good idea, being that he could ask me questions as and when he got stuck.

I anticipated that he would have problems with the “typical” problem areas:

  • Security
  • Forms
  • Database interaction

And maybe, given it is his first time using the MVC pattern, some of the concepts around that area, too.

What I didn’t anticipate was that he couldn’t even get started.

He experienced so many issues with installing Symfony, that after a couple of hours effort – with essentially nothing to show for it – he gave up.

I could sense his frustration.

Here’s a guy who spends all day working with PHP (mainly WordPress I believe), and after 8+ hours at his desk, he comes home, grabs a bite to eat, and tries to improve his dev chops by learning about Symfony.

For most of us, time is extremely limited, and spending two hours sat at home after doing 8 or more at your desk is a pretty big ask.

To come away with nothing (except a bad experience) is, understandably, enough to put him off.

What follows may appear heretical:

I suggested he try Laravel.

The next evening he did, and was up and running in less than ten minutes.

This got me to wondering just how many others are suffering from a similar fate?

I am well aware that Symfony has a steep learning curve. Laravel does too, if you are brand new to modern PHP practices.

What I hadn’t factored in was just how difficult it is to get the “hello, world” of Symfony up and running.

Coincidentally, around the same time I got an email from a site member (thank you Parminder) stating the following:

Please note that I am not a php developer and I haven’t dabbled at all with it beyond setting up the server to work with the react/redux/sagas project on your site. I think it would be useful to include instructions in the intro to the course on setting up the server for someone who is not familiar with Symfony/backend and just wants to focus on the React/Redux material – this would probably help with course uptake I think.

And in response to my reply, Parminder also shared the following:

It did take me a while to set up the Symfony server for the course on my mac and it no doubt is a barrier for people taking up your course, which is a shame because your material is very good.

Ok, so after I had told Mr Worf to stand down from Red Alert, I started to give this problem some serious thought.

Firstly, up until very recently I had not envisaged anyone who isn’t a PHP developer would join the site.

I’ve been proven wrong on this point.

Secondly, I have seemingly forgotten to cover a fundamental part of working with Symfony – getting set up.

I’m going to remedy this with a forthcoming video series. I will try and cover set up from the three major operating system variants – Windows, Mac, and Linux.

I will offer some suggestions as to how I’ve worked, and touch upon Vagrant, Ansible, and Docker.

Another really good suggestion that I’ve had from Parminder is to spin up a standalone server which none-PHP devs, or those who do not wish to spend the time doing all the setup themselves, can access my server instead. This would likely be on a 24 hour cronjob to reset the DB, or similar. This is something I will implement moving forwards.

It pains me that Symfony is potentially losing new devs at the very top of the funnel. There’s so much good stuff to be had from using the Symfony framework. I’m not just talking about developer productivity, but the wider benefits like:

  • a well paying job
  • an enjoyable and (generally) intuitive stack to work from
  • a community filled with incredibly smart and friendly folk

I’ve said before that learning Symfony has changed my life (and yes, for the better :)), and it’s part of my mission to share that same joy with you.

I’d love to hear your experiences of what it was like getting started with Symfony.

Was there a specific issue you hit upon?

Has this process improved as you’ve used Symfony more and more, or is the pain still there?

Please hit reply and let me know.

Video Update

This week saw three new videos added to the site.

We are coming to the end of the first phase of the Wallpaper Website.

Firstly we start by cleaning up our project.

Swapping and changing between branches in order to see how to write code with and without tests starts off fairly easy, but as the underlying design diverges, the setup (fixtures etc) need altering in differing ways for both branches.

There’s other stuff to cover here, too, such as the naming of files (and associated tests). It sounds almost trivial, but I’m sure you’ve experienced occasions when writing code where the names of things has started to feel… not quite right 🙂

Housekeeping is an important, if underappreciated aspect of the lives of us as developers.

In the un-tested approach we added in a nice little preview snippet which allowed us to see our existing uploaded wallpaper image when going to the Update screen.

We’re going to add the same functionality into our tested version, but we won’t be able to directly test the template. Is this a problem?

Finally we wrap up the test-driven approach to Wallpaper Updates. We cover not just the “happy path”, but two potential sources of bugs in our form setup.

This is really the major benefit of writing tests, as far as I am concerned. They make you think about the bad times as much as the good. It sounds very pessimistic, but 80% of the headaches I have as a developer stem from having not given enough thoughtful consideration to what might happen if things don’t go according to plan.

All we have left to do now is add in a tested approach to Deleting wallpapers (and their associated uploaded image files), and adding a little security. After all, we don’t want just any Tom, Dick, or Harry accessing our Admin panel.

That just about wraps up this week’s update. Thank you very much for reading, and I hope you have a great weekend.

Until next week, happy coding,


Symfony 3.3 Dependency Injection Example

Symfony 3.3 landed this week.

My most used addition so far has been the new Dependency Injection features.

Even though I’m not a huge fan of autowiring, I do very much like the new autoconfigure.

This is a cool new feature that allows the removal of tags from your service definitions.

Note that I use my services like this:

The important thing here is that stuff is split up.

What this means is that I could adopt the new approach in phases.

I started with the  event_subscriber service list, simply because that was the next thing I needed to work on.

If you don’t have a decent set of tests covering your services – and breaking said services would render you jobless – then please add tests before doing this.

Here’s my  services/event_subscriber.yml configuration before the change:

And after:

That big comment wasn’t added for the sake of this post either. That is for real.

I like Symfony *because* it is explicit.

Other people, I know, prefer what I consider a more magical approach. I like magic in real life. In code, I appreciate magic, but I need to know what’s going on underneath before I feel comfortable using it.

If all my services were in one giant  services.yml file, I would not use this approach. That’s my personal opinion anyway.

By the way, probably the most concise guide I have found on this topic has been “How to refactor to new Dependency Injection features in Symfony 3.3” by Tomáš Votruba.

Question Time

I would really appreciate it if you could hit reply, or leave a comment on the blog post to this one:

In a video tutorial series, do you care about seeing the Setup phase?

E.g. if the course was about using Symfony with Redis, how important is seeing Redis being setup and configured to you?

This would greatly help my video topics on a forthcoming course.

Thank you!

Video Update

This week there were 3 new videos added to the site.

Now that we have created a Symfony console command to find and import our wallpapers we are going to use Symfony’s console style guide to make it look nice.

Lets add Doctrine Fixtures Bundle to our project to provide a starting point for our Wallpaper and Category data. This is both useful, and easy to do.

With our Wallpaper and Category entities in place we can go ahead and create some starting data for each. Beware a few gotchas which we cover in this video.

As ever, thank you very much for being a part of, and have a great weekend.