Legacy PHP called thumbnails do not load when too many thumbnails are called within the page

[misterburke]

I suspect this is issue caused by a configuration within Apache/PHP that prevents the mass loading of PHP scripts by a single user but this does appear to be a bug if not (or at the very least a strong enhancement request). When too many thumbnail images are requested on a page several of them will simply not load (showing only the 'alt' text):

You can replicate by refreshing this page:
Mods

In order to resolve this issue, I will likely decrease the number of downloads which can appear on any given page though this isn't preferable. It doesn't seem reasonable to alter the Apache/PHP configuration to accommodate these requests as it will affect the entire site.

Suggestion:
Rather than loading thumbnail images via a PHP script (ex. http://www.nma-fallout.com/vbdownloads.php?do=file&action=thumbnail&downloadid=40&d=1400186324) load them directly from a URL accessible thumbnail directory.

 

[Fillip H.]

You can replicate by refreshing this page:
Mods

I am unable to replicate this issue on your site.

Rather than loading thumbnail images via a PHP script (ex. http://www.nma-fallout.com/vbdownloads.php?do=file&action=thumbnail&downloadid=40&d=1400186324) load them directly from a URL accessible thumbnail directory.

It uses a PHP script in order to be able to dynamically resize images rather than have to go through expensive image manipulation techniques (which requires additional server software installed) every time the thumbnail changes. This way, the modification can also fall back to use the first available image should the user not have configured a dedicated thumbnail image.

 

[misterburke]

Thank you for the reply!

Hmmm, that's interesting... I can replicate in Firefox consistently. With Internet Explorer I need to clear my cache between attempts. I've replicated this on three PCs connected to two different internet connections.

It uses a PHP script in order to be able to dynamically resize images rather than have to go through expensive image manipulation techniques (which requires additional server software installed) every time the thumbnail changes. This way, the modification can also fall back to use the first available image should the user not have configured a dedicated thumbnail image.

To be the devil's advocate, it's already manipulating the images using the GD library (packaged with PHP, vBulletin will not run on a version low enough not to have GD), it appears to even store them physically with the thumb- prefix. So a file is already being resized and written, it's just they aren't/can't be linked directly (they're also stored outside the public root).

The occasional resizing of a thumbnail is less process consuming than indirectly serving images thousands of times via a PHP script which is what we'll be doing when the downloads area is live and activity picks up. It seems like an image re-process will occur regardless if the thumbnail is to change, since if the source is a screenshot it will need to be downsized and stored physically, so that appears to happen anyway. Each image script also occupies space in memory at run-time (storing the file, resizing the file, reading the file, etc), which isn't a big deal until you're handling a large amount of traffic. Every little bit adds up eventually.

I can lower the number of files per page and that will alleviate the issue but I do think being able to direct link thumbnails would be a good feature at the very least. Not serving the actual download files themselves directly is an ideal way to have a downloads area since that prevents leeching (and those file requests only come on demand, not with the page view) but it is less appealing for images.

I do see the purpose of the script, which is to add some additional handling of possible thumbnails but it seems inefficient for this to occur hundreds of times. That is however my opinion.

Please do consider this as feedback and not criticism, this is easily the best download add-on for vBulletin.

 

[Fillip H.]

I can see most of your points, but I want to point out one small thing:

(packaged with PHP, vBulletin will not run on a version low enough not to have GD),

This is false. GD is not packaged with PHP, it's an extension you have to explicitly install and enable.

99% of webhosts will do this, because users expect to be able to use either GD or ImageMagick (though GD is vastly more popular), but it's certainly possible to encounter a PHP installation without this extension.


I'll look into changing the behaviour so that it creates static files

 

[misterburke]

I can see most of your points, but I want to point out one small thing:
This is false. GD is not packaged with PHP, it's an extension you have to explicitly install and enable.

99% of webhosts will do this, because users expect to be able to use either GD or ImageMagick (though GD is vastly more popular), but it's certainly possible to encounter a PHP installation without this extension.

It comes bundled with most if not all binary distributions but you are right that it has to be explicitly enabled in the PHP config by uncommenting it. vBDownloads relies on it however, so unless it's enabled the image features already utilized by the add-on won't work anyway ;-) which was my response to the comment:

"...in order to be able to dynamically resize images rather than have to go through expensive image manipulation techniques (which requires additional server software installed)"

The add-on already has a reliance on the GD library for image processing, unless I am missing something.

I'll look into changing the behaviour so that it creates static files

Thanks. The screenshot functionality does the same thing (if there are a lot of screenshots) and also does a resize with styles but you're still downloading the entire image whether the user wants to view them fully or not. This does consume some bandwidth, especially if there are a large number of images on the page. Example here:

Fallout 2 line art (seen at the Fallout 2 release party)

There are some files which will conceivably have several screenshots that measure over 1200 pixels on length/width and this will result in a large amount of file traffic for pictures the user may not click on.

 

[Fillip H.]

After quite a bit of hassle (mostly trying to get the sodding GD library working on my Mac development server), this has now been implemented for release in v2.3.2, currently scheduled to be released Monday 4th

 

[misterburke]

Awesome!

 

[misterburke]

This appears to be working on the main category pages but on the file download page itself the thumbnail no longer loads:

 

[Fillip H.]

This is most likely a result of a customised template, as that code is nowhere to be found in the updated templates

 

[misterburke]

Looks like that was it, forgot I'd even customized any of those templates. This appears to be working excellently in that case!