Liipimaginebundle: Image not generated and "resolve" in path

Created on 5 Sep 2016  路  42Comments  路  Source: liip/LiipImagineBundle

Hello,
It seems that LiipImagineBundle does not create the cached image and there is a "resolve" in the path returned by imagine_filter.

Here the twig code : < img src="{{ asset('img/gallery/p1/test2.jpg') | imagine_filter('my_thumb') }}" />
And the path returned: http://localhost/app_dev.php/media/cache/resolve/my_thumb/img/gallery/p1/test2.jpg

If I want to generate an image, I have to manually create the image using: app/console liip:imagine:cache:resolve relative/path/to/image.jpg relative/path/to/image2.jpg --filters=my_thumb --filters=thumbnail_default

How can I automatically generate the image? Thanks

Most helpful comment

@cedricziel Don't ever be embarrassed to explain the resolution to your issue, regardless of the origin of the malfunction. The absolute rock-stars of our field make the same mistakes as everyone else, and sharing it only serves to help others avoid banging their head against the wall suffering the same misconfiguration.

(If you ever happen upon a GitHub issue tracker whose members poke fun at your misfortunate oversights, it'd be a sensible reaction to simply leave that project and discontinue any additional contributions, as it will surely implode and die out, as the only remaining members become the elite a**s who talk down to and belittle their user base. I don't have any time for people with such attitudes.)

All 42 comments

What resolver are you using? I'm having the same issues in just the production environment and I'm having a hard time to debug it..

Edit: I'm _not_ using the webpath resolver, that's why it's suspicous for me..

I guess I am using default resolver so it might be cacheResolver

@phong-steph CacheResolver is a decorator for another resolver implementation, so if you are using that, you are also using another cache resolver as well. Can you share you configuration YAML?

@cedricziel An initial page request will return the resolve path, regardless of the data loader or cache resolver, as transformed images haven't been created yet, and therefore obviously haven't been cached. Alternately, subsequent request should be resolved.

Ok thank you for your anwer.

Here is my LiipImagineBundle config:

liip_imagine:
    resolvers:
       default:
          web_path: ~
    filter_sets:
        cache: ~
        my_thumb:
            quality: 20

I'm also having this problem, but only for some filter_sets.

filter_sets:
    ash_small:
        data_loader: aws_loader
        cache: aws
        filters:
            thumbnail: { size: [120, 90], mode: outbound }

The above is my config file setup. I'm working with Symfony CMF Blocks and if I use the default slideshow_medium filter, the filter works OK. But if I use my filter up above, it doesn't work

How can I automatically generate the image? Thanks

So, your config is simple and quite standard. There is nothing about it that would advice me as to why you are experiencing issues. Are you sure images are not being generated? The resolve string should be in the URL on the first request...

Sorry for not coming back to this earlier. nginx shortcircuited requests to assets to the filesystem which resulted in 404s and thus not generating correct URLs even on second load.

Removing the shortcurcuiting resolved my issue. Plus it's a little embarassing :)

@cedricziel Don't ever be embarrassed to explain the resolution to your issue, regardless of the origin of the malfunction. The absolute rock-stars of our field make the same mistakes as everyone else, and sharing it only serves to help others avoid banging their head against the wall suffering the same misconfiguration.

(If you ever happen upon a GitHub issue tracker whose members poke fun at your misfortunate oversights, it'd be a sensible reaction to simply leave that project and discontinue any additional contributions, as it will surely implode and die out, as the only remaining members become the elite a**s who talk down to and belittle their user base. I don't have any time for people with such attitudes.)

Hey @robfrawley , thank you so much for encouraging a proper and open communication style on issues. Reading your answer made me smile and boosts confidence! :)

Did you solve your problems as well, @phong-steph ? Maybe - and only mabye - you're bitten by the same problem. :)

Hello,

Yep it solved it! thank you ;)

I'm having the same problem.
Didn't find any solution yet.

liip_imagine:
    # configure resolvers
    resolvers:
        # setup the default resolver
        default:
            # use the default web path
            web_path: ~
    # your filter sets are defined here
    filter_sets:
        # use the default cache configuration
        cache: ~
        # the name of the "filter set"
        backend_thumb:
            # adjust the image quality to 75%
            quality: 75
            # list of transformations to apply (the "filters")
            filters:
                # create a thumbnail: set size to 120x90 and use the "outbound" mode
                # to crop the image when the size ratio of the input differs
                thumbnail: { size : [120, 90], mode : outbound }

