I can imagine this blog post will leave developers with the feeling, that they read something very obvious. That’s reasonable. From a specific point of view at least. But my work life with (in the meantime) many different “Symfony developers” showed me, that I am by far not alone. I thought I understood Symfony Environments. I used to think the environments represent the different stages an application gets deployed to, or is used in.

Usually, when I find a new interesting tool, I leave a bookmark in my “Tools”-folder, forget it and after some months I’ll miss it… So I thought I start a series of blog posts of the tools I use as a reminder for myself and of course as suggestions for the reader. It was pretty quiet in this blog anyway :) mitmproxy mitmproxy (“Man-In-The-Middle proxy”, Github) is a small HTTP(s)-proxy, that allows you to observe, inspect and manipulate requests.

I tried to get Symfony running on HHVM 3.3, because 3.2 caused some annoying issues. However, 3.3 didn’t run out of the box neither, because now it refused to parse DIC-XMLs. I’ve found the solution in one ticket, that I cannot find anymore. I found the explanation in the “inconsistencies”-file instead. (7) Loading of external entities in the libxml extension is disabled by default for security reasons. It can be re-enabled on a per-protocol basis (file, http, compress.

With the upcoming Symfony 2.6 SSI support is directly built-in. For me this is pretty exciting, because it is the first merged PR, that is more than a minor addition, or bugfix. However, setting up nginx wasn’t that flawless at the end. More about that later in this post. server { server_name domain.tld www.domain.tld; root /var/www/project/web; location / { # try to serve file directly, fallback to app.php try_files $uri /app.

Disclaimer: I’ve written this post a while ago and I am not entirely sure how accurate it was the time I stopped proof-reading it. So take with care and always keep a backup. The information provided here might be outdated, or even wrong. I hope, it still helps someone getting rid of overly large SVN-repositories. Multi-project subversion repositories sound convenient at the first glance: Everything at one place and only one system to manage.