This PR contains:

• Code formatting updated to PSR12 standard
• Added strict typing (and static analysis check using Psalm)
• Upgraded Glide to v2
• ~~Added support for running testsuite on PHP 8~~ New Github Actions worfklow file (as TravisCI builds are extremely backlogged)

At the moment, when a client request an image, a php process on the server must be started to transfer the image to the client. For a low traffic website this won't be a problem, but for a high traffic site the server might get flooded with requests to transfer images.

One possible way to avoid invoking php when an image gets requested is to create the image on the path of the request url.

Let me clarify that a bit. Instead of using get parameters to specify how an image should be manipulated, a regular url should be used. Eg: https://glide.herokuapp.com/height/100/with/500/sharp/2/kayaks.jpg If this manipulation does not already exist in cache, create it in the public folder of the server using path "/height/100/with/500/sharp/2/kayaks.jpg" and return the image via php. The next client that comes by to retrieve that manipulation won't trigger php on the server as the webserver will return the cached file on the filesystem.

I hope this suggestion is a bit clear.

Currently Glide does not do any cache cleanup, meaning it generates manipulated images and places them into the cache file system, but it never deletes them. It's possible that over time this cache gets large and contains many unused image manipulations.

The simple solution here is to simply delete the entire cache periodically, and on small projects this is probably fine. But on larger projects it could be problematic since all image manipulations will have to be regenerated.

It would probably be good if Glide came with a CacheCleanup helper. This cleanup tool could be run every time a request is received, or it could be setup with a scheduler (probably better). Something like:

$cache = new Filesystem(new LocalAdapter('cache-folder'));
$cleanup = new CacheCleanup($cache)
$cleanup->expire(2592000); // 30 days

This approach would delete any manipulations older than 30 days. This can be determined easily use the $filesystem->getTimestamp() method.

However, this technique will not take into consideration whether they are being actively accessed or not. Using the last accessed date would be much more complicated since this information is not readily available. To do this you would need to create a data store, and save this information every time a manipulation is created. I feel this falls outside of the scope of this project. If this sort of cache cleanup is needed, developers are welcome to implement this themselves.

I run glide on a very large site, lots of traffic and we had issues with the temp image filling up the server just because one image was broken, also the part setting the jpeg image in a white image was breaking the progressive jpeg format. I don't see the utility of it so I removed it. I can put it back for jpeg only, it just doesn't work for progressive jpeg

Because after #7 glide stores images with the query params as md5 in the filename there is not easy way to use try_files to let nginx find the cached image itself and speed up the whole process a lot.

Is there an easy way to change how getCachePath generates the filenames so I can make them so that nginx can find them?

Actually does not seems possible to specify a custom centering point for resize fit/crop operations.

Some cms allow the user to specify the focus coordinates for each image.

I propose to add an argument like this focal_coords=20%:70% to say that the focal point will be at 20% x and 70% y.

I am building a Laravel 8 app. I have some images related to products.

When I loop the images the response times from my local environment grow with each request. See the screenshot:

I am using the exact code from the controller shown in the docs:
https://glide.thephpleague.com/1.0/config/integrations/laravel/#installation

My route is:
Route::get('glide/{path}', [App\Http\Controllers\GlideImageController::class, 'show'])->where('path', '.*');

And my view looks like this:

<x-test-layout>

    @foreach ($products as $product)
    {{-- <img class="max-w-sm" src="/storage/{{ $product->imageUrl() }}" alt=""> --}}
    <img class="max-w-sm" src="/glide/{{ $product->imageUrl() }}" alt="">
    @endforeach

</x-test-layout>

The non- N.B. x-test-layout is just a bare bones html boiler plate.

Can anyone tell me what am I doing wrong?

Hi,

I am using this lib as part of a laravel 4.2 instalation with the following code:

$server = League\Glide\ServerFactory::create([
    'source' => public_path()."/uploads",
    'cache' => public_path()."/uploads/imgCache",
]);

Route::get('/loadimage/{type}/{id}/{width}/{height}/{crop}/{name}', function($type, $id, $width, $height, $crop, $name) use ($server){ 
    $server->outputImage(
          $type.'/'.$id.'/'.$name,
           [
                'w' => $width,
                'h' => $height,
                'fit' => ($crop == 1 ? 'crop':'max'),
           ]
    );
});

