We all know how to clean the cache and how to install assets for a new bundle, we execute these command a billion time a month. Working with many different fellow Symfony developers I’m feeling that a lot of them are not taking full advantage of this wonderful tool, hence the need to share some tricks about this topic.

One command to rule them all

First al all, the king of all the tasks: help. This is really the only one you need to know, in order to master all the other commands and to discover how many useful things can a command do for you. It is surprising how many developers forget about the help command.

With the help command you can get a detailed explanation of any other command: arguments, options, usage examples. Use this command and it will really make your day. If you’re brave enough you can even stop reading now, you know enough to discover by yourself all I’m going to say to you.

Still here? Let’s move on then.

Debug commands

There are some commands that I usually use for debugging purpose:

• router:debug
• router:match (from sf 2.1)
• container:debug
• doctrine:mapping:info & doctrine:mongodb:mapping:info
• doctrine:migrations:status

router:debug and router:match are my favorites in this category. Every time I need to identify a controller from a route name or from a URL I use router:debug and router:match to get this information in about 0.1 seconds (quite fast, if you ask me). router:debug will list all the routes in the application or, if you pass a specific one as first argument, it will print out a lot of useful details for that route such as route class or, most important, the default parameters, which also contains the fully qualified name of the controller class. Cool, isn’t it ?

I also find very useful the *mapping:info commands, I usually use these tasks to check and debug my annotation syntax. I define or change an entity and then I run the info command to check my syntax. It is a good way to validate your annotations.

Generator commands

These are a bit less present in my daily workflow, but I think that they are worthy of a mention anyway. We have several generator commands:

• generate:bundle
• generate:doctrine:crud
• generate:doctrine:entities
• generate:doctrine:entity
• generate:doctrine:form

Generate:bundle is, by far, the one I use the most here, I think that I’ve never implemented a bundle without this command.

Generating forms and cruds can save a lot of time, you should give these two commands a shot. Especially for the form classes it can be really useful to have an auto generated base to tweak and tune.

Again, help command is your best friend here, with it you can find all the available options you can use.

External tools

If you really love the cli as I do, there are at least two tools that you should take a look at:

• ServerGroveShellAliasBundle
• Oh my zsh

The first is not really an external tool, it is just a Symfony2 bundle, that will generate a list of shell aliases that you can use to speed up your typing. A good set of well known aliases can really make you faster, but many of us are lazy enough to not define a shell alias even if we type it 100 times per hour. This bundle will do it for you, I think it is worthy of a try.

“Oh my zsh” is, quoting the author, “A handful of functions, auto-complete helpers, and stuff that makes you shout…OH MY ZSHELL!”. I really love this project and I have been using this in the last year. It has a lot of plugins that you can activate or deactivate, included an autocomplete plugin for Symfony2.

I think that’s all for now, I hope this will help you to be a little more productive in the future.

I had to implement an auto login mechanism to let users authenticate via a query string parameter and I want to share with you what I’ve learned.

First of all, let’s face it: having an auto login link is not the best way to preserve your user’s privacy, I know.

I would like to put aside any security concern (pretty weird for a post about security layer uh?), to concentrate just on the Symfony security component.

I’m not even showing any code in this post, but the concept you’ll read here are valid for every custom authentication provider you’ll need.

Symfony security layer is based on two steps:

• Authentication
• Authorization

In this post we’re talking about authentication, and we’ll leave the authorization for another post.

The components

Authorization is quite simple, once you have the big picture in mind and you get used to the terminology. Three main actors are involved in the authentication process:

• A Token
• A Listener
• An Authentication Provider

The Token

The token is probably the most confusing piece, but its role is fundamental and afterall its job is quite simple. Think of the token as a simple container: the token retains the user’s credentials present in the request and, after the authentication, the authenticated user itself.

The security system uses the token to move these information through the involved components.

The listener

The listener is the glue between the request and the authentication provider.