My twig layout:

<img src="{{ item.mediaItem.webpath() | imagine_filter('lightbox_small') }}" itemprop="thumbnail" alt="{{ item.mediaItem.title }}" />

Result in HTML
<img src="http://xxx.dev/media/cache/resolve/lightbox_small/src/xxx/xxx.jpg" itemprop="thumbnail" alt="zonnepaneel4-large">

Can somebody help me?

I had the same problem. Just launch :
php bin/console liip:imagine:cache:resolve relative/path/to/image1.jpg --filters=yourfilter
You will get the error message. In my case, I was on a new server with GD not installed.

Hi @pascalbeynel, that is a temporary solution for one image.
But I have hundreds of images...

Anybody else knows a solution that fixes it?

@jeroendesloovere The idea is to test with one image. This way you can have the error detail why your thumbnails are not generated.

Well, that is the strange thing.
My config.yml
schermafbeelding 2017-03-20 om 15 55 23

When I execute:
php app/console liip:imagine:cache:resolve Source/01/schermafbeelding-2017-03-16-om-14-31-17.png --filters=backend_thumb

The image is created.
But when I refresh the page, the image url is still:
<img src="http://xxx/media/cache/resolve/lightbox_small/src/Frontend/Files/MediaLibrary/Source/01/istock-000001779902small.jpg" itemprop="thumbnail" alt="istock-000001779902small">

Do you have any further tips @pascalbeynel ?

@jeroendesloovere Hm, probably I have same issue. Are you using nginx?

I fixed it by moving

_liip_imagine:
    resource: "@LiipImagineBundle/Resources/config/routing.xml"

To the top in app/config/routing.yml

@jeroendesloovere Tried this, not solved my issue. Are you using nginx?

I'm not using nginx.
Did you do app/console cache:clear?

Yeah, I tried, no difference :)
But I founded solution. I added instruction to my nginx and all works!

location /media/cache/resolve {
    try_files $uri @rewriteapp;
}

Cheers!

I don't know why you are only using try_files at that location (how do you properly serve up CSS or image files?). For those having issues with Nginx, the configuration I always use for Symfony (including projects with this bundle) is the following:

  location / {
      try_files $uri @rewrite_framework;
  }

  location @rewrite_framework {
      rewrite ^(.*)$ /app.php/$1 last;
  }

I suggest removing app_dev.php, of course.

@robfrawley In my project this is the correct config, but thanks, I will remember your remark in the future

jeroendesloovere's solution worked for me. (using Apache)

@robfrawley could you please explain for those who can't find where to place this config to nginx, where should it be placed? Can't really figure it out...

@diriy Inside server section

@indapublic , I understand it. But, unfortunately, it crashes everytime, I try to launch the server. my nginx config is the following:

` server {
listen         %ip%:%httpport%;
listen         %ip%:%httpsport% ssl;
server_name    %host% %aliases%;

ssl_certificate               "%sprogdir%/userdata/config/cert_files/server.crt";
ssl_certificate_key           "%sprogdir%/userdata/config/cert_files/server.key";

location ~ /\. {deny all;}

location / {
    proxy_buffer_size         64k;
    proxy_buffering           on;
    proxy_buffers             4 64k;
    proxy_connect_timeout     5s;
    proxy_ignore_client_abort off;
    proxy_intercept_errors    off;
    proxy_pass                http://%ips%:%httpbackport%/;
    proxy_pass_header         Server;
    proxy_read_timeout        5m;
    proxy_redirect            off;
    proxy_send_timeout        5m;
    proxy_set_header          Host $host;
    proxy_set_header          X-Forwarded-For $http_x_forwarded_for;
    proxy_set_header          X-Real-IP $remote_addr;
    proxy_set_header          X-Forwarded-Proto $scheme;
    try_files $uri @rewrite_framework;
}

location @rewrite_framework {
  rewrite ^(.*)$ /app.php/$1 last;
}

location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|cur|swf)$ {
    root     "%hostdir%";
    expires  7d;
}

location ^~ /apacheicons/ {
    alias    %sprogdir%/modules/http/%httpdriver%/icons/;
}
location ^~ /apacheerror/ {
    alias    %sprogdir%/modules/http/%httpdriver%/error/;
}

location /openserver/ {
    %allow%allow    all;
    allow    127.0.0.0/8;
    allow    ::1/128;
    allow    %ips%;
    deny     all;

    location /openserver/server-status {
        stub_status on;
    }

    proxy_buffer_size         64k;
    proxy_buffering           on;
    proxy_buffers             4 64k;
    proxy_connect_timeout     5s;
    proxy_ignore_client_abort off;
    proxy_intercept_errors    off;
    proxy_pass                http://%ips%:%httpbackport%/openserver/;
    proxy_pass_header         Server;
    proxy_read_timeout        5m;
    proxy_redirect            off;
    proxy_send_timeout        5m;
    proxy_set_header          Host $host;
    proxy_set_header          X-Forwarded-For $http_x_forwarded_for;
    proxy_set_header          X-Real-IP $remote_addr;
    proxy_set_header          X-Forwarded-Proto $scheme;

    location ~* ^/openserver/.+\.(jpg|jpeg|gif|png|ico|css|js|cur|swf)$ {
        root     "%sprogdir%/modules/system/html";
        expires  7d;
    }
}

} `

