Skip to content
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

Glide Image Processing Issue with S3 (Minio) #5727

Closed
mikhailbot opened this issue Apr 1, 2022 · 7 comments
Closed

Glide Image Processing Issue with S3 (Minio) #5727

mikhailbot opened this issue Apr 1, 2022 · 7 comments
Labels

Comments

@mikhailbot
Copy link
Contributor

Bug description

Attempted to setup an asset container using S3 (via Minio in dev) for images, however unable to process any images using Glide hosted this way. The page will sit there attempting to load endlessly and also cause all other pages on the website to load indefinitely.

How to reproduce

  • Install Laravel then Statamic
  • Spin up local Minio (via Sail or similar)
  • Create image asset container using S3 as disk (including composer dependencies)
  • Create content that uses this asset container and attempt to process an image with glide

Example repo: https://github.com/mikhailbot/statamic-s3-glide-test
Requires adding an S3/Minio container called local. Add an image to the home content and then try to view it. Template simply outputs the contents and tries to use Glide on any images.

Logs

No logs recorded to laravel.log or `sail logs` (last log seen from sail is the accept http log for the page load that never completes).

Versions

Statamic 3.3.4 Solo
Laravel 9.6.0
PHP 8.0.17
No addons installed

Installation

Other (please explain)

Antlers Parser

regex (default)

Additional details

No response

@duncanmcclean
Copy link
Member

I think this might be fixed by #5725

@mikhailbot
Copy link
Contributor Author

While yes I’m super excited for that PR, images hosted on S3 should still be processable by Glide and storing them in the local disk cache. Others have that setup working as far as I’m aware.

I’m currently seeing if this happens on a site setup with Forge at the moment, and wondering if it’s an issue at the Sail level not Statamic.

@jasonvarga
Copy link
Member

#5725 not only adds the glide disk stuff, but fixes a file permission issue. I think that's the part that Duncan's talking about.

I'll try out Minio soon though.

@mikhailbot
Copy link
Contributor Author

Updated my test repo (composer update => Upgrading statamic/cms (v3.3.4 => v3.3.10)) but no changes sadly. The cached file doesn't appear to hit Minio/S3 either. Will hopefully have a chance this week to dig in more to find the logs or where the process is hanging exactly.

@mikhailbot
Copy link
Contributor Author

OK so did some digging and I think I know where the issue lies (or at least one of the spots). The local instance of Minio provided by Laravel runs on port 9000 which the Statamic\Imaging\GuzzleAdapter doesn't handle.

It's created from the Statamic\Imaging\ImageGenerator class which has a URL passed to it which is parsed (at least in
doGenerateByUrl but could be in other spots) but does not add in the port number (if existing).

In addition to the port number not getting passed around/parsed, the host is also localhost when it should be minio when interacting with the S3 API. If I change the constructor for GuzzleAdapter to use http://minio:9000 and ensure the ImageGenerator has a port defined things work without issue.

I'm still working on where these calls come from originally to determine where things go wonky and the impact of any changes there, but hopefully that makes some sense. For reference below is the .env config I'm using. The AWS_ENDPOINT is minio as that's what the Laravel container needs to get to the Minio container, while the AWS_URL is localhost as that's what my machine needs to get to the minio container.

FILESYSTEM_DISK=s3
AWS_ACCESS_KEY_ID=sail
AWS_SECRET_ACCESS_KEY=password
AWS_DEFAULT_REGION=us-east-1
AWS_BUCKET=local
AWS_ENDPOINT=http://minio:9000
AWS_URL=http://localhost:9000/local
AWS_USE_PATH_STYLE_ENDPOINT=true

@jasonvarga
Copy link
Member

The guzzle adapter shouldn't really be used. That only happens when you provide urls to glide and it can't figure out a corresponding asset.

How are you using your glide tags? If you pass assets to it instead of just urls, you should have more success.

@mikhailbot
Copy link
Contributor Author

mikhailbot commented May 12, 2022

Ah, damn my old habits clearly bit me--good catch. The top one is the way I've always done it (and to be fair works fine in many cases and shown that way in the docs) but it doesn't work with Minio/S3.

If I use either of the bottom forms of glide it works beautifully (including the new version where cached things are also stored on the S3 filesystem).

# Doesn't work

{{ images }}
    <img src='{{ glide:url width="120" height="500" }}'>
{{ /imags }}

# Both work

{{ images }}
    <img src='{{ glide:id width="120" height="500" }}'>
{{ /images }}

{{ glide :src="images" width="120" height="500" }}
       <img src="{{ url }}" width="{{ width }}" height="{{ height }}">
{{ /glide }}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants