Use Filesystem disks within Glide

[jasonvarga]

Issue based on #1892

It would be great to allow the Glide cache to use a Flysystem disk when using the "cached" mode.
This would allow the cached images to be served directly from S3, for example.

It's a bit pointless in the regular non-cached mode since it has to go through the controller anyway, but that's irrelevant.

The PR was appreciated but it should be doable in a non-breaking way.

[GioChocolateBro]

Was just looking at this, would be great!

I think adding another optional key to the config disk => null would already solved the backwards compatibility.
The cachePath function could just check which to use. ServerFactory of glide already checks if the passed param should be a local path or is a disk.

If we're also able to set a base url ourselves we can get cached image from a CDN/Cloudfront instead of S3.

[Christophvh]

Would love this, but the thing I find very weird about this is why are presets or derived images considered cache? Let's say we have 10 variations of a big image. Those variations might also be pretty big. Putting that inside a cache driver seems very strange they just belong in the same place as the original images.

If we look at the very popular library laravel-medialibrary this just stores variations inside a sub-folder on the same location.

Using a CDN/Cloudfront for the caching part makes more sense to me.

[jasonvarga]

Any generated images are considered cache.

[Christophvh]

Any generated images are considered cache.

yeah exactly my point. in our case 90% of storage space is used by generated images/variations and those are just on the disk so s3 doesn't really do anything.

[jasonvarga]

Right. That's the point of this feature request - to be able to put the cache on s3, etc.

[ryanmitchell]

Just as a bit of a temporary workaround until core supports this more fully, you can do this as things stand:

In your AppServiceProvider:

        $this->app->singleton(\League\Glide\Server::class, function () {
            return \App\Classes\GlideServer::create();
        });

<?php

namespace App\Classes;

use Illuminate\Support\Facades\Storage;
use Statamic\Imaging\GlideServer as Server;

class GlideServer extends Server
{
    /**
     * Get glide cache path.
     *
     * @return string
     */
    public function cachePath()
    {
        return Storage::disk('s3')->getDriver();
    }
}

Then in your config/statamic/assets set your image_manipulation.route to your S3 url.

Theres a bit of an oddity where it prefixes the https:// in the URL with a /, but I got around that doing a str_replace in a ResponseCreated event listener

[jasonvarga]

Where there's a will, there's a way.

[jasonvarga]

This is available in #5725

Anyone interested in testing this out, you can adjust your statamic/cms requirement to dev-feature/glide-cache-disks.

Then check out the docs PR for information: https://github.com/statamic/docs/pull/791/files?short_path=1418281#diff-1418281be766d8af386e93fa6d0c158de252a521ea85f2c87b504f609f5c61d5

The Custom Disk (CDN) section is what you'll be interested in, but you may want to read it all anyway.

Please feel free to leave any feedback on either of the PRs.

I recommend a new test bucket/space to use as the cache, just so it doesn't unintentionally interfere with your assets.

[jasonvarga]

Oh and if anyone was using @ryanmitchell 's workaround above, you'll need to migrate over to this official thing once it's released.

[adnankussair]

@edalzell Shall we give this bad boy a try... probably a good idea to test on a test bucket (I think we still have that one we had setup earlier for the folder delete bug).