JPG variant does not exist,..

[thaoms]

I added the field type, I updated the focal point, the placeholders are generated, color palette is generated.

But all the variants give the same message. XXX variant does not exist,..

Am I missing something? My config lives in config/image-optimize.php I'm using Craft 3 rc5 and assets are in a symlinked shared folder.

[nielsnuebel]

Did you set the asset File System Path correct?

[khalwat]

Yeah I'd check your Volumes.php and Asset Volume settings to make sure your paths are correct... and then also look in storage/logs/web.log for any errors

[thaoms]

Im using the CP ui, not Volumes.php:

• @web/uploads and
  • @webroot/uploads

for url and path.

When I check the FTP, the files are all actually generated, jpg and webp.

Uploading is actually not an issue, thumbs also get generated.

Screenshot as proof;

[thaoms]

I found that
{% set thisFileSize = value.getRemoteFileSize(thisUrl) %} returns -1B

So when I remove thisFileSize != -1 from {% if imageSource |length and thisFileSize != -1 and thisUrl |length %}

It actually renders fine: image exists, path is correct and the previews load correctly! I'm looking up why getRemoteFileSize returns a wrong value.

Maybe UrlHelper::isAbsoluteUrl($url) and UrlHelper::isProtocolRelativeUrl($url)l return false when using an alias like @webroot?

[khalwat]

That's a good find @thaoms it very well could be something to do with the alias. It's possible that:

a - I need to try to resolve the alias b - there's some bug in Craft where it should be resolving aliases when it isn't

[khalwat]

So when I remove thisFileSize != -1 from {% if imageSource |length and thisFileSize != -1 and thisUrl |length %}

So when you remove this, can you paste in what the URLs look like? If you click on any of the thumbnails, it will open the asset URL in a new tab.

I'm curious to see what it looks like.

[thaoms]

Sure, I truncated the host for privacy issues, but the links work:

Jpg: /uploads/_1200x675_crop_center-center_82_line/shutterstock_163448702.jpg?mtime=1515832810

Webp: /uploads/_1200x675_crop_center-center_82_line/shutterstock_163448702.jpg.webp?mtime=1515832810

If you want I can make you a test account in the control panel.

[khalwat]

So I think this is very likely some kind of local config issue; I was able to replicate your setup by using @web/assets and @webroot/assets as aliases in my Asset Volume without incident:

I'm not sure why your local webserver isn't letting the getRemoteFileSize() method obtain the image via curl() and CURLOPT_NOBODY

[thaoms]

I'll try with a fixed absolute path, or it might be because that folder is symlinked to a shared uploads folder.

Edit: It is indeed fixed by using absolute paths. @webroot was actually fine, but when I changed @web to my real url the thumbnails were showing up.

But being safe I'm using the volumes.php file with both absolute paths (no aliases), I'll avoid using the aliases in future projects.

Until we can rule out what the issue is, maybe you should add to the docs that the aliases can give unexpected results in some specific environments/hosting setups. (To avoid that someone adds an issue like mine)

Of course I am willing to provide further information.

Many thanks!

[khalwat]

I don't think the @web alias is an issue, given that it works okay here on my setup. It could potentially be the symlink, but it seems unlikely as well.

What are you using for a webserver / environment in the setup where you had this issue?

[thaoms]

I'm not much of a server guy so you might want to ask specifics ;)

I'm using php 7.1.11 We are a reseller of a hosting company, I do know it's a shared hosting so for example I can't change the public root (fixed to www).

[khalwat]

If it's a public website, if you can give me a URL to one of the images that was failing to display (but was properly generated) would be really helpful.

[thaoms]

http://craftstart3-chillibe.webhosting.be/uploads/_1200x675_crop_center-center_82_line/shutterstock_163448702.jpg?mtime=1515863215

[khalwat]

So odd. I can curl -I that URL with no issues at all.

I'll close the issue since you've found a work-around, but I'm still intrigued by what could be going on here.

[thaoms]

I got a little closer, when I var_dump the curl when using the aliases:

