This is less a blog post and more a personal attack on the original author of the bit of code in Symfony that reads in the filters.yml file. Firstly, you're a god damned idiot, secondly, you're and even bigger idiot.
Here's a very short backstory to this attack, in Symfony to enable a filter you place it in the filters.yml file which looks something like:
rendering: ~
security: ~
cache: ~
common: ~
execution: ~
With a first glance one would deduce that the order the filters get executed would in fact be from top to bottom. However, you'd be dead-ass wrong. They are, however, executed in reverse order. Now, keep in mind that this is not documented in any part of the admittedly great Symfony documentation.
How did I run across this little tid-bit of assholery(it's a word now)? I was writing a filter for SyntaxHighlighter that would look for the appropriate class and add the brush for that syntax. I couldn't figure out why even though my filter was correctly adding the javascript to the response, meaning it showed up in Symfony's list of added javascripts in the log it wasn't being added to the page. This is because the built-in sfCommonFilter (seen above with the common: ~ in filters.yml) is what actually adds javascript and stylesheets added with sfWebResponse::addJavascript. The problem, as you might have deduced is that the filters.yml file says it is executed second to last but is, in fact, executed second so the recommended place to put your filters by the Symfony docs (after the security filter) will cause any custom filter that adds javascript to do essentially nothing.
In the end I got it fixed and it works pretty well for 6 lines of code, I will end my rant with this for whomever developed that frustrating bit of code.
array_reverse