Its job is to retrieve the user’s authentication parameters (usually from the request), create a token and try to authenticate it through the authentication manager (which will delegate the authentication process to a set of compatible authentication providers). If the authentication manager returns an authenticated token, the listener stores it in the security context.

The authentication provider

The authentication provider is the real boss here. It verifies the user’s authentication information stored in the token and returns an authenticated token which contains the authenticated user.

As you can have many different tokens and many different authentication providers, authentication manager must know which provider is capable of handling a particular token. Here comes to play the AuthenticationProviderInterface which contains an authenticate and a support method. The support method will belp the authentication provider to decide which provider is able to authenticate a particular token.

The big picture

How does these three objects work together and how can the security system know anything about these?

You read in the documentation (you read the doc, right?) that security is a two steps process: authentication and authorization. Authentication is managed by a Firewall. When the firewall is activated, it calls the listeners (we talked about them above): any of the configured listeners could be able to authenticate a user.

Unfortunately tying firewall and listeners together is not so easy, because you can have different firewalls to secure different parts of your application, depending on your configuration.

To solve this you need to implement a special factory class, that implements SecurityFactoryInterface that will create the needed DIC entries.

This is pretty much all you need to know to implement your custom authentication provider.

Auto login

I haven’t written anything about my implementation of the auto login feature. The reaons is the implementation has nothing magic in it, it’s quite simple and it doesn’t add so much value to the explanation.

If you’re looking for code, there is a great cookbook about how to implement a custom authentication provider. You can use that as a good starting point for your implementation. While learning how all these classes work together, I found very helpful to look at the code and in particular at the RememberMeListener.

That said, if you’d like to read about my implementation, I can share it in another post about this topic, or maybe plan a screencast about it.

So you need to implement an API, maybe you want to be able to interact with some mobile application or just let some third party application to do cool stuff with your data. You’ve already read about all different architectures and REST is your final choice.

If you are reading this post, chances are that you want to implement your REST server using Symfony2 (or at least PHP). If so, our screencast will point you in the right direction (hopefully).

The main point of building a REST server with Symfony2 is FOSRestBundle. This bundle will take care of most of the boring staff for you, and will help you implementing a REST web service in the right way. Though it doesn’t all the work for you, it is certainly a good starting point that you should take in consideration.

We will guide you through the usage of this bundle implementing a complete CRUD for a resource.

Implementing an API also mean testing it, be able to debug it and provide good documentation for your clients. In our tutorial we will show you a handful of tools to effectively perform these tasks as well.

This screencast is still a work in progress, you’re in time to discuss with us what you’d like to see in it.

Any fancy ideas ? we’re open for suggestion.

Here it comes gaufrette: a filesystem abstraction library that allows you to store your medias everywhere you need to, using a unified API.

As we all know, web applications are growing creatures and requirements are far from defined when you start a new project. Our job, as developers, is to be able to quickly and efficiently respond to changes. One of the best choice that you can do about filesystem storage is gaufrette.

Gaufrette offers a simple object-oriented API to abstract both filesystems and files. This means that you get the same interface, no matter if your filesystem is local, on Amazon S3, or anywhere else. With gaufrette you’re storing your files somewhere, the library takes care of the rest.

This is really crucial, because at the beginning of a project you don’t want to think about “where”: as you’re already busy building business logic of your application, you just want to store files. But at some point you may want to switch from your local filesystem to some kind of cloud. With Gaufrette this switch is just a matter of configurations, whereas without it you’d have to surf around your application code hoping to find all the places you save and reference files.

With Gaufrette you can be completely storage agnostic. Sounds great uh?

All the magic is done by adapters. Your application interacts with Gaufrette, Gaufrette interacts with any filesystem through an adapter. Swap an adapter with another and you’ll end up saving files to a remote cloud instead of the local filesystem. The library ships with a rich set of ready to use adapters such as (this is not a complete list):

• AmazonS3
• RackspaceCloudFiles
• Ftp
• Dropbox

and more. And if you need to work with some exotic filesystem, you can always write your own adapter implementing the Adapter interface.

