You are not logged in.
Pages: 1
Hello Tim,
We are having issues with cropping images, we are getting "The file is an invalid image or is an unsupported image type." message. We are using jpg images and on bigtree 4.4.16. We are not having this issue with new images(uploaded to the file directory today), just images already in the file system in Bigtree / S3.
On July 28, we updated S3 to use TLS 1.2 and did notice http images were giving us 404 errors on our website. We are not sure if there is any relation to that change.
Do you have any insight on what could be the issue?
Offline
The warnings I get after going back in to edit again
Warning: getimagesize(): Unable to find the wrapper "resource" - did you forget to enable it when you configured PHP? in /.../bigtree/core/inc/bigtree/image.php on line 44
Warning: getimagesize(resource:////s3.amazonaws.com/.../welch-speaking.jpg): failed to open stream: No such file or directory in .../bigtree/core/inc/bigtree/image.php on line 44
Last edited by doon.mok (August 7, 2023 3:26pm)
Offline
If anyone else has this issue, we had to do an update in the database to add https: at the beginning of the column file.
UPDATE bigtree_resources SET file = CONCAT('https:',file)
WHERE file LIKE '//s3.amazonaws.com%'
AND (type = 'jpg' OR type = 'png' OR type = 'gif' OR type = 'jpeg');
Offline
I also noticed the core/inc/bigtree/image.php file checks if the file begins with //, add http. Adding http would break for us since we changed our S3 to only allow https.
if (strpos($file, "//") === 0) {
$file = "http:".$file;
}
Offline
Hi Doon!
Sorry for the delayed reply — we had a 3 day power outage up here after storms blew through on Monday. Glad you caught the issue — I think either an earlier version of BigTree was using protocol agnostic file paths or your static_root in the config was using them. If it's the latter you'll want to update that to be https://.
Offline
Hey Tim,
I hope everyone is safe.
We have static_root as //rosalin... I'm not sure adding https:// will fix the issue with old Amazon S3 files that still have "//s3.amazonaws.com". Do you think running UPDATE in the database to look for "//s3.amazonaws.com" and add "https:" is the best option?
Thanks for your help.
Offline
Thanks Doon! Nothing deadly, just lots of downed trees.
Adding https:// to the static_root won't help the existing assets (you will want to update them in the database directly — that is the right course of action!) but I believe it should prevent future uploads from getting // by default but I could be wrong. It's been a long time since I last ran into the issue!
Offline
Got it, thanks for the quick reply.
Offline
Pages: 1