ensure that hardcoded filter formats are applied

[lsmith77]

fixes #78

also reduces some code duplication and removes some ugly interaction between the resolver and cache manager

[roderik]

I'm sorry, but this has to be reopened. We deployed this in our project and all hell broke loose :) Seems like my test case covered up a major flaw.

The test project is updated with a change that demonstrates the problem. the flaw in the test case was that there was a source image, with the same name with both jpg and png extension. I've modified the names and in the test cases where we change the format, the controller throws an exception stating: Source image not found in ""
This is because it cannot find the source image with the different extension.

[lsmith77]

it seems like there is a bit of a mess with the interaction between the cache manager, the resolver and the data loader. the data loaders have logic to look for files independent of their file extension, which is what we need here. i think this really needs some careful rethinking of the responsibilities of all of these classes and then making sure we use the right one in the right places .. not sure how soon i will get to this though :-/

can you open a new ticket for this please, referencing the old one?

[lsmith77]

actually what you are noticing is the a "security measure" to prevent conversion to arbitrary formats:

diff --git a/app/config/config.yml b/app/config/config.yml
index 449fb72..bea20a3 100755
--- a/app/config/config.yml
+++ b/app/config/config.yml
@@ -60,6 +60,7 @@ jms_security_extra:
     secure_all_services: false

 liip_imagine:
+    formats: [jpg, png]
     cache_prefix: uploads/cache
     driver:       gd
     #cache:                no_cache