Gaufrette is a library by KnpLabs, if you want to know everything about this great piece of code you can read a post about it from their blog or the documentation at the github repository.

If you want to learn more about how to upload a file with Symfony you can check out our screencast that will introduce you to the main concepts of file upload handling and to VichUploaderBundle which also offers a way to to handle uploads with Gaufrette.

Stay tuned, in the next post I’ll show some example of how this library works.

I thought that every single Symfony developers knows about knpbundle, but working experiences with different teams show me that this is not always the truth, and that’s why I’m writing this post: to spread the voice.

As said every single Symfony functionality comes from a bundle. The Standard Edition comes with a few pre-installed bundles, so this may not be obvious to new users. As a bonus from the decoupled architecture of the framework, every new functionality that you need to implement can be (and should be) a bundle. Thanks to this level of expandability the Symfony developers community is generating a lot of bundles.

Find the right bundle for the right job could be a pain, and here comes knpbundles.com

The website let you search over a catalog of about 1600 bundles (and counting) from the community, but it also has a score algorithm that tries to help you choosing the best one for your needs. Chances are that the higher the score, the better the bundle.

Knpbundles integrates with github and calculates the score against a number of factors such as:

• Github followers
• length of README file
• Travis result
• composer package definition

and much more. When you find different bundles for the same task, you’ll usually want to get the one with the higher score.
You can also have a look at the evolution of the bundle, at its developers, at its number of recommendations.

If you are looking for a bundle, Knpbundles is the way to go.
If you are a bundle developer don’t forget to register your own bundle so it can be found by the rest of the world.

• Install bootstrap in you Symfony application
• Load it using assetic
• Compile bootstrap LESS files with lessphp

Let’s start with a fresh Symfony2.1 application, the best way to create a new application is using composer:

1

composer create-project symfony/framework-standard-edition bootstrapdemo 2.1.x-dev

After that, we need to install bootstrap within our application, again we will use composer to download and install the source code. Bootstrap doesn’t have a composer package so we’ll need a little bit of extra work to get it done.

Add the repository definition to your composer.json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

"repositories": [
        {
            "type": "package",
            "package": {
                "name": "twitter/bootstrap",
                "version": "2.1.0",
                "source": {
                    "type": "git",
                    "url": "https://github.com/twitter/bootstrap",
                    "reference": "v2.1.0"
                }
            }
        }
    ]

and then, add bootstrap as a dependency as usual:

1

"twitter/bootstrap": "v2.1.0"

Note:
Mind that we are not installing the latest bootstrap version, but 2.1.0 because of a known issue with lessphp. By the time you read, this could be solved, you should try using “master” instead of “2.1.0″ and see how it goes

Last but not least, we need lessphp in order to be able to compile our boostrap .less files, let’s add to our composer.json:

1

"leafo/lessphp": "dev-master"

Now we can run:

1

composer update twitter/bootstrap leafo/lessphp

This will download needed sources. Fair enough, it’s time to start writing some Symfony code, isn’t it?

Assets management with assetic is well documented in this cookbook, if you are completely new to it I’ll suggest to start from there.

Assetic ships whit a lot of useful filters, we’ll use LessphpFilter, so we need to configure it (some filters require configuration params, some don’t) in config.yml, find assetic section and add:

1
2
3
4

filters:
        lessphp:
            file: %kernel.root_dir%/../vendor/leafo/lessphp/lessc.inc.php
            apply_to: "\.less$"

This will define lessphp path, and will apply the filter to all our .less files. This filter is mandatory for less files, so I usually apply it to all .less files by default. After that, the last thing we need is to include bootstrap in main template:

1
2
3

{% stylesheets '%kernel.root_dir%/../vendor/twitter/bootstrap/less/bootstrap.less' %}
 
{% endstylesheets %}

Nothing special here, just mind that we are using absolute path for boostrap file, this allows us to work with vendor files, and that we are not specifying lessphp filter since it will be applied by default for .less files.

And that’s all.

