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.


How I Fixed: \Swift_Message::newInstance() not found

I had a recent requirement to overwrite the Mailer  class provided as part of FOSUserBundle.

There’s a protected method in this class as follows:

Seems fairly straightforward.

Notice that PhpStorm sees nothing wrong with this method:

Being the lazy dev, I started by copy / pasting the entire contents of this class to form the basis of my own Mailer  implementation. Cue confusion:

I’ve used this  \Swift_Message::newInstance()  code before, so I know it works. A quick check of the Symfony docs, and the SwiftMailer docs both seemed to confirm that what I was trying to do was correct:

(I checked the docs for Symfony 3.2, 3.3, and 3.4)

I thought it was just PhpStorm being a bit weird, but then I ran my code and saw things like this:

Attempted to call an undefined method named “newInstance” of class “Swift_Message”.

Diving through the code did indeed seem to show no references to newInstance .

Quite odd.

Anyway, sending an email – whilst important – wasn’t super urgent, so I commented out the code and added it to my GitLab issues list.

Whilst browsing Twitter later that evening I noticed:

I then remembered that being hasty to try new and shiny things was probably the cause of my problems.

Sure enough it turned out I’m using  dev-master of SwiftMailer in my project. A quick glance of the changelog:

This looks like the culprit:

Fixing this is really simple:


And as is often the case, when the provided objects / methods are used properly, things do work 🙂

Update – There is already an open PR to fix this in the docs:

How I Fixed: Missing Headers on Response in Symfony 3 API

The first time this caught me out, I didn’t feel so bad. The second time – i.e. just now – I knew I had already solved this problem (on a different project), and found my urge to kill rising.

I wanted to  POST in some data, and if the resource is successfully created, then the response should contain a link – via a HTTP header – to the newly created resource.

Example PHP / Symfony 3 API controller action code snippet:

And from the front end, something like this:

Now, the interesting line here – from my point of view, at least – is the final line.

Because this is a newly created resource, I won’t know the ID unless the API tells me. In the Symfony controller action code, the routeRedirectView  will take care of this for me, adding on a Location header pointing to the new resource / record.

I want to grab the Location  from the Headers returned on the Response and by removing the part of the string that contains the URL, I can end up with the new resource ID. It’s brittle, but it works.

Only, sometimes it doesn’t work.

Excuse the formatting.

From JavaScript’s point of view, the Headers array is empty.

This leads to an enjoyable error: “Cannot read property ‘replace’ of null”.

Confusingly, however, from the Symfony profiler output from the very same request / response, I can see the header info is there:

Good times.

Ok, so the solution to this is really simple – when you know the answer.

Just expose the Location  header 🙂

After that, it all works as expected.

Have You Ever Used A Symfony Compiler Pass?

It’s been JavaScript, JavaScript, JavaScript for the past few weeks, so this week I thought I’d vary things up a little and, heck, cover a little Symfony 🙂

Yes, two new – dare I say – useful videos were added to CodeReviewVideos this week.

Lets go ahead and jump right into it.

First up we venture into the wonderful – and scary sounding – world of Compiler Passes. Now, this is one of those Symfony things that is really useful, but also something you’re unlikely to try until you’ve seen it working before. Ahh, the old catch 22. Not so bad if you work in a huge team of devs who all share knowledge (or you are particularly good at reverse engineering), but if you’re a lone wolf, or part of a smaller, less experienced team, things like this may completely pass you by.

To begin with, we start with a code smell that I saw recently when working with a client. This problematic code is fairly common, and isn’t specific to Symfony projects. You may even have it in your own projects:

Controller bloat.

This particularly issue starts off with an if  / else , which turns into an if  / elseif  / else , and within a few further iterations you’ve got this nasty conditional dominating the method. Actually in the code I was looking at, this was a common theme throughout multiple controllers, and multiple actions in each controller. It’s things like this that make people believe Symfony is hard, when in reality, this problem would follow you if you switched to Laravel, or Zend, or Slim, or any other.

We’ll use an example of having to convert an array of data into a variety of formats – CSV, XML, YAML, and so on.

To begin with, these various conversion strategies live inside our controller action.

In the first video we cover a simple way to start refactoring this code:

At this stage all we are doing is extracting the problem code from the controller. This is really easy to do, and can immediately start to reduce duplication, and increase code re-use.

Unfortunately this doesn’t actually solve the tight coupling problem. But sometimes, you know what? You don’t need too. Over engineered code can be just as painful to work with as sloppy code. It’s just a different kind of pain.

Anyway, on larger systems simply extracting code out like this may not give you the flexibility you need. For that we can use a technique that third party bundles use:

In this video we cover how to use a Symfony Compiler Pass to decouple the Conversion service we’ve created from the various conversion strategies (e.g. convert to YAML, convert to JSON, and so on).

Let’s imagine that you wanted to create a Symfony Bundle that you could then share with the world in order to help others who might need to convert arrays in the future. Whilst you might provide a variety of implementations out of the box – ConvertToJSON, ConvertToXML, and so on – you don’t want to be solely responsible for adding every possible implementation in the future.

Instead, you could allow users of your library to implement the expected interface, and then use a Symfony service Tag that tells your Conversion service to also include this custom converter that your library user has created.

There’s loads of uses for this approach, and honestly it’s easier to do than you might think. Much like a lot of Symfony concepts, actually 🙂

All of this weeks videos are free to watch, though I will be making the Compiler Pass video a Members Only video at the end of this month.

Until next week, take care and happy coding