Where did I do a mistake? I use OpenServer. It crashes with error "1 rewrite or internal redirection cycle while redirect to named location "@rewrite_framework", client: 127.0.0.1, server: site.dev, request: "GET /app_dev.php/ HTTP/1.1", host: "site.dev", referrer: "http://site.dev/app_dev.php/_profiler/243ba6?panel=config". Thank you for your help!

@diriy nginx -t said anything?

@diriy There are multiple mistakes in your example, for example you don't define a root for Symfony's context. Also, you should always run nginx -t (you may need to run that as sudo) to check your configuration syntax, as well.

I run my site on PHP-FPM using the FastCGI transport of Nginx. Here is a basic, working example:

server {
    listen      80;
    listen      443 ssl http2;
    server_name domain.com;
    root        /web/domain.com/web;

    access_log /var/log/nginx/acess_domain.com.log combined buffer=256k flush=10m;
    error_log  /var/log/nginx/error_domain.com.log error;

    location / {
            try_files $uri @rewrite_framework_symfony;
    }

    location @rewrite_framework_symfony {
            rewrite ^(.*)$ /app.php/$1 last;
    }

    location ~ \.php(/|$) {
        fastcgi_param QUERY_STRING      $query_string;
        fastcgi_param REQUEST_METHOD    $request_method;
        fastcgi_param CONTENT_TYPE      $content_type;
        fastcgi_param CONTENT_LENGTH    $content_length;

        fastcgi_param SCRIPT_NAME       $fastcgi_script_name;
        fastcgi_param REQUEST_URI       $request_uri;
        fastcgi_param DOCUMENT_URI      $document_uri;
        fastcgi_param DOCUMENT_ROOT     $document_root;
        fastcgi_param SERVER_PROTOCOL   $server_protocol;
        fastcgi_param HTTPS             $https if_not_empty;

        fastcgi_param GATEWAY_INTERFACE CGI/1.1;
        fastcgi_param SERVER_SOFTWARE   nginx/$nginx_version;

        fastcgi_param REMOTE_ADDR       $remote_addr;
        fastcgi_param REMOTE_PORT       $remote_port;
        fastcgi_param SERVER_ADDR       $server_addr;
        fastcgi_param SERVER_PORT       $server_port;
        fastcgi_param SERVER_NAME       $server_name;

        fastcgi_split_path_info         ^(.+\.php)(/.*)$;
        fastcgi_buffer_size             384k;
        fastcgi_buffers                 1024 8k;
        fastcgi_busy_buffers_size       384k;
        fastcgi_temp_file_write_size    384k;
        fastcgi_param                   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param                   REDIRECT_STATUS 200;
        fastcgi_read_timeout            1m;
        fastcgi_pass                    127.0.0.1:9090;
    }
}

I just encountered the same problem on an Apache Server. My config worked fine on my local development machine, but on the server the thumbnails were not generated and the "resolve" path showed up in the path to the thumbnail image.

Now i know that the "resolve" path is a hint for the bundle that there is no cached image yet and needs to be generated. If there IS a ached thumbnail this path will disappear from the url.

The problem showed up after setting up a deployment system that required me to move the image cache folder outside the application folder to a seperate shared files folder. So the cached files were only available via a symlink. But the bundle checks the absolute filesystem paths and stops working if your cache directory is outside your application directory. The Exception meesage showed up after trying to run the resolver via command line.

