Multiple "Source image could not be found" since 1.7 update #849

picks44 · 2017-01-13T09:40:49Z

Since the update to 1.7, I have problems with images not being found and therefore no image beeing generated by the bundle.

Error is "Source image could not be found", and "[1/2] NotLoadableException: Source image invalid "C:\wamp\www\MyProject\src\MyBundle\Resources\public\images\icon.png" as it is outside of the defined root path".

I haven't changed my config

liip_imagine:
    resolvers:
        default:
            web_path: ~
    filter_sets:
        cache: ~
        thumb:
            filters:
                background: { size: [1140, 400], color: '#fff' }
                strip: ~

I'm also using VichUploaderBundle and the Symfony asset versioning system

framework:
    assets:
        version: 'X'

so my Twig looks either like

{{ asset('bundles/mybundle/images/icon.png'|imagine_filter('thumb')) }}

or

{{ vich_uploader_asset(enity, 'iconFile')|imagine_filter('thumb') }}

My assets are installed with symbolic links.

The text was updated successfully, but these errors were encountered:

robfrawley · 2017-01-13T19:31:13Z

Please reference issue #846 and PR #848 for discussion on the problem you are describing.

robfrawley · 2017-01-13T22:41:36Z

Please see if #851 resolves your issue.

picks44 · 2017-01-16T10:37:31Z

Well I have to wait for v1.7.1 to try this as I guess I have several data_root pah to configure (one for the bundle images, and one for the manual user uploads).

picks44 · 2017-01-16T10:38:33Z

To me this new config is not really "user-friendly"...

picks44 · 2017-01-16T10:47:40Z

Now I have the error "Root image path not resolvable "kernel.root_dir%/../web/uploads"...

My confil.yml

liip_imagine:
    resolvers:
        default:
            web_path: ~
    loaders:
        default:
          filesystem:
            data_root: "kernel.root_dir%/../web/uploads"
    filter_sets:
        cache: ~
        thumb:
            ....

adaniloff · 2017-01-17T17:07:13Z

@picks44 try "%kernel.root_dir%/../web/uploads" instead.
I think you forgot a % car. in your config.yml file.

Regards

edvinasnet · 2017-01-17T23:45:07Z

@picks44 maybe are you using symlinks to cached image? I have same error with deployer and symlinks

robfrawley · 2017-01-19T16:39:30Z

@picks44 You absolutely forgot a %. Variables (or, more accurately, string replacements) in Symfony config files must be surrounded by % characters, for example: %kernel.root_dir%.

robfrawley · 2017-01-19T16:41:37Z

To me this new config is not really "user-friendly"...

@picks44 This configuration isn't new, the root check is simply more secure, and takes symbolic links into account. If you aren't using symbolic links there is no need to set this configuration option. What is new is the ability to define multiple root paths.

robfrawley · 2017-01-20T02:05:27Z

Version 1.7.1 released with multiple data roots support.

picks44 · 2017-01-20T15:25:31Z

@robfrawley @edvinasnet @adaniloff Thanks, sorry for my basic mistake, I went over too quickly... Will try this new version.

picks44 · 2017-01-20T15:53:36Z

It's strange, on my dev env (WIndows), I don't need to use the data_root option, but in prod env (Debian) it's looks like i do. Basically my assets are in the web/bundle/mybundle/images (hard copy) and in web/uploads/* (several folders for several types of uploads). Do I need to set a data_root for EVERY folder ?

robfrawley · 2017-01-20T16:12:29Z

@picks44 If they are symbolic links, yes (you should set their destination as data_root paths). If they are regular folders, then no.

robfrawley · 2017-01-20T16:17:08Z

@picks44 You can determine if any symbolic links exist using the find command

find /web-server-root/src/web/ -type l

robfrawley · 2017-01-20T16:19:56Z

For example, given the following folders within %kernel.root_dir%/../web

uploads/ (as regular folder)
other/ (as regular folder)
more/ (as regular folder)
symlink/ (as symbolic link to /some/other/path)

You would have the following as your config for data_root

