getimagesize errors on site generate #91
Comments
|
I just ran into this too after the same upgrade. I dunno if it matters but I'm using the S3 driver. |
|
I’m not using S3 on this site, so I don’t think it makes a difference. |
|
The Glide Tag is using the cache path set by the CMS config instead of the SSG config here: https://github.com/statamic/cms/blob/e69c1f434acc4a267832dc20ea7397ea1623bb34/src/Tags/Glide.php#L110. In order to fix this the SSG plugin needs to be able to override the cache paths set here: https://github.com/statamic/cms/blob/e69c1f434acc4a267832dc20ea7397ea1623bb34/src/Imaging/GlideServer.php#L34 |
|
I’m not even using Glide on the pages in question, which makes it extra weird. I’m guessing it’s related to SEO Pro using Glide. |
|
@imacrayon I’m not sure this is the whole story, because I have cache disabled in the assets.php file, so I would think it shouldn’t even be caching the glide images, unless the SSG is overriding that. |
|
OK, I take that back. Caching on/off doesn’t apply because it has to generate them anyway, so they have to be “cached.” But I think you may be on to something. So my Glide path is set to from ssg.php: But error is showing So perhaps since glide isn’t putting images into that path during SSG generate, it can’t find them for the next step unless they’ve already been generated by the CMS on the dynamic side. |
|
Yep, I'm pretty sure that's what's going on. If I add this after line 101 in Glide.php. SSG starts working again for me. |
|
@imacrayen Would you be able to do a pull request with that fix? Maybe we could actually get this fixed faster. :-) |
|
Hey I believe this is related to statamic/cms#5662 which I'm investigating now. |
|
statamic/cms#5724 doesn't quite fix this b/c the The SSG command overrides Glide's internal cache path here: Line 109 in 1acc7b8 but GlideServer.php still returns the cache path set in config/statamic/assets.php.
|
|
So this error did not occur on a new site built from the basic starter kit. Granted, it’s a simple site that I haven’t done anything fancy on, but the issue is not universal. On another site, instead of getting For example: But here is the image: So that would seem to support @imacrayon’s point that the issue is with the cache path not being respected. |
|
So I noticed the fresh site I set up uses Laravel 9, so I went through all the shenanigans of updated to that (which also means disabling the lovely Review module for now). I also generally made sure other composer modules were updated to match the new starter file. Now I get a slightly more robust error message: I’m not sure what this source containers folder is, but I don’t think it exists. |
|
@fitzage, by chance did you ever figure out the last error message? I'm running into this too and the cause seems to be related to the seo-pro addon in our case. We're using github actions to deploy to S3/CloudFront and this is the only hangup we're currently encountering. |
|
@conradfuhrman Nope, I’ve had to back burner the upgrades. I did just build a site without SEO Pro that works fine, so it makes sense that this is the issue. |
|
Thanks for the quick response! I'll make sure to make a ticket for SEO Pro and reference this. Any other issues with Glide you experienced and SSG? We also just backed out SEO Pro and had a perfect deploy so we'll just have to implement our own SEO fields (or try a different addon). |
|
@conradfuhrman I don’t think I’m actually using glide anywhere else on the sites in question, so I’m not sure about other issues. |
|
Running into this issue too: The file does exist when I check through terminal
Once this error occurs during This exception will only go away if I do
As you can see, I am not using SEO Pro. I do not think this is issue with an addon I have installed, just a general Glide & SSG issue. Happy to send the git repository to core team. |
|
I've started getting the same problem on Github Actions. I was going crazy trying to figure it out but it's the same message: |
|
I have dug up another, earlier exception stack trace from the one I posted earlier. I don't know why exceptions in console output are so bare bones, we are shooting ourselves in the foot by not having exception stack traces that can be easily accessed. Here's the exception: |
|
I was able to narrow this issue down to Glide tag pairs. I opened a new separate issue. #110 Templating like this {{ glide:assets_field }}
{{ height }}
{{ width }}
{{ /glide:assets_field }}
caused this error for me. Maybe you folks have tag pairs in your projects also? The failing assets were always consistently the same for me, not random, so it was not difficult to narrow this issue down. |
|
@ncla I haven’t directly used Glide the sites in question. It’s SEO Pro for me. |
|
You may not be using it directly, but the addon does contain Glide tags, and I think this code for example from SEO Pro Will trigger the same error. |
|
FWIW, if anyone needs a quick workaround, I set up a Gist with the code for Just create a folder named It's probably not the cleanest/best way about it but it worked for me. https://gist.github.com/jsbls/d0858e1e254652c1deb71b063904c778 |
|
#104 resolved this for me. Add the new config to 'glide' => [
'override' => false,
], |
|
I found that SSG and Glide (to Netlify) needed two configuration file adjustments. (Should also fix #123.)
'image_manipulation' => [
'cache' => true,
'cache_path' => public_path('img'),
],
'copy' => [
public_path('img') => 'img',
],
...
'glide' => [
'directory' => 'img',
'override' => false,
],But note that setting the |
|
Full disclosure, I don't personally use SSG day-to-day so haven't felt confident enough to do a PR as I'm unsure of the bigger implications, however rather than changing vendor files above, I developed a little workaround for a client so that they can maintain local edit-ability of images (i.e. not cached): blog post Basically it is moving this logic to the |
|
@martyf None of the other workarounds have solved my problem, but I’ll give your fix a shot. |
|
@martyf Yay! I can finally upgrade to 3.3, and hopefully beyond. |
|
@martyf Yep, this is needed all the way into 4.0, but it also works just fine in 4.0. Woohoo! |
|
Happy to hear it has helped - it was for Statamic 4 that it was originally written (as the client raised the issue during the 3-to-4 process), but glad it has worked on 3 too. Not sure if this is too opinionated for a PR as it does it in a way that works, but may not work for everyone too. Again, not a SSG user myself (except for very hands-off for this one client) so unsure of the bigger picture ramifications. |
|
@martyf Works like a charm! Thanks! |
I’m not sure where exactly the issue is here because I updated to Statamic 3.3 as well as SSG 1.0 at the same time, since it kind of all depended on each other.
When I attempt to generate my site statically, a few pages generate and then I get a glide error. At first I thought it was social images, but it’s not just social images. As far as I’ve been able to track down, the generator is for some reason trying to run “getimagesize” on versions of images that haven’t yet been generated by glide. I’m not even sure why it’s trying to do that here, and not sure why glide is even generating some of these images. I’m not actively using it in these cases (although I imagine it’s in use in the background for the social images.
I did figure out this much: if I visit the page with the image in question on my localhost, the image that was missing gets generated. I can go into
storage/statamic/glide/containersand dig down to that folder and the image doesn’t exist. But as soon as I load the page, it gets generated. So the SSG is expecting these to be generated, but they’re not getting generated unless I go visit the actual page, which creates a pretty big issue for the SSG.This happens even if I disable multiple workers, so it’s not related to the other bug of occasional issues with multiple workers.
The text was updated successfully, but these errors were encountered: