Rebase your database migrations to a single class file quickly

While developing, Doctrine Migrations can quickly become obsolete as you adjust your schema in the early stages of development. Nevertheless, Migrations are still a vital part of properly building compatibility for deployments. However, to consolidate and avoid having several (or in my case dozens) Migration Versions before you’ve got a stable schema, I’ve found it very useful to “rebase” my migrations to a single file.

I also try to keep my non entity driven schemas in a separate file, typically Version0.php. All of my recent development work has been on Symfony 2.7 so I have a modified sessions table I use for PDO session management (that’s a separate debate we can have later). This particular file I want to ignore when running this script so I’m left with two consolidated files for my entire schema:

And last but not least, this simply bash script calls upon a file config in the same source directory that has simple configuration values:


Simply run the bash script above and your Migrations files will be cleaned up entirely. You’ll of course want to rebuild your database as well so everything is in sync.

Symfony Tools

This is one script available in a collection of simple scripts I’ve written to help my development

Throw Exception based on Accept Header

Symfony has a wonderful onKernelException event that we can expose in an Event Listener to properly handle exceptions in our applications.

In one particular use case, we want to handle JSON and XML responses for our exceptions that are thrown via our API. In this case, we need to format and render our exception based on the Accept Header of the initial request.

This is handled in two simple steps:

  1. An ApiExceptionListener class that processes the onKernelException event.
  2. A service declaration that tells the Symfony kernel about our Event Listener.

The Exception Listener

We need to be careful above not to check the Accept header for XML because some browsers will give a false positive on this. As such, we check instead for an AJAX request that was not JSON, which thus must be XML.

Defining the service

Sample Response

Now that we’ve got this setup, our exception messages are nice and clean:


Symfony3 Restructuring

Symfony3 is coming soon and with it a handful of wonderful changes and restructuring to the core directory structure of a symfony app.

The new directory structure has a number of benefits, all of which are minor and may require minimal changes to your workflow.


phpunit can now be run from the project root without having to explicitly specify the path of the configuration file.

Binary Executables

All binary executable files are now all located in a single location – the bin directory.

This simplifies things also so on a *NIX machine you can configure your $PATH to simplify calling repeatable commands.

A new /var directory

The new /var directory contains the files to which the system writes data to during the course of its operation; this replaces/moves cache and logs from the app directory.

This also makes it easier to add permissions, the entire /var directory should be writable by your webserver (apache, nginx, etc).

Symfony requirements check

Running symfony_requirements will output mandatory & optional environment configurations.


Most of the credit for this post belongs to justAnil @ StackOverflow for his amazing write-up.