The solution was to configure the file_system loader with an additional data_root path to my shared files folder. that looks something like this:

# configuration f眉r liip imagine bundle und thumbnails / filter sets liip_imagine: # configure resolvers resolvers: # setup the default resolver default: # use the default web path web_path: ~ # loaders loaders: default: filesystem: data_root: - '%kernel.root_dir%/../web/' - '%liip_imagine_web_root%'

The first path is the default path, the second is my new parameter that i can define in parameters.yml and holds the complete absolte path to the shared files folder ( /var/www/...... ).

After clearing the cache everything is working properly again.

Good Luck!

@dkuss solution worked for me, thanks man, was trying to make this work for weeks.

For some unknown reason installing php-imagick didn't work for me. The module was getting loaded for the PHP CLI (I checked with php -m | grep -i imagick) but through my nginx webserver it didn't show up in the list of modules reported by phpinfo() at all. I even inserted extension=imagick.so to /etc/php/7.0/fpm/php.ini manually, just to make sure.

I then purged the php-imagick package and installed from cpan:

sudo apt install libmagickwand-dev imagemagick php-dev
sudo pecl install imagick
And still, no cigar. It would work through the cli but not via nginx. Turns out I had to restart the fpm:

sudo service php7.0-fpm reload
Now it works just fine.

Thank you, @dhirajpatra for sharing your solution!

Hi,

I'm using Apache, I did the @jeroendesloovere solution, the @dkuss solution as well but it still don't work.

When I resolve manually it works, no errors, and it seems that some images manage to be resolved...

Any tips ?

If I try to access to the given "resolve" path in my browser, I'm redirected to my login page. Is there something to investigate this way ?

In my case it was the "gd" driver not installed, simply solved the issue by uncommenting the extension under php.ini:
;extension=gd2
to
extension=gd2

Hey, I had this problem on my production server (using apache) and tried all the different solutions mentioned above.

Turns out I generated the apache .conf file and didn't double check it.

by adding

Allow from all
AllowOverride All
Options -MultiViews
Require all granted

to the .conf file and reloading apache all was working properly again.

update to @dkuss solution for SF 4.4

liip_imagine:
    loaders:
        default:
            filesystem:
                data_root:
                    - '%kernel.project_dir%/public/'
                    - '%env(LIIP_PUBLIC_PATH)%'

Then add LIIP_PUBLIC_PATH to your .env and .env.local file
Example :

LIIP_PUBLIC_PATH=/var/www/myproject/shared/public

I had the same problem and it was linked to nginx with web browser caching for images. @cedricziel reported it earlier in this thread but did not provide solution. As, like me, you may not be really at ease with nginx. I share my solution. If it is bad pattern, please tell me. It works but I recently moved from apache2 to nginx so it can be inaccurate.

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

I had the same problem beacuse i used nginx cache as :

    # Media: images, icons, video, audio, HTC
    location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
        expires 1M;
        access_log off;
        add_header Cache-Control "public";
    }

I had to add try_files $uri $uri/ /index.php$is_args$args; in this directive to make it work.

You can also use this instead of creating extra parameters or ENV variables.

liip_imagine:
  resolvers:
    default:
      web_path: ~

  loaders:
    default:
      filesystem:
        data_root:
          - '%kernel.project_dir%/public'
          - '%kernel.project_dir%/../../shared/public'

php app/console liip:imagine:cache:resolve

Hi everyone,

just to add my little stone to the wall, thanks for the hint here, we found the solution.

By using this command on prod (AWS EC2 with Apache + Cloudfront), we checked that the file can be correctly resolved. The problem was in the Cloudfront settings where we configured the distribution to serve directly the content from S3 if url match pattern "media/*"

(extract from cloud formation template)

        CacheBehaviors:
          - Compress: true
            ForwardedValues:
              QueryString: false
            TargetOriginId: s3-media-endpoint
            ViewerProtocolPolicy: redirect-to-https
            MinTTL: 0
            DefaultTTL: 30
            MaxTTL: 60
            PathPattern: "media/*"

By commenting theses lines and updating the distribution, the resolve is done correctly. For the moment we will let it disabled, I think we can change the pattern to exclude media/cache/resolve to fix it properly.

Hope it will help someone, some day.

Was this page helpful?
0 / 5 - 0 ratings