Rebuild Thumbnails

[Forrest]

If you want to poke around... check out

administrator/components/com_virtuemart/html/shop.product_details.php
administrator/components/com_virtuemart/html/shop.browse.php

administrator/components/com_virtuemart/classes/ps_product
administrator/components/com_virtuemart/classes/ps_category

The problem likely doesn't reside there tho.
But most likey here:

administrator/components/com_virtuemart/classes/htmlTools.class.php
administrator/components/com_virtuemart/classes/imageTools.class.php

I hacked the htmlTools or imageTools to solve my problem in a rough way, but at this point I don't recall where or which file... though I think it was
administrator/components/com_virtuemart/classes/htmlTools.class.php

I just removed an if statement, from my recollection, as the function began to check image dimension.

[linux4me]

I was having the same problem after an upgrade from 1.1.3 to 1.1.4, but found that new category images that I added as a test in 1.1.4 did have the "resized/" prepended to the path name for the thumbs in the database.

I ended up fixing the problem--at least temporarily--as I described in this post using some SQL queries with phpMyAdmin, but as you can see in that thread it didn't appear to work for the OP.

I agree that the problem must lie in the code somewhere, as I don't believe the 1.1.3 -> 1.1.4 upgrade altered anything in the database. I'm going to look around later and see if I might have copies of the files listed above from a 1.1.3 installation, but I don't think I do. If someone still has a copy of the 1.1.3 PHP files that might be responsible and can post them, I can do a quick file comparison with the 1.1.4 versions to see what might have changed and we may be able to get to the bottom of this...

[Forrest]

All good catch linux4me. The rabbit hole gets deeper....

[linux4me]

I found the file that appears to be causing the problem, thanks to Forrest.

First, I ran the SQL statement to reset all my thumbnail image paths to the full image path, removing the "resized/" I had added via phpMyAdmin to work around the issue. Then, I went through the list of possible files Forrest suggested as the cause one at a time and replaced the one on the server with an older version which I think is from 1.1.3.

The culprit turned out to be:

administrator/components/com_virtuemart/classes/ps_product

Replacing version 1948 2009-09-30 with version 1599 2009-01-08 seems to fix the problem; the thumbnails are re-created in the "resized" folder as they should be. I haven't found any issues using the old file creates. I have attached a copy of the ps_product.php that's working in a zip file in case anyone wants to try it.



[attachment cleanup by admin]

[linux4me]

You aren't going to believe this!

I have been playing with the 1.1.4 version of administrator / components / com_virtuemart / classes / ps_product.php to see if I could find the change in the code that was causing us such headaches.

On line 1364, the 1.1.4 version reads like this with an 'and':

Code: [Select]

if(PSHOP_IMG_RESIZE_ENABLE == '1' && $resize==1) {The file I used that fixed the problem with the thumbnails has an 'or' in the same location:

Code: [Select]

if(PSHOP_IMG_RESIZE_ENABLE == '1' || $resize==1) {I substituted the 'or' for the 'and' and low and behold, it worked! The thumbnails are showing up without the need for the "resized/" workaround in the database.

I haven't found any other issues yet. It would be great if someone else could give it a try.

This also fixed my problem with the full-sized images showing up for categories and products in the back end.

[Forrest]

I'll check it out tonight! Nice find linux4me. You're a stud.

Funny... so I checked it out, and that is where I had commented out some functioning... including the if statement... I just never caught the difference between || and &&.

Having found that, there is still a problem with my system. While it solves what has been addressed here, I still have the problem of the system very randomly choosing to use, or not, the resized image vs the product_thumb_image.

I'm at a loss, but it works well either way in my case, so it's not that big of deal.

Linux4me, I'd say you nailed it. Kuddos!

[n3m3sys]

Bravo linux, ha funzionato alla grande!

Worked like a charm!!!
I think it may be considered [SOLVED],thanks to linux4me!

[copperwire]

I registered just so I could say THANK YOU to linux4me. It was such a big relief to get it fixed with that little edit!

[publipoint]

Same situation here. Everything is fine in the category, but once I reach a product image...well...the image is full.

[da_mascus]

2. sql: update jos_vm_product set product_thumb_image = product_full_image

hey guys.
is there a way how to reverse this command?
After I used it to make the thumbnails, my product flypage starterd using the original picture as a thumbnail image. look at the pic if you like:
http://sw33t.sk/ukazka.jpg

thanks in advance

[PRO]

da_mascus are you saying you dont have a small image anymore?

Do you have dynamic resize enabled?

[da_mascus]

yop, it is enabled. the permissions are fine, even the thumbs in the folder are the right size.

but since I used that command in phpMyadmin, every product detail page started using the full size image instead of the thumbnail one.

btw this is the piece of code that shows the thumb inage in my flypage layout.

Code: [Select]

<div class="primage"> <?php echo $product_image ?><br/>
                    </div>
maybe my flypage is using a wrong VM variable ?


bottom line: is there a way how to reverse the command ?

[PRO]

no it cant.

BUT, if you have a recent CSV import with the thumb image url, you can upload it again.

but, THIS HAS TO BE A SIMPLE FIX.

[JOOblogs]

1. By default VM use resized image for GD render . So in case resized image have smaller size than GD re-resize unuseful !
GD function should take org image for resize not resized image.
2. Solution
+ Delete all images in resized folder.
+ Open file
administrator\components\com_virtuemart\html\shop.browse.php

Replace

Code: [Select]

        if( $db_browse->f("product_thumb_image") ) {
            $product_thumb_image = $db_browse->f("product_thumb_image");
}
else {
if( $product_parent_id != 0 ) {
$product_thumb_image = $dbp->f("product_thumb_image"); // Use product_thumb_image from Parent Product
}
else {
$product_thumb_image = 0;
}
}by

Code: [Select]

        if( $db_browse->f("product_thumb_image") ) {
            $product_thumb_image = $db_browse->f("product_full_image");
}
else {
if( $product_parent_id != 0 ) {
$product_thumb_image = $dbp->f("product_full_image"); // Use product_thumb_image from Parent Product
}
else {
$product_thumb_image = 0;
}
}
Above code will allow use full size image for GD resize without resized image that stored in db !
So if you dont have any require with resized image stored in db. You can try above code.
I have used this code for my client.

[LeonZ]

I was having these problems also. Wanted to have a productrow of 2 on my categorie page but not knowing what to put into the GD size so the categorie page looks good.

For testing I altered the browse page and gave in a product_thumb width.
for my browse_2.php the code was

Code: [Select]

          <?php echo ps_product::image_tag( urldecode($product_thumb_image), 'class="browseProductImage" border="0" title="'.$product_name.'" alt="'.$product_name .'"' ) ?>and I changed it to

Code: [Select]

          <?php echo ps_product::image_tag( urldecode($product_thumb_image), 'class="browseProductImage" border="0" width="112" title="'.$product_name.'" alt="'.$product_name .'"' ) ?>This way I was able to find out the exact size of my thumb so I didn't have to loop through all steps over and over till everything suited my needs and looked fine.

ofcourse if you want your thumb just a little smaller this can be a nice temporarily workaround.