{"action":"created","issue":{"url":"https://api.github.com/repos/thephpleague/glide/issues/170","repository_url":"https://api.github.com/repos/thephpleague/glide","labels_url":"https://api.github.com/repos/thephpleague/glide/issues/170/labels{/name}","comments_url":"https://api.github.com/repos/thephpleague/glide/issues/170/comments","events_url":"https://api.github.com/repos/thephpleague/glide/issues/170/events","html_url":"https://github.com/thephpleague/glide/issues/170","id":201019853,"number":170,"title":"Brainstorming on Glide 2.0","user":{"login":"reinink","id":882133,"avatar_url":"https://avatars.githubusercontent.com/u/882133?v=3","gravatar_id":"","url":"https://api.github.com/users/reinink","html_url":"https://github.com/reinink","followers_url":"https://api.github.com/users/reinink/followers","following_url":"https://api.github.com/users/reinink/following{/other_user}","gists_url":"https://api.github.com/users/reinink/gists{/gist_id}","starred_url":"https://api.github.com/users/reinink/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/reinink/subscriptions","organizations_url":"https://api.github.com/users/reinink/orgs","repos_url":"https://api.github.com/users/reinink/repos","events_url":"https://api.github.com/users/reinink/events{/privacy}","received_events_url":"https://api.github.com/users/reinink/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2017-01-16T13:32:28Z","updated_at":"2017-01-16T15:31:06Z","closed_at":null,"body":"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.\r\n\r\n### Serve cached images via web server\r\n\r\nMy 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.\r\n\r\nThe 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.\r\n\r\n### New URL format\r\n\r\nThis 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:\r\n\r\n```\r\nhttp://example.com/img/kayaks.jpg/w-800-h-500-fit-crop-s-5ac7f6163057bf1931fd5b513f797644939ece7724ee3846a27e9915f3ea5eda.jpg\r\n```\r\n\r\nIt'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.\r\n\r\n### URL generation\r\n\r\nI 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](http://glide.thephpleague.com/1.0/config/security/). 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.\r\n\r\nBy 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:\r\n\r\n```php\r\n<img src=\"<?=glide('landscapes/lake.jpg', ['w' => 800])?>\">\r\n```\r\n```blade\r\n<img src=\"{{ glide('landscapes/lake.jpg', ['w' => 800]) }}\">\r\n```\r\n\r\n### HTTP signature simplification\r\n\r\nHTTP 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.\r\n\r\n```php\r\n// Setting the key:\r\n$glide = ServerFactory::create([\r\n    'sign_key' => 'your-signing-key',\r\n    'source' => __DIR__.'/images',\r\n    'cache' => __DIR__.'/public',\r\n    'base_url' => 'public',\r\n]);\r\n\r\n// Verifying the key (happens automatically):\r\ntry {\r\n    $glide->outputImage($path);\r\n} catch (HttpSignatureException $e) {\r\n    // handle failed signatures\r\n}\r\n```\r\n\r\n### Securing image URLs\r\n\r\nAs 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.\r\n\r\nFrom 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.\r\n\r\n### Supporting the old functionality\r\n\r\nFinally, I hope to still support the old functionality. This may look like this, although this is still open for discussion:\r\n\r\n```php\r\n// Will assume the new path format\r\n$glide->outputImage($path);\r\n\r\n// Old functionality, where you give it the source image path\r\n// and an array of manipulation params\r\n$glide->outputImage($path, $_GET);\r\n$glide->outputImage($path, ['w' => 100]);\r\n```\r\n\r\nMany people use Glide without using GET params, so being able to manually pass in an array of manipulation params is also important."},"comment":{"url":"https://api.github.com/repos/thephpleague/glide/issues/comments/272892410","html_url":"https://github.com/thephpleague/glide/issues/170#issuecomment-272892410","issue_url":"https://api.github.com/repos/thephpleague/glide/issues/170","id":272892410,"user":{"login":"cdowdy","id":5969974,"avatar_url":"https://avatars.githubusercontent.com/u/5969974?v=3","gravatar_id":"","url":"https://api.github.com/users/cdowdy","html_url":"https://github.com/cdowdy","followers_url":"https://api.github.com/users/cdowdy/followers","following_url":"https://api.github.com/users/cdowdy/following{/other_user}","gists_url":"https://api.github.com/users/cdowdy/gists{/gist_id}","starred_url":"https://api.github.com/users/cdowdy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cdowdy/subscriptions","organizations_url":"https://api.github.com/users/cdowdy/orgs","repos_url":"https://api.github.com/users/cdowdy/repos","events_url":"https://api.github.com/users/cdowdy/events{/privacy}","received_events_url":"https://api.github.com/users/cdowdy/received_events","type":"User","site_admin":false},"created_at":"2017-01-16T15:31:06Z","updated_at":"2017-01-16T15:31:06Z","body":"> Checking to see if the cached image exists will be slow (ie. requires a request to Amazon S3)\r\n\r\nwhat I'm suggesting here would add complexity that may not be needed :) haha\r\n\r\nWhat if you were to save any image using the S3 adapter ( or any other non local one) to memory then on return visits provide the S3 url - either though x-accel/x-sendfile? The problem with the x-sendfile variants is you still need to make that call to the externally hosted images and I'm not so sure how that degrades in instances where the image still isn't uploaded to S3.  Or a cookie/session/token needs to be set which .. yeah not always ideal \r\n\r\n\r\nAside from your latest can-o-worms haha.. after thinking on it, as of right now I prefer your's and Jason's suggestion for the filename /modifications and how the url is structured. "}}
{"actor":{"display_login":"cdowdy"}}