Updating from 1.5.1 to Bleeding Edge Breaks Product Images

[Rhapsody]

I have been testing some bleeding edge updates and found that when I update a shop using bleeding edge, the product images are replaced by the camera icon on the product when displayed in the front of the shop because the images can't be found.  Rolling back to the stable version fixes this. The shop is running on PHP 8.0.30.  Shown below are the error log entries (multiple entries) displayed after the update.  Thumbnail generation does not find the images.  I've tried various setting changes on the Preferences, Image page with no luck.  Attached are screen shots of the original settings page and the new one.  Any ideas what needs to be done to fix this with the settings, or should I post a bug on github?

[28-Aug-2024 14:50:28 US/Eastern] PHP Warning:  Attempt to read property "images" on bool in /.../shop/classes/ImageEntity.php on line 118
[28-Aug-2024 14:50:28 US/Eastern] PHP Warning:  Attempt to read property "image" on null in /.../shop/classes/ImageEntity.php on line 118
[28-Aug-2024 14:50:28 US/Eastern] PHP Warning:  foreach() argument must be of type array|object, null given in /.../shop/classes/ImageEntity.php on line 118

[the.rampage.rado]

The code looks proper. In any case there is some local issue as the regeneration and the rewrite as a whole works with at least few installations (including mine 3 production installs and 2 test installs).

[Rhapsody]

Making progress - I found that turning off friendly URLs fixes the images on bleeding edge. I'll be looking into why the friendly path get broken.  Pass on any ideas you may have. 

[wakabayashi]

Just now, Rhapsody said:

Making progress - I found that turning off friendly URLs fixes the images on bleeding edge. I'll be looking into why the friendly path get broken.  Pass on any ideas you may have. 

Yeah, this is kind of logical. The problem is not the source files or the thumbnails. It's the rewrite.

[the.rampage.rado]

Check if mod_rewrite is on.

[wakabayashi]

7 minutes ago, the.rampage.rado said:

Check if mod_rewrite is on.

Pretty sure, otherwise all links would be broken or not?

[the.rampage.rado]

He's now using them so it's installed, yes.

Officially out of ideas! 😄

[Rhapsody]

Mod rewrite is on and functioning.  What I can't figure out is when I manually edit the .htaccess file (using cpanel rather than the TB save function) I still can't get the proper product image link redirection. I've also used an incognito window to make sure the browser isn't caching anything when I try this.

Feel free to pass on any other troubleshooting tips.

[datakick]

Maybe you have nginx in front of your apache? Or some other caching server?

 

[Rhapsody]

Another data point.  I have 3 shops hosted on different Linux hosts.  One is on GoDaddy, and the other two on Glowhost.  All three shops exhibit the same behavior when upgraded to bleeding edge.  Rolling back to stable 1.5.1 restores the images.

[DRMasterChief]

Was any solution found for this? Or what triggered it?

I'm experiencing a situation where, after updating to version 1.6, the thumbnails in the category previews are populated with the camera icon when there's no actual image.

Previously, nothing was displayed there at all, just a blank white space.

I have the .htaccess files from versions 1.5.1 and 1.6 for comparison, but of course, I'm stuck.

[the.rampage.rado]

36 minutes ago, DRMasterChief said:

Was any solution found for this? Or what triggered it?

I'm experiencing a situation where, after updating to version 1.6, the thumbnails in the category previews are populated with the camera icon when there's no actual image.

Previously, nothing was displayed there at all, just a blank white space.

I have the .htaccess files from versions 1.5.1 and 1.6 for comparison, but of course, I'm stuck.

Did you follow the guide from page 1? All entities set correctly? Here is an example from Warehouse:



Have you regenerated all thumbnails with the new settings down the page:


