I believe I have found (and fixed) two bugs in the image_tag() function of ps_product.php
I'm posting here in the hope that someone on the development team can verify this; and, if correct, get the fixes into the next official build.
1.
The line that says:
if(PSHOP_IMG_RESIZE_ENABLE == '1' || $resize==1) {
should be:
if(PSHOP_IMG_RESIZE_ENABLE == '1' && $resize==1) {
2.
The lines that say:
} elseif( file_exists($mosConfig_absolute_path.'/'.$image)) {
$url = $mosConfig_live_site.'/'.$image;
should say:
} elseif( file_exists( IMAGEPATH . $path_appendix . '/' . $image )) {
$url = IMAGEURL . $path_appendix . '/' . $image ;
This bug had prevented product images from displaying on the site and on the Product Images tab (but had not prevented them from being viewed in the links on the Product's Media List) whenever the image files are in sub-directories of shop_image/product .
This bug had made it impossible to organize images into subdirectories (perhaps based on manufacturer or category or whatever)
to avoid the 2,000 file-per-directory limit on FTP,
or to manage the files better,
like when different manufacturers periodically send you updated CSV (or EDI) and image files to bulk import periodically.
Here is an example of the image_tag() variables after fixing:
shaw/tile/resized/thumb_CS65A_00100.jpg
is what's in the thumbnail field of the vm_product data table, and that's the $image parameter that product_list.php passes to image_tag().
The $path_appendix parameter is: product
The initial URL formation is: http://gardenrugs.com/components/com_virtuemart/shop_image/product/shaw/tile/resized/thumb_CS65A_00100.jpg
This is correct even unpatched, but the unpatched code will then say the file doesn't exist; and then mess up the URL.
After the patched code verifying file's existence in
/home/gardenru/public_html/components/com_virtuemart/shop_image/product/shaw/tile/resized/thumb_CS65A_00100.jpg
the URL is now built correctly.
Before patching, it was testing the wrong places and constructing wrong URLs.
3.
The following is not a bug fix, but an enhancement to product.product_form.php.
Anyone who organizes images in sub-directories
may want to make this patch,
and it won't hurt anybody else.
Instead of the Product Images tab testing the write-ability of only /product/ and /product/resized/, it will check the subdirectories as well.
Replace the line that says:
$ps_html->writableIndicator( array( IMAGEPATH."product", IMAGEPATH."product/resized") );
with the following code instead:
$source_dir = IMAGEPATH."product" ;
$dirArray[] = $source_dir ;
foreach (glob($source_dir."/*") as $dir_entry) {
if ( is_dir($dir_entry) ) { $dirArray[]=$dir_entry ; }
}
foreach (glob($source_dir."/*/*") as $dir_entry) {
if ( is_dir($dir_entry) ) { $dirArray[]=$dir_entry ; }
}
foreach (glob($source_dir."/*/*/*") as $dir_entry) {
if ( is_dir($dir_entry) ) { $dirArray[]=$dir_entry ; }
}
$ps_html->writableIndicator( $dirArray );
In a previous post, I showed what to patch so you can organize images into subdirectories and still have the Product Images tab and the catalog front-end display them properly. But such images still weren't appearing in the standard modules. Below, I provide the patch to fix the code so the standard modules work with such images.
The file with the bug was: com_virturemart/show_image_in_imgtag.php
Replace this original code:
$basefilename = @basename(urldecode($_REQUEST['filename']));
$filenames[] = IMAGEPATH."product/".$basefilename;
$resized_filenames[] = IMAGEPATH."product/resized/".$basefilename;
with the replacement code below:
$filenameAlone = @basename(urldecode($_REQUEST['filename']));
$fileAndPathProvided = "" . $_GET['filename'] ; // this includes the entire path, if it was in the parameter
$pathOnly = str_replace($filenameAlone, "", $fileAndPathProvided); // remove the filename
$withoutResized = str_replace('resized/', '', $pathOnly); // if resized is in the path, remove it. Empty if no subdirectories used.
$basefilename = $withoutResized . $filenameAlone ; // this should work even for sites without subdirectories
$filenames[] = IMAGEPATH."product/".$basefilename;
$resized_filenames[] = IMAGEPATH . "product/" . $withoutResized . 'resized/' . $filenameAlone;
// In the absence of subdirectories, $withoutResized = "" , so this should work for others too.
That's it!
Its acceptable that the Product Images tab and the archive front-end affectation them properly. But such images still weren't actualization in the accepted modules.
_________________
Filtrete (http://www.iaqsource.com/category.php/3m-filters/?category=517)
Quote from: Black18rose on August 05, 2009, 08:36:46 AMIts acceptable that the Product Images tab and the archive front-end affectation them properly. But such images still weren't actualization in the accepted modules.
Hi. Can you clarify what you mean? Are you saying that you tried this and it did not work for you?
Hi jlwagner,
I have the same issue, since I have so many products I have them in sub directories too. Not sure what he was trying to say either, but your fixes did not work for me.
The issue for me is that all of the "/" are being replaced with "%2" and the theme was stripping out "/" on the details page with rawurlencode. It has to do with all of the urlencode and rawurlencodes, they output the url in html, but it just needs to be the actual text in the database.
Anyways, I think that the problem is either that urldecode or rawurldecode has to be used. Or maybe the encodded urls shouldn't use "echo" in the templates.
the main problem isn't building the url, its that the url is encoded in the javascript. It cannot be encoded in the javascript to work.
I have the same problem of gr8sale.
I have done the hack of three files and when I try to open the lightbox I see that the Url called replaced "/" with %2
Any solutions?
I see. I am not using lightbox to view the full-size images. I suppose that's why it all works for me.
The thumbs work right in the standard and third-party modules, and the full size images work fine for me if I don't use lightbox.
If and when I get around to patching lightbox so it works, I'll post it here and/or at ElectronicMother.com
Sorry I don't have a fix at this time.
--- J.
Quote from: gr8sale on September 13, 2009, 22:56:22 PM
This should fix it:
1) complete jlwagner changes
3) replace
<?php echo ps_product::image_tag( $product_thumb_image , 'class="browseProductImage" border="0" title="'.$product_name.'" alt="'.$product_name .'"' ) ?>
with
<?php echo ps_product::image_tag( urldecode($product_thumb_image), 'class="browseProductImage" border="0" title="'.$product_name.'" alt="'.$product_name .'"' ) ?>
basically just use urldecode($product_thumb_image) instead of $product_thumb_imagein the image_tag function
Which file are you refering to? I can't find the above code in any of the files jlwagner modified.
This should fix it:
in your template files just use urldecode.
instead of:
<?php echo $product_image ?>
use:
<?php echo urldecode($product_image) ?>
instead of:
<?php echo ps_product::image_tag( $product_thumb_image, 'class="browseProductImage" border="0" title="'.$product_name.'" alt="'.$product_name .'"' ) ?>
use:
<?php echo ps_product::image_tag( urldecode($product_thumb_image), 'class="browseProductImage" border="0" title="'.$product_name.'" alt="'.$product_name .'"' ) ?>
That did it! Thank you very much!
Finally after so many solutions from other people this one worked!!! I am using the 1.1.5 (2010) and this is still not fixed. Please add into the new release.
Thanks again steph.s