data_root:
  - %kernel.root_dir%/../web
  - /some/other/path

robfrawley · 2017-01-23T05:22:10Z

@picks44 Is you issue resolved?

garak · 2017-01-23T09:12:17Z

I'm getting the same issue. Thumbnails are not working anymore since last upgrade. I can't get any error in logs. Configuration in dev looks fine, there is a datarootdefauit option set when I runconsole debug:configuration liip_image`. but in prod is not working 😞

garak · 2017-01-23T09:27:19Z

OK I managed to log errors and I found the following:

Liip\ImagineBundle\Exception\Binary\Loader\NotLoadableException: Source image invalid "/myvhost/shared/web/media/lego-lsp_58820aba57b79.jpg" as it is outside of the defined root path in /myvhost/releases/20170123091600/vendor/liip/imagine-bundle/Binary/Loader/FileSystemLoader.php:67

I'm using capifony for deploy, I think that's a pretty common solution. How could be possible that you broke it on a minor release? 😥

picks44 · 2017-01-23T09:31:08Z

@garak I'm using Capifony to deploy too, and I'm currently trying to get this working. Will give you some updates soon.

garak · 2017-01-23T09:39:48Z

Solved with following config:

liip_imagine:
    # ...
    # see https://github.com/liip/LiipImagineBundle/issues/849
    loaders:
        default:
            filesystem:
                data_root: 
                    - "%kernel.root_dir%/../web"
                    - "%kernel.root_dir%/../../../shared/web"

picks44 · 2017-01-23T09:40:30Z

@garak yes I was trying this also. Did you put this in your config.yml or config_prod.yml ?

garak · 2017-01-23T09:43:16Z

When I tried to debug this problem I checked ImagineController and I wonder why every exception is not logged? I mean something like $this->error($e->getMessage). This could improve a lot the ability of finding such problems in production

garak · 2017-01-23T09:43:54Z

I put it directly in config.yml, but now you let me think about it maybe config_prod.yml is more appropriated

picks44 · 2017-01-23T10:58:30Z

Strange, if I do this in my config.yml

liip_imagine:
    resolvers:
        default:
            web_path: ~
    loaders:
        default:
            filesystem:
                data_root:
                    - "%kernel.root_dir%/../web"
                    - "%kernel.root_dir%/../../../shared/web"

And this in my config_dev.yml

liip_imagine:
    loaders:
        default:
            filesystem:
                data_root:
                    - "%kernel.root_dir%/../web"

The app still takes into account the config.yml configuration... Isn't it supposed to be overwritten by config_dev.yml ?

garak · 2017-01-23T12:51:24Z

I think that there's no need to override your config_dev, when I tried with config only, it worked. Anyway, I then moved it to config_prod

picks44 · 2017-01-23T12:55:40Z

@garak @robfrawley if I do not override my config.yml, then I get this error on ALL my processed images Root image path not resolvable "C:\wamp\www\MyBundle\app/../../../shared/web"

robfrawley · 2017-01-23T16:34:09Z

@picks44

if I do not override my config.yml, then I get this error on ALL my processed images Root image path not resolvable "C:\wamp\www\MyBundle\app/../../../shared/web"

You are using the wrong "slash" character in your paths. On Windows, the correct one is \, whereas, on Linux, the correct one is /. PHP does not automatically handle correcting directory separators.

if I do not override my config.yml, then I get this error on ALL my processed images

The app still takes into account the config.yml configuration... Isn't it supposed to be overwritten by config_dev.yml ?

It sounds like it is overwriting the configuration, which is why when you have the configuration in config_dev.yml, you do not get the error (as this file doesn't contain the invalid path). Whereas, when you remove the config_dev.yml file, the invalid path from condif.yml is causing the exception.

You can try the following to test this: create a PHP file with the following and execute it.

<?php
var_dump(realpath("C:\wamp\www\MyBundle\app/../../../shared/web"));

It will output false, meaning the path is invalid: this is the issue causing the exception you mentioned.

robfrawley · 2017-01-23T16:37:29Z

@garak @picks44 As for when to use config.yml, config_prod.yml, config_dev.yml, etc:

Always use config.yml for global configuration (something that should apply to ALL environments)
Only use config_dev.yml for configuration that should only apply to your development environment (and not your production environment)
Only use config_prod.yml for configuration that should only apply to your production environment (and not your development environment)

You use that exact same logic when overwriting configuration from the global (config.yml) configuration file. It is likely you should be only using config.yml. The only reason to use the others is if your production and development environments rely on different configuration options.

robfrawley · 2017-01-23T16:41:40Z

@garak I'd be happy to merge a PR from you that includes additional logging statements in the ImagineController!

robfrawley · 2017-01-23T16:45:02Z

@picks44

The app still takes into account the config.yml configuration... Isn't it supposed to be overwritten by [...]

To clarify a bit, the configurations are not only overridden but also merged. Given your config.yml and config_dev.yml files:

# config.yml
liip_imagine:
    resolvers:
        default:
            web_path: ~
    loaders:
        default:
            filesystem:
                data_root:
                    - "%kernel.root_dir%/../web"
                    - "%kernel.root_dir%/../../../shared/web"

# config_dev.yml
liip_imagine:
    loaders:
        default:
            filesystem:
                data_root:
                    - "%kernel.root_dir%/../web"

The resolved configuration for the production environment is

liip_imagine:
    resolvers:
        default:
            web_path: ~
    loaders:
        default:
            filesystem:
                data_root:
                    - "%kernel.root_dir%/../web"
                    - "%kernel.root_dir%/../../../shared/web"

And the resolved configuration for the development environment is

liip_imagine:
    resolvers:
        default:
            web_path: ~
    loaders:
        default:
            filesystem:
                data_root:
                   - "%kernel.root_dir%/../web"
                   - "%kernel.root_dir%/../web"
                   - "%kernel.root_dir%/../../../shared/web"

robfrawley · 2017-01-23T16:53:23Z

@garak

I think that there's no need to override your config_dev, when I tried with config only, it worked. Anyway, I then moved it to config_prod

You likely want the configuration to apply to both your production and development environment. Therefore it should be in config.yml. See #849 (comment) for additional info.

picks44 · 2017-01-24T07:06:12Z

@robfrawley This is exactly what I'm doing and in dev environment I get the same error on all images Root image path not resolvable "C:\wamp\www\MyBundle\app/../../../shared/web"
This path is not resolvable because it doesn't exists in my dev environment, so why is it taken into account while my config_dev.yml doesn't mention it? And this is not a backlash or slash issue, as I have other configs like this which work like a charm.

I've also tried writing my config like this

# config.yml
liip_imagine:
    loaders:
        default:
            filesystem:
                data_root: ["%kernel.root_dir%/../web", "%kernel.root_dir%/../../../shared/web"]

# config_dev.yml
liip_imagine:
    loaders:
        default:
            filesystem:
                data_root: ["%kernel.root_dir%/../web"]

But I get the exact same error (in dev mode).

robfrawley · 2017-01-24T16:26:20Z

@picks44 The way Symfony merges "array" configuration, your values for data_root will be merged together, meaning the "%kernel.root_dir%/../../../shared/web" path will always exist. For example, in production, your config would result in:

data_root:
  # from `config.yml`
  - "%kernel.root_dir%/../web"
  - "%kernel.root_dir%/../../../shared/web"

Whereas, in development environment, it would result in:

data_root:
  # from `config_dev.yml`
  - "%kernel.root_dir%/../web"
  # from `config.yml`
  - "%kernel.root_dir%/../web"
  - "%kernel.root_dir%/../../../shared/web"

To get around this merge handling of the Symfony Tree Building, move the config from config.yml into config_prod.yml, so that you have completely separate and independent configs for your production and development environments, without any merge functionality occuring on the liip_imagine block.

@picks44 Regarding "directory separators," I don't use Windows, but I do know on Linux you cannot use Windows directory separators. Perhaps Windows automatically allows the use of Linux separators; I have no experience working with PHP on this OS, though, so IDK.

picks44 · 2017-01-25T09:40:41Z

Thanks @robfrawley.

picks44 closed this as completed Jan 20, 2017

lsmith77 removed the State: Confirmed This item has been confirmed by maintainers as legitimate. label Jan 20, 2017

picks44 reopened this Jan 20, 2017

robfrawley removed Level: Bug 🐞 This item involves a legitimate regression (bug) to existing functionality. State: Duplicate This item is a duplicate and will be closed for further discussion in the prior existing thread. labels Jan 23, 2017

picks44 closed this as completed Jan 25, 2017

robfrawley mentioned this issue Jan 28, 2017

[RFC] Provide core implement or enhanced documentation for high-traffic issues #865

Open

peter-gribanov mentioned this issue Nov 30, 2017

Problem with loaders data_root #1018

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multiple "Source image could not be found" since 1.7 update #849

Multiple "Source image could not be found" since 1.7 update #849

picks44 commented Jan 13, 2017

robfrawley commented Jan 13, 2017 •

edited

Loading

robfrawley commented Jan 13, 2017

picks44 commented Jan 16, 2017 •

edited

Loading

picks44 commented Jan 16, 2017

picks44 commented Jan 16, 2017

adaniloff commented Jan 17, 2017

edvinasnet commented Jan 17, 2017

robfrawley commented Jan 19, 2017

robfrawley commented Jan 19, 2017

robfrawley commented Jan 20, 2017

picks44 commented Jan 20, 2017

picks44 commented Jan 20, 2017 •

edited

Loading

robfrawley commented Jan 20, 2017

robfrawley commented Jan 20, 2017

robfrawley commented Jan 20, 2017

robfrawley commented Jan 23, 2017

garak commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

garak commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

robfrawley commented Jan 23, 2017 •

edited

Loading

robfrawley commented Jan 23, 2017 •

edited

Loading

robfrawley commented Jan 23, 2017

robfrawley commented Jan 23, 2017 •

edited

Loading

robfrawley commented Jan 23, 2017

picks44 commented Jan 24, 2017

robfrawley commented Jan 24, 2017 •

edited

Loading

picks44 commented Jan 25, 2017

Multiple "Source image could not be found" since 1.7 update #849

Multiple "Source image could not be found" since 1.7 update #849

Comments

picks44 commented Jan 13, 2017

robfrawley commented Jan 13, 2017 • edited Loading

robfrawley commented Jan 13, 2017

picks44 commented Jan 16, 2017 • edited Loading

picks44 commented Jan 16, 2017

picks44 commented Jan 16, 2017

adaniloff commented Jan 17, 2017

edvinasnet commented Jan 17, 2017

robfrawley commented Jan 19, 2017

robfrawley commented Jan 19, 2017

robfrawley commented Jan 20, 2017

picks44 commented Jan 20, 2017

picks44 commented Jan 20, 2017 • edited Loading

robfrawley commented Jan 20, 2017

robfrawley commented Jan 20, 2017

robfrawley commented Jan 20, 2017

robfrawley commented Jan 23, 2017

garak commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

garak commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

garak commented Jan 23, 2017

picks44 commented Jan 23, 2017

robfrawley commented Jan 23, 2017 • edited Loading

robfrawley commented Jan 23, 2017 • edited Loading

robfrawley commented Jan 23, 2017

robfrawley commented Jan 23, 2017 • edited Loading

robfrawley commented Jan 23, 2017

picks44 commented Jan 24, 2017

robfrawley commented Jan 24, 2017 • edited Loading

picks44 commented Jan 25, 2017

robfrawley commented Jan 13, 2017 •

edited

Loading

picks44 commented Jan 16, 2017 •

edited

Loading

picks44 commented Jan 20, 2017 •

edited

Loading

robfrawley commented Jan 23, 2017 •

edited

Loading

robfrawley commented Jan 23, 2017 •

edited

Loading

robfrawley commented Jan 23, 2017 •

edited

Loading

robfrawley commented Jan 24, 2017 •

edited

Loading