string(109) "//craftstart3-chillibe.webhosting.be/uploads/_1200x675_crop_center-center_82_line/DSC2217-1_180111_143659.jpg" string(15) " malformed

And with absolute paths:

string(100) "http://craftstart3-chillibe.webhosting.be/uploads/_1200x675_crop_center-center_82_line/DSC2217-1.jpg

FIXED:

Because $url is /uploads/_1200x675_crop_center-center_82_line/DSC2217-1_180111_143659.jpg, this function jumps to the else case, which uses the site url.

My site url is protocol relative, that's what's causing the malformed url. Site url doesn't get resolved with a protocol.

'siteUrl' => [
            'chilliEnglish' => '//craftstart3-chillibe.webhosting.be',
            'chilliNederlands' => '//craftstart3-chillibe.webhosting.be/nl'
        ],

When I add http:// everything is work fine! Is there any solution that will not be using the siteUrl? As you can see I'm adding a language segment so that might be dangerous when I would use a language segment as default siteUrl.

And I rather not fill in a fixed protocol in the config file.

[khalwat]

Ahhhhh, good sleuthing! I think I can put a fix in there to catch this case.

[khalwat]

Should be fixed in 1.4.9!

https://github.com/nystudio107/craft3-imageoptimize/releases/tag/1.4.9

[thaoms]

Thank you!

I was wondering what would happen if your default siteUrl has a language segment?

[khalwat]

I think Craft is smart enough that it will work as expected, if you have set things up properly via your volumes.php

[thaoms]

Is it possible that the last update reverted this?

[hascoulijn]

I'm experiencing a similair issue with ImageOptimize 1.4.14, "JPG variant does not exist", even though the files are generated and everything is working fine in the template. I've tried various configs in the asset's volume base URL and file system path with no success.

[khalwat]

@hascoulijn have a look at what your Volumes.php settings are for your Asset volume, or what the URLs for any aliases you might use like @web or @baseUrl or what have you.

[khalwat]

Just for clarification's sake, the regression that @thaoms noted was fixed in Version 1.4.11:

https://github.com/nystudio107/craft-imageoptimize/releases/tag/1.4.11

[hascoulijn]

I use @baseUrl and @basePath as aliases as per Craft 3 Multi-Environment setup. But it doesn't seem to matter whether I use absolute paths and URLs or aliases, my assets keep working fine but the imageOptimize field in my Asset Volume can't seem to find the variants. I figure it could have something to do with my local environment. I'm running PHP 7.0 on Ubuntu 14.04, could it have something to do with that?

[khalwat]

Right, but I'm asking what you actually have your @baseUrl set to? What it does to display those images is it tries to load them via curl to get the file size. Something isn't allowing it to load them.

[thaoms]

To be honest, since the last update and even the fix for the regression, it doesn't work anymore. But this time I have no idea why, did Craft change the urlhelpers?

[khalwat]

@thaoms what version of Craft CMS 3 are you running, and what version of ImageOptimize are you running?

[khalwat]

Sanity check: everyone has updated their composer.json to be:

        "nystudio107/craft-imageoptimize": "^1.0.0",

(renaming the craft3- prefix) yes? That or uninstall and re-install the plugin. Just want to make sure we're all using the same thing, I had to rename the package a few versions ago.

[thaoms]

Yes I got "nystudio107/craft-imageoptimize": "^1.4.14" Craft RC10.1