Assetic is a really powerful tool and it can really improve the way you manage and optimize your assets, we are planning to release a premium screencast about advanced assetic usage with twig, if you think you’ll love it give us some feedback and let us know what you should see in it.

Happy coding.

You should know now what a bundle is. If you don’t, have a look at the official documentation.

We love bundles and you should too! Bundles are the way to share code with other developers and through different applications. Our motto is “more bundles for everyone”. Every single day, in your developer life, you are going to start a new feature, check for a bundle that cover it, and this world will be a better place

FOSUserBundle is the bundle for you if your application need to have some user management stuff such as registration flows, confirmation emails, reset password procedures. More or less all the common needs of a standard web app are satisfied.
As many other bundles from FriendsOfSymfony, FOSUserBundle has a great code base, which is really flexible and reliable at the same time. It works well with doctrine, propel, mongo and couchdb and the entire bundle if unit tested.

If you need to, you will be able to customize its core functionalities extending its templates, controllers or the services it defines. FOSUserBundle has a very thorough documentation that will guide you over your customization process. You can also make it work with other authentication mechanisms. If you want to know how to integrate FOSFacebookBundle and FOSUserBundle we have recorded a screencast for you!

We can’t cover all the functionality of the bundle here (it would take several posts for it) but we want to warmly recommend to use this bundle in your next application. If you are looking for best practices and good habits, you should really use FOSUserBundle for managing users.

What do you think about it? Did you know this bundle? Are you using it or are you planning to do in the future? Would you like a premium detailed screencast about its functionalities? Let us know using our uservoice page!

If you have written even the smallest Symfony2 app, you surely have perused the Symfony2 official documentation.

If you haven’t had the chance of glancing over the cookbook, you should check it out now: it’s a collection of useful recipes and quick tutorials to solve common problems, written in a practical and direct way.

At Screenfony we believe screencasts are a quick way to see things in action. So -we thought- why not give these recipes a little “video” twist!?

That’s it! We are planning to support the official Symfony2 cookbook producing an alternate way of getting the point of each recipe. Often times seeing it in action is better than reading it!

If you are the kind of person who prefers PDF’s this won’t be a shocking news, but we believe that if you are following this blog you will probably like it!

As we record the video recipes we will try to add some “Screenfony juice”: sometimes we might add our point of view on the topic, sometimes we might make some obscure points more clear, sometimes we could end up creating a completely new recipe!

Each video recipe will be a free Symfony2 tutorial available on our YouTube channel. It’s probably premature now, but it would be nice if they could be linked directly from the documentation.

If you like the whole idea of video recipes, let us know which are your favourite: we will happily give priority to the most requested!

Check the first two recipes on our YouTube channel, the “community edition” series has begun!

Keep following our blog and subscribe to our mailing list to know the latest news on our project!

Stay tuned!

Communities are the hearth of every open source, symfony makes no exception. With Screenfony we are trying to make a living out of video tutorials for Symfony2, but we feel the importance of contributing back to the community.

For this reason we setup the official Screenfony YouTube channel where you’ll find all our community edition Symfony video tutorials, which will be published for free.

We’ll talk more about the single videos as we release them, we don’t want to spoil the fun.
As usual we appreciate your suggestions and advices.

Our Youtube channel will collect the best tutorials, screencasts and presentation videos around the web: if you find something interesting around, let us know and we’ll add it to our playlists!

See you soon!

Around the web you can find many good posts about deploying symfony application with capifony. Screenfony is about screencasts so that’s what we aim to share in this blog.
Our first screencast mention is for Moises Gallego and his good video introduction to capifony. He shared it with us and we want to share it with you. In his post you will also find a slidshare presentation.
Both the screencast and the presentation are in Spanish. Would you like to have them in English? Let us know in the comments!

At Screenfony we follow the community efforts to spread knowledge about Symfony and related stuff, for this reason we want to use this blog also to collect useful resources on the net. If you have created a screencast (or a post or a slideshare presentation) about symfony share it with us, we will promote your content on this blog.