#507

04.07.2011 19:51
0 Kommentare
Share

One problem when relaunching large projects with a ton of images is to re-create all the thumbnails that users have uploaded in the years. If you don’t use paperclip (ruby) or anything like it in PHP (is there any like it!?) where you can run run one command to re-create all the thumbnails in all specified sizes your can try to keep it flexible and create every image on demand.

Theory

The Webserver should serve the image if it exists. If the file does not exist, the request should be redirected to a PHP script that searches and creates the requested image file (in requested size) at exactly the location it was originally requested. The second request on the file will not be redirected to the PHP script and will server the image that now exists.

Practice

So the first thing to archive is to send the request of a not existing image to a PHP file. That’s easy if you’re familiar with all the nginx directives:

This rule can be combined with the anti-hotlinking rules for images with nginx I showed you last week.

After that we need to create a format that includes width and height of any requested image so that the

thumbnailer.php

knows which size the created image should have. A valid request for a resized file should always have all parameters (width, height) in it:

../img/public/9c4be029/438xauto/filename.jpg

This makes it easy to split up width, height with a regexp in

thumbnailer.php

. The following code is just an example. You’re surelly integrate the logic into your frameworks:

That’s it! After that you can request any image in any size on your webserver by only creating it once it’s requested.

There are some things you can add, like other parameters in the

$formatRegexp

string to add different resizing methods or even filters, or limitations on the

width

and

height

parameter.

Appendix: Apache

It’s almost the same thing with apache. Just add a few lines to your

.htaccess.

and all your image requests are redirected to the thumbnailer (or anything):

#506

28.06.2011 11:16
0 Kommentare
Share

Almost two weeks ago I moved my personal blog-project horrorblog.org from a domainfactory managed hosting server to a JiffyBox which is a scalable cloud server solution also by domainfactory. I won’t talk about the setup for now (but later this or next week) but I want to show you an example for a nginx config file that prevents your images from beeing hotlinked but still enabling google and facebook.

Prevent hotlinking in nginx is really simple and some rules and examples can be found via google:


# apply this rule on any location that’s an image using Regexp

location ~* \.(png|gif|jpg|jpeg|swf|ico)(\?[0-9]+)?$ {

  # block empty blocked or whiteliste referers

  valid_referers none blocked horrorblog.org www.horrorblog.org;

  if ($invalid_referer) {

    return 403;

  }

}

This works fine, unless you won’t have your images displayed on facebook when anybody likes your stuff with the facebook share button (og:image) or in google image search. The solution that enables facebook to grab the images from your host is by adding

~\.facebook\.

and

~\.fbcdn\.

to the whitelist of hosts:


# apply this rule on any location that’s an image using Regexp

location ~* \.(png|gif|jpg|jpeg|swf|ico)(\?[0-9]+)?$ {

  # block empty blocked or whiteliste referers

  valid_referers none blocked horrorblog.org www.horrorblog.org ~\.google\. ~\.yahoo\. ~\.bing\. ~\.facebook\. ~\.fbcdn\.;

  if ($invalid_referer) {

    return 403;

  }

}