In this PHP tutorial, you'll learn how Type Hinting can help you get better errors from PHP as you develop your application. You'll learn to debug errors and see how Type Hinting impacts the phrasing of the error messages you receive.
Additional resources
In this PHP tutorial, you'll learn how to use Constructors to set up objects and perform certain operations when a new object of this type is instantiated.
Additional resources
Constructors and Destructors (PHP Manual)
Explore more PHP tutorials
Starting in Symfony 2
CourseWelcome to Symfony
FreeIf 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
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
Symfony Bundles
FreeA 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.
Symfony Routing
FreeWhen 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.
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.
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
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
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
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
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
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.
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
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.
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.
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
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
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.