Starting in Symfony 2

This page is archived

We're keeping this page up as a courtesy to folks who may need to refer to old instructions. We don't plan to update this page.

Alternate resources

Get your first Symfony 2 project off on the right foot, with the right tools, best practices and tips. Learn how to get set up with Symfony and work with some major pieces, such as Composer, Routing, Controllers, and Doctrine.
Tutorials in this course
More information
In this course, we’re going to kick off your Symfony journey by building an events application. To sweeten the deal, you’ll also be mastering the most important concepts used across all frameworks and web apps in general, because Symfony builds on the shoulders of other giants. Through building with Symfony, you’ll also be learning general programming best practices. Through these tutorials, you will start a new project using Symfony 2, and explore the core areas, like routing, controllers, requests, responses and templating, along with a few additional tools like Doctrine. This first lesson gives a quick overview of what Symfony is and why you would use it.

If you'd like to learn Symfony 2 beyond what this introductory series offers, you should head over to KnpUniversity and check out their full catalog of Symfony 2 tutorials.

Additional resources

Symfony website

More information

In this lesson, we're going to get things all set up using Composer. If you are not familiar with Composer, you can watch the Wonderful World of Composer tutorial to get up to speed. Once we have Symfony installed, we'll take a tour of the directory structure, and then we'll get things set up to start developing our application with Git.

Apache Notes

If you’re using Apache instead of PHP 5.4's built-in web server, and you've downloaded the project to your Apache document root, then you can go to http://localhost and find your way to the config.php script at http://localhost/starwarsevents/web/config.php. The URL for your app will be http://localhost/starwarsevents/web/app_dev.php.

Fixing Permissions Issues

The easiest permissions fix is to add a little umask function to the top of 2 files. Pop open your project in your favorite editor (we love PhpStorm). Open up app/console and web/app_dev.php. You’ll see a little umask line there. Uncomment this:

#!/usr/bin/env php
<!--?php
umask(0000);
// ...

What the heck? The umask function makes it so that cache and logs files are created as 777 (world writable). Once you’re done, set the permissions on the two cache and logs directories:


$ chmod -R 777 app/cache/* app/logs/*
You shouldn’t have any more issues, but if you do, just set the permissions again.

This method can be a security issue if you’re deploying to a shared server. Check out Symfony’s installation chapter for details on other ways to setup your permissions.


Additional resources

Symfony website Symfony installation documentation Composer website
More information

A bundle is just a place for us to store related code. We might make an EventBundle directory for that feature, and a UserBundle where we build the registration and login stuff. You can put anything and everything into a bundle: PHP code, config, templates, CSS and cats. You can also put other people’s bundles into your project. A bundle in Symfony is similar to a plugin in other systems. In this lesson you're going to create your first bundle, an EventBundle, using the Symfony app console.

More information

When you need a new page, you always start by creating a route: a chunk of configuration that gives that page a URL. In Symfony, all routes are configured in just one file: app/config/routing.yml. Your route was generated automatically when you created the EventBundle. In this lesson we'll take a look at how this is working and explain basic routing concepts and route importing. We'll also dive into the _controller syntax, routing parameters, and controller arguments.

More information

When it comes to rendering a page, the application compares the URL against the routes until one matches, Symfony reads the _controller key and executes that function. The page you want to render is built in the function. Controller functions are dead-simple, and there’s just one big rule: it must return a Symfony Response object. In this lesson, we'll build our Response, take a look at JSON, and then render the template using the Symfony templating service.

More information

Getting down to the actual templates we want to render, we need to get a handle on Twig, a language that feels a lot like PHP, but was made specifically to be awesome at doing templating tasks, like looping, rendering other templates, and handling layouts. In this lesson, we'll go over the basic Twig tags, and extend a base layout to get our page looking the way we want.

Additional resources

Twig Templating

More information

Symfony doesn’t care about your database or the code you use to talk to it. Most people that use Symfony use a third-party database library called Doctrine. Doctrine maps rows and columns in your database to objects and properties in PHP. Imagine we have an Event object with name and location properties. If we tell Doctrine to save this object, it inserts a row into a table and puts the data on name and location columns. And when we query for the event, it puts the column data back onto the properties of an Event object. When using Doctrine you need to stop thinking about tables, and start thinking about PHP classes. In this lesson, you will create the Event Entity Class, and learn a little debugging trick.

Additional resources

Doctrine website

More information

In this lesson, you will start using Doctrine to insert and query a database. First, you need to actually create and configure the database. Once we have that all set up, you will query the database, and render the results with Twig.

Additional resources

Doctrine Project
Twig Templating

More information

We’re using the built-in PHP web server, and it’s awesome for development. But it only handles one request at a time, so unless you only ever want one visitor, we’re going to need something different. To see how this might look, we’ll invent a fake domain, events.l, and set it up to point to our project. I’ll use Apache, though it’s more and more common to use Nginx with PHP-FPM, because they’re lightning fast, but all the ideas are the same.

Additional resources

Symfony documentation: Configuring a Web Server

More information

Now that we have an event page, we need our app to let users create, view, update and delete events. In other words, we need a CRUD for the Event entity. We can use Doctrine to generate a CRUD for us, but when it does that we need to clean a few things up since we've already been doing work in there. We'll also take a look at how to tighten up the generated code.

Additional resources

Doctrine Project

More information

In this lesson, you'll use the assets:install command to get some nice CSS added to your application so we can make things look a little nicer.

More information

We've got our Twig template files, and in this lesson we're going to take a closer look at working with creating links with the Twig path function, and making our dates make sense of the Twig date filter.

Additional resources

Twig Templating

More information

We have the application looking a lot better, and now, to see things fleshed out a little more we're going to load fixtures, which are dummy data we put into the database. When we started the project, we downloaded the Symfony Standard edition—our pre-started project that came with Symfony and other tools like Doctrine. Unfortunately, it didn’t come with any tools for handling fixtures. To do this yourself, you're going to learn to use Composer and KnpBundles.com to take care of things.

More information

A fixture is just a PHP class that puts some stuff into the database. To get your dummy data set up, in this lesson, you'll write a fixture and then load it up.

More information

Autoloading is the magic that lets us use classes without needing to require or include the file that holds them first. An autoloader has a tricky job: given any class name, it needs to know the exact location of the file that holds that class. In many modern projects, including ours, Composer handles this for us, and there are two pieces to understanding how it figures out what file a class lives in. In this lesson we're going to get an overview of how directory structures and namespaces make autoloading work.

Additional resources

The Wonderful World of Composer

More information

In this lesson we'll going to look at a few shortcuts we can use in our controller, using the SensioFrameworkExtraBundle, which comes with the standard Symfony project. We're going to review how to use @Template rendering, annotations, and working with routes.

Additional resources

Symfony SensioFrameworkExtraBundle

More information

In this tutorial we're going to wrap things up by taking a look at some quick, simple tips for working with Twig. We're going to explain what GlobalVariables is, and then play with the block function and clean up some whitespace issues.

Additional resources

Twig Templating