Liipimaginebundle: Images not resolving when browser caching is enabled

Created on 10 Jan 2020  路  16Comments  路  Source: liip/LiipImagineBundle

Hello,

when I enable browser caching using nginx

location ~* .(js|jpg|jpeg|gif|png|css|tgz|gz|rar|bz2|doc|pdf|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|woff|woff2|svg)$ {
expires 30d;
add_header Pragma "public";
add_header Cache-Control "public";
}

images are not resolving(only resolving when I open developer tools and tick "Disable cache while dev tools is open" in Chrome)

image

Most helpful comment

I share my experience in case it can help someone. In my case, I use an nginx web server, the configuration was :

   location ~*  \.(jpg|jpeg|png|gif|ico)$ {
        expires 365d;
        log_not_found off;
        access_log off;
    }

The thing is that with such a configuration, the image is not found and nginx does not try to go any further. I added : try_files $uri $uri/ /index.php?$query_string; for liip to be able to generate the cache as it is supposed to do. With this new line, if the image is not present, index.php is hit with the query string that corresponds to the image and liip can do its job.

My server configuration is then :

   location ~*  \.(jpg|jpeg|png|gif|ico)$ {
        expires 365d;
        log_not_found off;
        access_log off;
        try_files $uri $uri/ /index.php?$query_string;
    }

You can check :

  • /vendor/liip/imagine-bundle/Resources/config/routing.yaml
  • /vendor/liip/imagine-bundle/Controller/ImagineController.php

I am nor symfony, nor nginx guru, therefore, there can be some better way to achieve that.

PS : it works on symfony 5 with LiipImagineBundle 2.3

All 16 comments

Hi @bogdandovgopol and thanks for your report! Which version of the bundle are you using?

I'm using version ^2.3

is this bundle dead?

is this bundle dead?

no, but it is open source and people work on it as they find time. if you need payed support with strict response time, you should ask for that...

the question you ask is very specific and might be an unlucky interaction between nginx and how the imagine bundle works. or something that is not related to the bundle. afaik the first time you request an image, a redirect happens to generate that image. but in the end, assuming you do see an image on a first page load, i don't see why the browser would cache a broken response. did you debug the process to see what goes wrong?

No I don't need any special support. It just feels like this bundle is dead and not supported, no one is giving any comments in "issues" section. I'll look at this later, since I had to uninstall this bundle and do it myself and my way.

Btw. this guy probably has the same issue #1252 , but again no response.

Recently we prioritised rolling out Symfony5. We're an open source project with over 100 issues and few maintainers. Triaging issues takes time, especially since we also have paid work to do. This bundle is not dead, but unless it's an urgent or critical issue we might not get to it in a timely manner.

I have the same problem and I just made the change of driver from GD to imagick and it still does not solve the problem of general image.

The problem seems to be FilterService.php where the getUrlOfFilteredImage method returns the url that the image was located but only generates the url but does not copy the image with the new filter

@michellesanver
Performing a flow check everything goes to CacheManager->generateUrl () returns the URL that the new image filter was generated. but $ filterUrl = $ this->router->generate ('liip_imagine_filter', $params, $referenceType); only the URL returns but the ImagineController::filterAction controller method is never executed then the error could be found on the router liip_imagine_filter.

that only the new url returns but never perform the filter process to the new image at: $ this->filterService->getUrlOfFilteredImage ($path, $filter, $resolve);

It took almost two days for me to debug the same crap. I'm so surprised to see so many people have the same problem here.

There is no such settings as verbose mode for logging & debugging, I'm quite clueless, such a waste of time.

Recently we prioritised rolling out Symfony5. We're an open source project with over 100 issues and few maintainers. Triaging issues takes time, especially since we also have paid work to do. This bundle is not dead, but unless it's an urgent or critical issue we might not get to it in a timely manner.

This IS a critical issue. Browser caching is something that should be enabled on every webserver by default and the bundle is clearly not working with browser caching enabled. Please provide us with an update on this problem at the very least, that way I can decide if I should create a PR for this myself.

As @dbu and @michellesanver said, it's an open source project that people work on it when they can. They don't get paid for that.

Having that in mind, I recommend to instead of ranting, using that time to create a reproducer to be able to see that bug or even create a PR, that would be really helpful for someone else to try to debug the problem.

Have you tried to tried change the response code?

liip_imagine:
    controller:
        redirect_response_code: 302

Browsers usually store 301 responses.

I share my experience in case it can help someone. In my case, I use an nginx web server, the configuration was :

   location ~*  \.(jpg|jpeg|png|gif|ico)$ {
        expires 365d;
        log_not_found off;
        access_log off;
    }

The thing is that with such a configuration, the image is not found and nginx does not try to go any further. I added : try_files $uri $uri/ /index.php?$query_string; for liip to be able to generate the cache as it is supposed to do. With this new line, if the image is not present, index.php is hit with the query string that corresponds to the image and liip can do its job.

My server configuration is then :

   location ~*  \.(jpg|jpeg|png|gif|ico)$ {
        expires 365d;
        log_not_found off;
        access_log off;
        try_files $uri $uri/ /index.php?$query_string;
    }

You can check :

  • /vendor/liip/imagine-bundle/Resources/config/routing.yaml
  • /vendor/liip/imagine-bundle/Controller/ImagineController.php

I am nor symfony, nor nginx guru, therefore, there can be some better way to achieve that.

PS : it works on symfony 5 with LiipImagineBundle 2.3

Seems, that the issue is related to routing.

Console command bin/console debug:router shows routes from routing.yaml

  liip_imagine_filter_runtime   GET        ANY      ANY    /media/cache/resolve/{filter}/rc/{hash}/{path}  
  liip_imagine_filter           GET        ANY      ANY    /media/cache/resolve/{filter}/{path}            

But in Frontend, the Profiler doesn't show this routes

@ChristopheFerreboeuf 's solution didn't work for me (with ddev + nginx-fpm)

I needed to switch to use apache 2.4

I put a specific configuration only for resolving before static files caching directive:

    # bypass thumbs cache image files
    location ~ ^/media/cache/resolve {
      expires 1M;
      access_log off;
      add_header Cache-Control "public";
      try_files $uri $uri/ /index.php?$query_string;
    }

    location ~* .(js|jpg|jpeg|gif|png|css|tgz|gz|rar|bz2|doc|pdf|ppt|tar|wav|bmp|rtf|swf|ico|flv|txt|woff|woff2|svg)$ {
        expires 30d;
        add_header Pragma "public";
        add_header Cache-Control "public";
    }
Was this page helpful?
0 / 5 - 0 ratings