Create Caching

[masterexploder]

Need to restore the prior version of the library's caching mechanism (or something similar)

[deplorableword]

I've implemented a little cache as part of my image.php generation script, not awesome but it does the job.

http://github.com/deplorableword/glanceable-guardian/blob/master/image.php

[masterexploder]

Awesome, I'll take a look into it. Thanks!

[SalviJansen]

I hope this will be included soon as it is quite an important element...

[Egorka]

Caching is very necessary.

[masterexploder]

I plan on implementing this in the very near future

[masterexploder]

I'm at a bit of a loss as to how I should best implement caching. If I try and do it at the class or plugin level, I don't really have access to the things that would make caching worth-while. For example, you'd probably want to cache based on the filename and desired dimensions... well, you don't really have access to this until you set about resizing the image.

What I can do is write a generic "image.php" script that implements caching as an example, similar to what @deplorableword did. I'm open to suggestions as you guys have requested it... how would you like to (ideally) have caching work?

[deplorableword]

Could it not be baked into create?

So if a cache directory was set and an image request was sent (which was the same as a previous one) it would serve the file from the cache directory instead of regenerating it.

Would be handy to have an option to disable / enable cache each time you used Create and perhaps also specify a timeout of how long the cache should last?

[SalviJansen]

If I would use this script, it would be used quite intensively so I'm better of with a way to set the overall cache size rather then a timeout. If you specify a timeout only you can still get a huuuuge amount of pictures being cached.

I also played around a bit with deplorableworld's solution but I'm not a .cache file expert and creating extra cache folders on a php hosting requires access to .ini files. I don't see how his solution could work because I had to edit it to include mime-types. If not you get a text file if you hit refresh on the same picture. Well anyway, just my 2 cents...

[masterexploder]

deplorableworld's solution wouldn't require any access to .ini files or mime-type modification as it does a readfile inside the script... the extension is merely arbitrary so his capistrano script can clear caches properly without blowing away real images. Also, the cache folder can be wherever you'd like...

At any rate, even if you do it at create time, you don't have enough information to make the cache unique. The idea is that you'd like to cache the resizing of a given image to certain dimensions, etc... as such, you'd need to know those ahead of time (which you don't when you create the object). You only know these when you actually call the resize and other transformation functions. Hence my dilemma.

[deplorableword]

@SalviJansen I think dealing with 'old' files is bit beyond what were talking about here, you can fairly easily setup Cap or Cron to delete files *.cache that get stale or when your caching folder is too large.

@masterexploder Could we not serialise the options + filename passed to create and use that as a hash?

Perhaps a new method Get, which would eval based on the options if a cached version could be used and if not just calls Create and writes a cache?

[JensRoland]

I was missing the caching function as well, until I read this post on Stack Overflow describing a best practice using much faster mod_rewrite rules:

http://stackoverflow.com/questions/140734/best-way-to-cache-resized-images-using-php-and-mysql/141378#141378

Combining PHPThumb with Apache's own handlers is a much better solution than trying to invent a clever caching scheme in PHP. It'll be faster, simpler, and it will serve up large cached images without the memory overhead of streaming them through show(). PLEASE don't implement caching! (or if you do, let it be an optional plugin)

[masterexploder]

Yeah, I'm not sure I can implement a good bundled caching mechanism anyway without really messing with the API... this does seem to be the kind of thing that should be implemented depending on your needs rather than an inherent part of the library. Good link as well, thanks!