[bug fixed] Missing Resized Images in Front End

My client is using using the Isotope System to initially list titles for hire in their Video Store (later we will add cart and payments). Got it working nicely with the store and got a pop-up description, category icons, etc.

http://www.video-mania.com/dvd.html

isotope 0.1.3 stable build 6 Up to date.

In the Back-end everything is fine, the main image is uploaded and it displays correctly both in the (1) Product Managment List and (2) when editing the item a thumbnail appears with Description and Alt Text boxes (like normal). I can see them both (and verify them in system/html)

Front-End things are going wrong. The front-end Module is only making the thumbnail versions needed for the list ("thumb") and detail popup ("medium") for certain items, some it completely ignores. The only image assigned is the source-original one. You can visit the URL and look in the source for the commented print_r(); showing the item details. You will see the module skipped the rendering of the thumbnails for these items.

The needed thumbnails also do not exist in system/html. Only the BE thumbnails mentioned above are there.

Why is the Product List being so choosy?

[attachment=0:l366vtek]missing images.jpg[/attachment:l366vtek]

If its always pngs, i'd imagine either your hosting environment may have a problem with gd library png support - or maybe the getImage function itself does.

The only thing that seems to be wrong to me is that the image has not been physically made but the code assumes it has.

thyon you might want to edit your post, theres a few (all) mysql details in it

I'd have to agree with ramjet... Something is either up with the files themselves or with gdLibrary.

One thing I ran into recently was that a client had uploaded photos with a PNG extension when in fact they were JPGs and the gdLibrary did not like that one bit. It took me a while to figure out what was exactly going on because when they are labeled with the wrong extension you can still view them in a browser and on your desktop, etc...

Ok guys, chill!! There is nothing wrong with the Image, try not to blame the image, because if you read my original post correctly, you would have realised, that the small thumbnails in the BE are created, so there is nothing wrong with the images!!!

Quote:

---

In the Back-end everything is fine, the main image is uploaded and it displays correctly both in the (1) Product Managment List and (2) when editing the item a thumbnail appears with Description and Alt Text boxes (like normal). I can see them both (and verify them in system/html)

---

Product Listing in BE, so thumbnails are perfect, and GD Lib is ok.
[attachment=1:ugrq16cp]BE-productlist.jpg[/attachment:ugrq16cp]

Showing that the Image for the product is correctly uploaded (see behind mediabox pop-up -- thumbnail is perfect, so GDLib works)
[attachment=0:ugrq16cp]BE-imageupload.jpg[/attachment:ugrq16cp]

No worries, Thyon... Just trying to eliminate the obvious solutions before digging deeper :D

I assume you've done some tracking down of the code by now that does the resizing (IsotopeGallery.php)... I've never seen it not process some images and process others unless there was something characteristically different about them (width, height, filesize, filename) or the resize settings in the config (width, height, proportion/crop/fit to box, or the base System settings).

Can you try uploading the image using the TL core File Manager and try resizing it in the layout somewhere? Does that fail as well? Perhaps we can track it down that way... Is the image larger than 1200px in any width?

I've done this (although I knew it would work), that the image (taken actually from the isotope uploaded file), placed on the search page (unused) and resized to 150px height. The original image is 299x433px.

http://www.video-mania.com/search.html

I'll start debugging the core.

PS. Also, there is no IsotopeGallery.php in my installation (or I can't locate it) and I cannot figure out how the product rendered does the images, because it loads classes to render each element, and I don't know what the class is to render the images (I haven't got a local copy up and running, only the online version for the client).

My fault, Thyon... IsotopeGallery is coming in 0.2.0 :oops:

The images in the current existing version are generated in IsotopeProduct.php around line 181. Might want to try echoing out /adding some log messages to see what is happening. Like I said, I don't think we have had this problem, but if you are still stuck I would see if Andreas can help out, as he is good at diagnosing these things...

This is the result of my testing. The PHP installation is simply ignoring files as if they just don't exist. Since this is GoDaddy, and I'm not in the States, I'll never be able to fix this. What a disaster!

RESULT: 4 of the files are listed as existing, the rest are flagged as gone.

Code:

---

/home/content/69/5497969/html/isotope/1/18-Fingers-DVD-cover-37a53957.jpg -- is_file=[1]
/home/content/69/5497969/html/isotope/C/Chloe-84325c8d.jpg -- is_file=[]
/home/content/69/5497969/html/isotope/s/stacks_image_1392_1.png-40336158.png -- is_file=[1]
/home/content/69/5497969/html/isotope/t/the-day-the-earth-stood-still03030911-9928ea19.jpg -- is_file=[1]
/home/content/69/5497969/html/isotope/G/Girl With the Dragon Tattoo-97b6df12.jpg -- is_file=[]
/home/content/69/5497969/html/isotope/s/stacks_image_99_1.png-eb80902e.png -- is_file=[1]
/home/content/69/5497969/html/isotope/T/TrueBlood_DVD_Season1-b8fa3818.jpg -- is_file=[]

---

EDIT:
The only thing I can spot for now, is that the ones with UPPERCASE folders are the ones that are not flagged as files...

EDIT2:
Another thing, I've noticed that my installation looks like this. The folders with files are duplicated in uppercase and lowercase files, even though the files inside are Uppercase... very strange...

[attachment=0:37xpsvgd]isotope-folder.jpg[/attachment:37xpsvgd]

I've found the bug. Youre IsotopeProduct.php doesn't use the strtolower() function in the path.

Here is the corrected line (about 189):

Code:

---

$strFile = 'isotope/' . strtolower(substr($file['src'], 0, 1)) . '/' . $file['src'];

---

PS. Don't let me near any software, I tend to zoom in directly to all the bugs...

Good find. Although I have a feeling this is limited to crappy hosting like GoDaddy. They are AWFUL...

Thanks!!

This is actually a serious bug. Because in the Front-End your module is CREATING the uppercase folder e.g. "G" AND the file with new File(); Then all subsquent folder checks try to find the files inside the uppercase folders first and says they don't exist (because the subsequent files are in the lowercase folder.

Both, linux and Mac OSX have a problem with folders that are 1 letter upper or lowercase as they are considered identical to PHP. You MUST fix this bug and always keep it lowercase in all locations.

It has been passed on to the powers that be and should be in the next update (along with a lot of other fixes/things...) We're just getting ramped up with this, so we're excited to make it more stable and roll out some great stuff in the near future :D

we're on it!

Quote:

---

Postby thyon » Tue Jul 27, 2010 7:22 pm
I've found the bug. Youre IsotopeProduct.php doesn't use the strtolower() function in the path.

Here is the corrected line (about 189):

Code: Select all
$strFile = 'isotope/' . strtolower(substr($file['src'], 0, 1)) . '/' . $file['src'];

---

Thanks Thyon, I couldn't figure this one out.

It was line 188 for me, it worked immediately with a frontend reload.

I'm not sure it matters, but I thought I'd mention this website was on rackspace 'cloud sites', not godaddy.

Thanks for sharing. It's great