I am having some very weird issues:

• Some times when refreshing a page i just get an image and nothing else
• Sometimes a variety of images on the page are all showing the same image (even if they are not called using the same path)
• sometimes images take ages to load and thus dont display in email clients (such as outlook) however they work fin else were - it seems like the caches images are not being used as its recreating them every time?

We'd love to see (and be helpful in adding, if possible) Intervention\Image's watermark support come to Glide.

I would imagine the HTTP API could be a bit of an awkward place to try and manage that, so I wonder if it's something you could configure on the ServerFactory config or something, and then either allow a watermark=true parameter or force it to always be on for those server instance requests.

Perhaps something like this?

ServerFactory::create([
    'source'    => config('glide.source'),
    'cache'     => config('glide.cache'),
    'watermark' => config('glide.watermark') // would point to /img/watermark.png or similar
]);

It would be awesome to add face detection to the crop function. This might be a bit of a pipe dream. There is this PHP package. Also, could be good to look at this JavaScript project.

Function would work like this:

kayaks.jpg?w=500&h=500&crop=face

I noticed the issue for #206 had a pull request but it hadn't been merged yet because of naming issues. So I went to check in the Imgix api and made changes accordingly. In the imgix api the fill function is used for resizing and filling an image (so this function shoud actually do what is requested in the issue).

So in my PR I changed this function to the function made by @xor22h in the previous PR. Next to that I added the fillmax function to allow users to also fill and preserve ratio as the fill function used to do. If you rather have them the other way around I can change it since this would be a change affecting everyone using the fill method.

Hello,

I have a weird issue with Glide on a fresh local Laravel install (PHP 8.1.13 / Laravel 9.44.0). I followed the documentation to the letter, my route looks like this:

Route::get('/img/{path}', [ImageController::class, 'show'])->where('path', '.*');

I have an ImageController that looks like this:

namespace App\Http\Controllers;

use Illuminate\Contracts\Filesystem\Filesystem;
use League\Glide\Responses\LaravelResponseFactory;
use League\Glide\ServerFactory;

class ImageController extends Controller
{
    public function show(Filesystem $filesystem, $path)
    {
        $server = ServerFactory::create([
            'response' => new LaravelResponseFactory(app('request')),
            'source' => $filesystem->getDriver(),
            'cache' => $filesystem->getDriver(),
            'cache_path_prefix' => '.cache',
        ]);

        return $server->getImageResponse($path, request()->all());
    }
}

But when I try to access an image through the correct path, it gives me a "Could not find the image storage/images/portrait-rose.jpg." error.

Url is: http://localhost:8000/img/storage/images/portrait-rose.jpg

And if I try to access http://localhost:8000/storage/images/portrait-rose.jpg the image definitely shows up. What could be the issue there?

Thanks in advance.

I'm running the glide test suite on PHP 8.1, and it all passes except for one thing:

1) League\Glide\ServerTest::testMakeImageFromSource
Mockery\Exception\NoMatchingExpectationException: No matching handler found for
Mockery_8_League_Glide_Api_ApiInterface::run('/private/var/folders/wn/fk5c4mz15z56v0ztf3g4c5dh0000gn/T/GlideUCfJUM', []). 
Either the method was unexpected or its arguments matched no expected argument list for this method

I don't understand this error, but I figure it shouldn't be failing!

Parsing URL with security key causes performance on lots of requests (image gallery)

You have to keep in mind - html code makes tonns of async requests to your server that should start framework or even if you create native php file with configured Glide - even then launching PHP to just check signature - useless thing.

It should be like this: glide makes url to resize if image still not resized, but makes url to static file if it is already done.

Is it a good idea, you think?

Added the "fill-max" resizing option to the version 1.x branch. So that users which kept stuck at version 1.x can use this resizing option.

The code was taken from PR #332 which is now part of version 2.x

Some images converted to webp format has response type "octet-stream" and are empty in browser.

If copy link of image and put it into new tab everything is good.

The problem was resolved by removing raw: header('Content-Length:'.$this->cache->fileSize($path));

In the public function outputImage($path, array $params) file Server.php