Did you regenerate your htaccess and does it include the images as:
....
RewriteRule ^categories/([0-9]+)(\-[_a-zA-Z0-9\s-]*)?/.+?([2-4]x)?\.(avif|gif|jpeg|jpg|png|webp)$ %{ENV:REWRITEBASE}img/c/$1$2$3.$4 [L]
....
RewriteRule ^products/([0-9])([0-9])(\-[_a-zA-Z0-9\s-]*)?/.+?([2-4]x)?\.(avif|gif|jpeg|jpg|png|webp)$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.$5 [L] and so on...

[Rhapsody]

3 hours ago, DRMasterChief said:

Was any solution found for this? Or what triggered it?

I'm experiencing a situation where, after updating to version 1.6, the thumbnails in the category previews are populated with the camera icon when there's no actual image.

Previously, nothing was displayed there at all, just a blank white space.

I have the .htaccess files from versions 1.5.1 and 1.6 for comparison, but of course, I'm stuck.

My problem was an override I had done that caused the problem.  Make sure you check for that.

[DRMasterChief]

Yes, everything is done as described, set SEO/URL,  regenerate all pictures and so on...
Changes does not have any effect.

Test shop:
# categoriesthumb images
RewriteCond %{HTTP_HOST} ^test.domain.xyz$
RewriteRule ^categoriesthumb/([0-9]+)(\-[_a-zA-Z0-9\s-]*)?/.+?([2-4]x)?\.(avif|gif|jpeg|jpg|png|webp)$ %{ENV:REWRITEBASE}img/c/thumb/$1$2$3.$4 [L]

Live shop:  (i think this is the part for categoriesthumb images, i do not have a listing with # in there)
RewriteCond %{HTTP_HOST} ^livedomain.xyz$
RewriteRule ^c/([0-9]+)(\-[\.*_a-zA-Z0-9\s-]*)(-[0-9]+)?/.+?([2-4]x)?\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3$4.jpg [L]
RewriteRule ^c/([a-zA-Z\s_-]+)(-[0-9]+)?/.+?([2-4]x)?\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3.jpg [L]

and i dont have any other overrides for pictures (caused in the theme).

There is the folder /thumb/  included in the test-shop rule,  but why?

Edited 22 hours ago by DRMasterChief

[wakabayashi]

In categories you have two different types of images:

\thumb is the preview image.

[Yabber]

Displaying a placeholder image for subcategories causes an bug in getSubCategories() method of Category class:
    foreach ($result as &$row) {
        $row[‘id_image’] = $row[‘id_category’];
        $row[‘legend’] = ‘no picture’;
    }
Whether the image exists or not, ‘id_image’ with the ID of the given subcategory is always returned.
And if there is no image, the rules from htaccess load a placeholder image.

 

[wakabayashi]

53 minutes ago, Yabber said:

Displaying a placeholder image for subcategories causes an bug in getSubCategories() method of Category class:
    foreach ($result as &$row) {
        $row[‘id_image’] = $row[‘id_category’];
        $row[‘legend’] = ‘no picture’;
    }
Whether the image exists or not, ‘id_image’ with the ID of the given subcategory is always returned.
And if there is no image, the rules from htaccess load a placeholder image.

 

I am not sure... Is this a bug report or an explanation? 

Do you have uploaded a thumb image for packets? Cause you are right, these are exactly the images we are talking about "thumb".

[Yabber]

32 minutes ago, wakabayashi said:

I am not sure... Is this a bug report or an explanation? 

Do you have uploaded a thumb image for packets? Cause you are right, these are exactly the images we are talking about "thumb".

I deliberately deleted the image for this one category to get the effect of displaying a placeholder image 🙂 
Whether this is a bug or not is open to debate.
If we decide to display subcategory images, we should add images to all categories. However, many stores do not have a uniform data management concept and add images to some categories but not to others. And with these placeholder images, it looks ugly.

[the.rampage.rado]

Merchants can always upload 1px transparent blank images if they only want graphics for only some of the categories.

[Yabber]

10 hours ago, the.rampage.rado said:

Merchants can always upload 1px transparent blank images if they only want graphics for only some of the categories.

A less labor-intensive solution is to replace the image /img/404.gif with an blank transparent image.