-
Notifications
You must be signed in to change notification settings - Fork 206
Description
I've started thinking about Glide 2.0. The purpose of this issue is to share those ideas and get some discussion going about it.
Serve cached images via web server
My number one goal for Glide 2.0 is allowing cached images to be served by the web server, instead of Glide. Meaning the first request to a manipulated image would hit PHP (and Glide), but all subsequent requests will be handled by the web server automatically. Further, beyond the standard front-controller rewrite rule (routing all requests through index.php), I don't want there to be any extra web server configuration required.
The simplest way to accomplish this is to save the cached images in the same place, and with the exact same URL as the requested images. This way, when the first request comes in, the cached image won't exist, so the request will be routed to PHP and handled by Glide. However, all subsequent requests will hit the cached image directly, without hitting PHP. This should greatly improve the performance of loading cached images.
New URL format
This will not be possible with GET parameters since they are not treated as part of the filename. Further, the proper file format extension (jpg, gif, png) is also required so that the web server will output it properly. Finally, this will also require saving images in a public folder. Here is a proposed format that I've been testing with that works well:
http://example.com/img/kayaks.jpg/w-800-h-500-fit-crop-s-5ac7f6163057bf1931fd5b513f797644939ece7724ee3846a27e9915f3ea5eda.jpg
It's obviously not as nice as the current GET based URLs, but maybe that's okay. By grouping the cached images into source image folders it's easy to delete all the cached images for a specific image.
URL generation
I really feel like URL generation using a helper method is going to solve a lot of issues. Right now Glide ships with a URL generator, but it's sort of buried in the security documentation. I think this has been a bit of an issue with Glide 1.0. It makes it look like you can easily just edit URLs, but in reality if you sign your images (and you absolutely should be) you have to use some type of URL generator.
By making a URL generation helper more of a first-class feature, it will help minimize the pain caused by the less desirable URL format. Plus it will make HTTP signatures easier to work with. It will look something like this:
<img src="<?=glide('landscapes/lake.jpg', ['w' => 800])?>"><img src="{{ glide('landscapes/lake.jpg', ['w' => 800]) }}">HTTP signature simplification
HTTP signatures would work in the same way as they currently do, except will also be part of the filename. I want to make HTTP signatures easier to work with in 2.0, since they are so important. Part of me is even tempted to require them. I want to make it possible to set the sign key right on the Glide object, and then let Glide check this value automatically when generating images, as opposed to right now where you must manually check the signature. This isn't a big step, but I think it's a hurdle for people new to Glide, and it's easy to skip setting them up.
// Setting the key:
$glide = ServerFactory::create([
'sign_key' => 'your-signing-key',
'source' => __DIR__.'/images',
'cache' => __DIR__.'/public',
'base_url' => 'public',
]);
// Verifying the key (happens automatically):
try {
$glide->outputImage($path);
} catch (HttpSignatureException $e) {
// handle failed signatures
}Securing image URLs
As already noted, to have the cached images loaded by your web server you must place the cached images in a public folder. However, we could still keep the current functionality, where the cached images are loaded through PHP. This can be helpful in situations where you want to do authorization checks on the cached images before displaying them. To make this work you would simply make your cache folder non-public.
From my experience, this isn't a super likely requirement. Typically HTTP signatures are a sufficient enough security since these URLs are next to impossible to guess. Just something to consider.
Supporting the old functionality
Finally, I hope to still support the old functionality. This may look like this, although this is still open for discussion:
// Will assume the new path format
$glide->outputImage($path);
// Old functionality, where you give it the source image path
// and an array of manipulation params
$glide->outputImage($path, $_GET);
$glide->outputImage($path, ['w' => 100]);Many people use Glide without using GET params, so being able to manually pass in an array of manipulation params is also important.