return [
    'uploads' => [
        'path' => '@webroot/uploads',
        'url' => '@web/uploads',
    ],
];```

[khalwat]

What are you seeing if you var_dump the URLs as you did here? https://github.com/nystudio107/craft-imageoptimize/issues/34#issuecomment-358398903

Also, are there any error messages in console about 404s, etc.?

[khalwat]

I've gone over the code diffs, and it looks exactly the same as the pre-regression fix for protocol relative URLs @thaoms

It's also continuing to work on my test installs, so I'm not sure what is going on here...

[thaoms]

when I echo this: $url = UrlHelper::siteUrl($url, null, $protocol); echo $url;

I get this

//craftstart3-chillibe.webhosting.be/uploads/_1200x675_crop_center-center_82_line/DSC2217-1_180111_143952.jpg

Seems it is not adding the protocol, no console errors

[khalwat]

It shouldn't be hitting that function for you, though. The code does:

            if (UrlHelper::isProtocolRelativeUrl($url)) {
                $url = UrlHelper::urlWithScheme($url, $protocol);
            } else {
                try {
                    $url = UrlHelper::siteUrl($url, null, $protocol);
                } catch (Exception $e) {
                }
            }

In this case, it is a protocol-relative URL, so it should be calling UrlHelper::urlWithScheme()

[thaoms]

My urls before that function are actually:

/uploads/_1200x675_crop_center-center_82_line/DSC2217-1_180111_143659.jpg

after the function they are

//craftstart3-chillibe.webhosting.be/uploads/_1200x675_crop_center-center_82_line/DSC2217-1_180111_143952.jpg

echo $url; $url = UrlHelper::siteUrl($url, null, $protocol); echo $url;

[thaoms]

It must be something in Craft, I do remember that it was fixed for a while.

[khalwat]

I'm putting in something that should fix it for you at least @thaoms -- I agree that this is some kind of regression in Craft.

[khalwat]

I added some code in the just-released 1.4.15 which will force the URL to have a protocol if it's a protocol-relative URL even after asking UrlHelper::siteUrl() for a URL with a specific protocol. Give it a whirl, see if it fixes it for you @thaoms @hascoulijn

https://github.com/nystudio107/craft-imageoptimize/releases/tag/1.4.15

[hascoulijn]

The latest update did not fix the problem for me. To get back to you on your question earlier, my @baseUrl is set to http://craft.test. The BASE_URL in .env.php looks like 'BASE_URL' => $protocol . $httpHost . '/', I have the following aliases in general.php

'*' => [
  'aliases' => [
    '@basePath' => getenv('CRAFTENV_BASE_PATH'),
    '@baseUrl' => getenv('CRAFTENV_BASE_URL'),
  ]
]

And in my volumes.php I have

'*' => [
  'images' => [
    'path' => '@basePath/uploads/images',
    'url' => '@baseUrl/uploads/images',
  ]
],

Also, I noticed that the trailing slash set in .env.php gets trimmed.

[khalwat]

@hascoulijn What are you using in local dev for your environment? MAMP? Valet? Homestead?

It's really curious to me that curl fails, yet the images display fine on the frontend.

[hascoulijn]

@khalwat I use Scotch box for Vagrant and made sure that cURL is enabled.

[khalwat]

@hascoulijn if you're willing, try putting a Craft::dd($url); at line 363 (right before it does $ch = curl_init($url);) of vendor/nystudio107/imageoptimize/src/models/OptimizedImage.php and see what it outputs. You'll also need to put a use Craft; up at the top near the other use statements.

And then try doing a curl on the URL that it outputs from the command line inside of your Vagrant VM. Really curious what is going on here...

[hascoulijn]

@khalwat where should I be seeing the output of Craft::dd($url);? I'm getting "An unknown error occured" when trying to open an asset.

[khalwat]

Ah yes, sorry, I forgot that it's being done via AJAX.

You should find it in your storage/logs/web.log

[khalwat]

@thaoms we good with 1.4.16?

[thaoms]

@khalwat sorry I couldn't get to you earlier. But yes, that fixed it, thank you!

[khalwat]

Any updates @hascoulijn

[hascoulijn]

@khalwat sorry, I was away for a couple of days, but I wasn't able to find anything particular in web.log using Craft::dd($url);. I did echo the URL though and was able to curl -I it inside of my Vagrant VM without any problems.

On a side note, I'll be switching my environment from Scotch Box to Homestead soon, so maybe that fixes the issue.

[khalwat]

Alright, do let me know. This one has be flummoxed.

[hascoulijn]

Will do! You may close this ticket for now as far as I'm concerned.