My Website Engine

Where to start this time?

Originally I worked my way down explaining my ideas for top level concepts like, layout themes, switching languages, discussion forums and automatic menu generation. I introduced relevant components as I went, however I think hands on people who have experience with other systems might be more interested to start at the bottom with some things that often cause niggly problems with established systems.

Image Handling

My camera is set to save raw image data. This gives me maximum resolution, flexibility and quality in post-processing of images before I upload them, but apart from converting to standard jpeg format, I don't want to have to create optimized image versions for my website by hand. Even after I had cropped it, the ajacent picture of my puppy, Tama, is 1763x2361 pixels. It is 1.7MB in size.

Web browsers do rescale images to fit the display, but transferring lots of full size images could criple page load and also gobbleup all the visitor's data allowance in a jiffy. To avoid this my web engine automatically creates and caches reduced versions. I find 720 pixels max width and height quite adequate for web page display and this one transfers in 0.082 MB.

The uncropped jpg version is 8.2 MB, so the image I generate automatically on the server saves you about 10,000% on your data allowance and loads a lot faster. My web engine also can automatically generate thumb nail size images. Here that thumbnail appears to be 0.0018 MB size. Click it to see the full precision image open in a separate window and watch how slow it is to load the first time. Note: that action WILL gobble up 8.2 MB of your data allowance on first access! My server-side cached images are meant to be only just good enough to embed on a web page. This speeds things up no end. By way of consistency my image macro (php function) always opens the full size original when you click on it.

Besides raw image data, I also set my camera to save a compact low resolution image (1280x960 pixels). The uncropped original here is 0.451 MB. It would be good enough for use in web pages, but would not have the precision necessary to produce a decent quality cropped version and it wouldn't let you view the full resolution when you do want it. None the less I could have just uploaded that rather than the full image, but either way my website engine only has to produce the reduced size image on first access and it keeps that on hand for all future page visits.

How it works

When a web page includes an image, my script modifies the path, inserting "/_image" folder and tagging .Webp filetype on the end. That image doesn't exist, so it generates a 404 file not found error. I trap that error and process it in a php script to strip off the .Webp and the /_images and find the original. This is then processed to produce the reduced inage and store it in the new path for future use.

Likewise, my thumbnail macro sends thumbnail sized images to the "/_thumbs" directory. If and when I do update an image original, then I will have to also delete the reduced size versions so that a new one will be generated, next time it is accessed. This is similar to clearing your web browser cache when reloading a page, but now it's done on the server when I update my site.

To make things easier to manage, I have a convention that any folder name that starts with _ is a folder of generated files. (Note: underscore is the universal "don't care" variable of the Prolog programming language.) There is no need to ever back them up. These folders or any part of their content can simply be deleted at will and my 404 processor will regenerate as and when needed.

My 404 (file not found) process is also instrumental in banning malevolent hack attempts, but I shall discuss that on my page about website security.