Skip to main content

Basic Prototype App with Symfony3

The objective of this is to build a simple route, and controller that handles this entire “application.”

The components of this simple prototype are essentially a bunch of HTML pages with interaction hard-coded or baked into the twig templates. So the objective here is to build the structure such that building a new template is all that is required and the application will then pick it up.


  1. Separately a custom controller handles exception catching and 404 errors.
  2. Everything, including authentication/authorization can be “faked”
    1. Presumably you’d hide this behind HTTP-Basic or keep local only.

The Route

The Controller

How it Works

Now all you need to do is build your filenames to match and you can create template files that work out of the box.

Now your routes map to filenames, which for the purposes of a simple static HTML prototype makes things very easy for any designer or developer to add and work with:

Route (path) Template filename
/jake/home DemoBundle\Resources\views\Jake\home.html.twig
/auth/forgot-password DemoBundle\Resources\views\Auth\forgot-password.html.twig
/jake/dashboard DemoBundle\Resources\views\Jake\dashboard.html.twig

Improve Symfony3 cache/logs performance by environment

Tired of the permission errors with your cache/logs in a Vagrant environment? Me too!

After being mildly annoyed with having to manually delete /var/cache and /var/logs repeatedly during “local” development, I decided to brut force matters into my own hands and solve this little annoyance once and for all. Ironically, Symfony 3.3 is addressing some of this, so it may be obsolete by then, but in the meantime…

What are we doing here?

  1. Define cache and logs directories for a specific environment.
    1. Wouldn’t it be awesome if we could customize these as parameters in the FrameworkBundle? Yes, yes it would!
  2. Write a simple CacheCommand that overrides the default cache:clear
  3. PARTY!!!!

Customize your getCacheDir and getLogDir methods by your environment

In my case, I typically use Vagrant/Virtualbox for local development, and Docker containers/bitbucket-pipelines for “test” while Production is a variety/flavor of AWS EC2 instances which have some additional flare.

Write a CacheCommand you can love and cherish forever and ever


Now you can enjoy life and all references to cache:clear will run your new and improved command that will also work noticably faster in Vagrant development environments; thanks entirely to Benjamin Eberlei and his wonderful blog post.


cd /path/to/myapp && php bin/console cache:clear

API environment contextual responses with Symfony3 Subscribers for Dev vs. Non-Dev

According to the ideal 12 Factor App you want to store your configuration in the specific environment. This includes debugging, logging, and everything else your application does. When building an API, these days you want your response data to be JSON, unless you’re an XML holdout which case you’re still using XML. Regardless, while in production you want clear and concise error message responses that do not reveal too much information. However, outside of production you probably want a quick way to see at least the source file throwing the exception so you know where to begin without crawling logs for every iterative issue while in development. For this you’ll need your API response data to include some contextual debugging and/or exception information you normally wouldn’t want in your response. This is a perfect scenario for environment configuration, and Symfony has a great way we can handle this with an ExceptionSubscriber for “Dev” and for “Non-Dev” environments (in this example).

Here’s a brief breakdown of what we’re building:

  1. Service declaration for subscribing to exceptions in dev and default environments
  2. ExceptionSubscriber class that processes exceptions being thrown, and cleans up the response JSON (…and XML because we aren’t jerks).
  3. DevExceptionSubscriber that extends ExceptionSubscriber and adds some debug “stuff” to the response.

Declare the Default Service

Build ExceptionSubscriber


Extend ExceptionSubscriber for DevExceptionSubscriber

Here, we don’t filter any of the message content, so we can get the literal exception text thrown for exception classes we didn’t specifically write. This is particularly useful if we want to mask exceptions for invalid passwords so users cannot guess which usernames exist or not, and other business rule exceptions for Unauthorized or Access Denied messages where we don’t want to reveal too much.


In use, you’ll know see responses like this: