-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Images not uploading to AWS #134
Comments
Same here. |
I'm having the same issue. I turned on logging for my aws and here's the error I got: (replacing my actual bucket name with "bucketname")
|
Same. I don't know about that AWS log file, though. Inspecting the broken image links in the browser show a legitimate AWS path, but nothing is getting uploaded. I don't think Imager is even trying. Same configuration settings as @andrewmenich here. Craft CMS 3.0.9 |
Are you guys using bucket encryption? https://www.cloudconformity.com/conformity-rules/S3/bucket-default-encryption.html |
No. We are not using bucket encryption. |
@smockensturm Did you at some point change your configuration from having transforms locally to enabling AWS? If so, make sure that you clear the local imager transform cache, if the image already exists there, Imager will assume that it has already been uploaded to AWS. What regions are you guys creating your buckets in? |
If we do, we empty the cache and local imager directory. As instructed. The region is |
Are you using the same bucket in Craft? You're sure that the access is set up correctly? Also, have you tried enabling the debug toolbar, any errors there? Imager will throw one error that says "Invalid configuration of S3 Client: (error message)" if the S3 client can't initialize, and "An error occured while uploading to Amazon S3: (error message)" if the upload failed for some reason. |
Yes. Yes. Here is the error in the log:
|
Can you post your aws config settings (remove the access key and secret!)? |
|
That looks correct to me, not sure what could be wrong then. All the threads I find when googling the error message, suggests that the region is wrong. Are you sure the bucket is created in us-east-2? What's the name of the region when you view the bucket in your s3 console (where it says EU (Ireland) in the attached screenshot)? |
US East (N. Virginia) |
North Virginia is us-east-1 according to the list here: https://docs.aws.amazon.com/general/latest/gr/rande.html |
Boom! That does the trick. I don't know what is up then with the Amazon S3 url string then that says:
Anyway. Thanks for helping us track this down. |
The region string in the url has nothing to do with where your buckets are, it's just where your account are I think, or where the console is loading from. Mine says us-west-2, even though I have no buckets in that region. ;) Glad we got that sorted out. But I kinda think this issue is unrelated to what @Tam, @sergeifilippov and @andrewmenich reported. Did you guys figure out what the problem was? |
For me the issue was resolved by clearing out the |
@nfourtythree Anything in the debug toolbar? See my reply above on what to look for. |
@aelvan enabled debug toolbar. Killed the local folder. Reloaded the page, nothing came up in the logs in terms of errors. Interestingly the same issue happening on another page and it is always the 6th image, that same transform that is hashed to But doesn't happen on all of them. So there might be three images on the page using the same set of 6 transforms. 1 image, all of the images are fine, the other two only 5 of the 6 transforms have uploaded. Let me know if you want to talk through/screen share on slack or somethign |
Any thoughts on this @aelvan? It seems quite strange I have noticed it on a few pages of the project I am currently working on and it seems like it seems to fail to upload 1 of the transforms. So if there are 3 it would upload 2, or 5 it would upload 4 etc. |
We are having the same issue as @nfourtythree. I haven't noticed a pattern, but some images don't make it to AWS. |
We are experiencing a similar issue where our imager transforms are saving properly locally, but never making it to S3. Uploading to S3 from Craft assets works without any issue, so it doesn't appear to be a permissions problem. We are not seeing any imager or S3 errors in the debug toolbar. In our S3 logs we are seeing the following error:
|
I have a similar issue. Anyone know where to enable the "debug toolbar"? Is that Craft, Imager or AWS specific? The generated transforms are supposed to reside in a numbered folder, for example "300" - but that folder doesn't even exist in the bucket. I have emptied all local imager caches. It's weird, we can upload files to AWS with Craft. But the Imager transforms aren't uploaded, in certain environments. |
Just want to echo the previous two post and say that I can't for the life of me get Imager to write to my S3 bucket. I have 1 site on my Homestead/Vagrant server that works fine, along with the staging and live versions which live on a Forge server. But the new site that I created on Homestead will not write any images to S3 (even though Craft itself uploads the images fine) |
Updating my post, as I fixed the issue by setting |
@jwb009 So you've defined it above the returned configuration array?
Or did you the this as part of the returned configuration array? ...
'storages' => ['aws'],
... |
Above. So the relevant code looks like:
|
I've seen this problem as well - it's much more likely to happen when you upload over 5 images at once (this seems to be reflected in the thread above) Could it simply be an AWS upload issue and we just need to retry? Does this line suggest that if the upload fails then the Craft queue job is not marked as 'failed' (so that it can be retried in the queue later)? Imager-Craft/src/jobs/OptimizeJob.php Line 63 in e644e8e
I'm not an expert in this but it looks to me like this would just fail in the event of an AWS upload fail |
I got to the bottom of my issue which I'll write here in case it affects anyone. Images generated via the elements api were getting uploaded to S3 but to the wrong 'folder'. They were getting uploaded to s3://bucket/_imager/var/www/...... ie: including the full web root. I tried to fix this by adding 'imagerSystemPath' to the imager config (which enabled imager to remove the the full path of the image when creating the s3 url). This still didn't work because we store images in a shared folder that doesn't get overwritten by a deploy so I had to fix that issue too. Once that was done it worked as expected. Be sure to fully check your s3 bucket to see that missing files are not elsewhere... |
@petetak - Would you be willing to share your configuration for this task? I'd love to compare your configuration change. |
@JWheeler sure thing. My images crops live in a folder called 'shared' whereas the craft site lives in a folder called 'current'. In order to make sure the S3 filepaths are correctly created I needed to swap out current for shared. It's not a great solution but it works...
|
Imager is working on my staging environment, which is on the same server as the live site. The configs are identical, but the images aren't being uploaded to S3 on the live site.
The locally stored images are being transformed and saved correctly, but the S3 images aren't.
There isn't an
imager.log
, and there are no errors in thecraft.log
. I've checked the permissions and they're all correct (staging writes to the same location, and that works).For the time being I've disabled AWS & set my
imagerUrl
back to default, and everythings working as expected. Is there anything I can do to get this working on S3, or at least better debug what's wrong?The text was updated successfully, but these errors were encountered: