Broken images

[Mark]

Hi around the time I updated to 1.1.0 many images became unusable by the system and now just have camera image placeholders throughout the site.

Uploading new replacement images doesn't help.

Ive tried regenerating thumbnails and the .htaccess file

The process is that Im uploading product images, they upload fine, but then show as camera image placeholders in the back office.

Sometimes they appear fine on the front office, sometimes not.

Thinking its possibly something to do with Image Generation, Ive attached two pictures here of my image management section

 

 

[Traumflug]

Alright. Now we have not one, but two solutions.

Solution 1 is another fallback for image types:

https://github.com/thirtybees/thirtybees/commit/ba81aad0667658f1f083f8a4a033442bbd4526d2

This loads these images without any change to the theme or the module. Inspired by @datakick's pull request, but only for these fallbacks (I'm not sure which implications the other place might come with).

Solution 2 is a fix in the theme, of course:

https://github.com/thirtybees/niara/commit/df3c7f79af47ba7dde4454c990d041cc096722f8

Yes, it's that simple. Just replace 'medium_default' with 'medium' in the theme's template. Apparently this spot got forgotten when image types got renamed.

 

And then there are improvements like this (templates of the module and both themes):

https://github.com/thirtybees/niara/commit/dd798ad52c103c9e97bd7cf1b0f2bc910f084b27

which move definition of the image entirely into the template and accordingly, into the theme. Defining certain images in PHP as well as in the template doesn't make much sense. For one it's error prone, because the other definition is often out of sight. For two, only the theme template knows which image type fits the theme best.

 

P.S.: these fixes took a while, because my first attempt was to search the best matching image type in PHP:

https://github.com/thirtybees/blocknewproducts/commit/58c1069a7b595578f6cf3f5b792a821168e4deb3

https://github.com/thirtybees/blocknewproducts/commit/54708c09a550233db4cc556ea93ed75138f64d47

... until I recognized that a module can't really know what a theme wants. Sometimes one has to implement something just to find the just written code to be suboptimal. A learning experience.

[zen]

Wich theme are u using right now on front office ?

you can give the shop URL please ? In private if you prefer.

 

Edited September 14, 2019 by zen

[datakick]

It is possible you are using some module that has hardcoded image type, ie home_default instead of home. 

Please share your url, otherwise it's just a guesswork 

[Mark]

An example is here https://product.solutions.org.nz/remote-car-alarm-with-central-locking-and-engine-disable

You'll notice in the back office all of these images are presented as placeholder images (image attached)

Im using community theme

Edited September 14, 2019 by Mark

[zen]

datakick was right : you need "home" as a default image size, but it's not available on your settings, so it's not created, therefore you can't show them in front office.

You need to edit the images config, and delete all images sizes wich are not used and estup one for "home" and others missing.. then regenerate thumbnails !

[Mark]

OK, I had to manually delete the community theme and manually reinstall. What should the image settings be for "home" (Note they also dont sometimes appear in the back office and in places other than "home" either)

Edited September 14, 2019 by Mark

[zen]

Now you did this, your theme request this image :

https://product.solutions.org.nz/194-community-theme-default_cart_default/remote-car-alarm-with-central-locking-and-engine-disable.jpg

then you need this image setting : community-theme-default_cart_default,

what size is it ? I don't know but it's should be square I guess.

 

Also on the same page you need also this image : https://product.solutions.org.nz/98-home/3000-lumen-headlight-with-sensor-and-red-light.jpg

and that is "home"

[zen]

If you want, I can fix that for you with BO Access, as u like 🙂

[musicmaster]

I am puzzled. Prestashop used -home until 1.4. With 1.5 it got a new theme and attached _default behind all the image formats. Are we now going back to the 1.4 naming convention?

[Occam]

2 hours ago, musicmaster said:

Are we now going back to the 1.4 naming convention?

Though I'm not sure if compatibility with PrestaShop is a chief aim of thirty bees anyway, I'm puzzled too. But in this case not by any lack of compatibility, because my current test professional (thirty bees 1.1.0) creates the expected defaults,  though not really following the naming convention (default is not attached but prefixed for some unknown reason):

en-default-Niara_home_smaller.jpg, en-default-Niara_large.jpg ...

Weird! But at any rate bad practice. 

 

Edited September 14, 2019 by Occam

[lesley]

When you install a theme, the configuration should add the image types needed for the theme, so changing the name should not be a problem you just need to regenerate the images. 

[Occam]

44 minutes ago, lesley said:

When you install a theme, the configuration should add the image types needed for the theme, so changing the name should not be a problem you just need to regenerate the images. 

This already has a tiny disadvantage: the Niara theme won't find the images afterwards, because in the theme as well as in many modules the picture format names are hard coded - no matter what @zen believes.

[lesley]

@Occam Good point. I think we are going to have to figure out a perm fix for this. That is something we did not take into account. 

[zen]

16 hours ago, Occam said:

This already has a tiny disadvantage: the Niara theme won't find the images afterwards, because in the theme as well as in many modules the picture format names are hard coded - no matter what @zen believes.

I do believe that everything can be fix.. otherwize I don't know what you think I believe... I just want to help this user on his particular case, that should not happen, but before fixing the core, this user needs specific help in his settings, and I'll provide this care if he accepts.

I know images are harcoded, that's where the matter starts, Also there is way  too much images sizes for produits... only 3 or 4 will be enough and will help to maintain an image directory light.

[Traumflug]

On 9/14/2019 at 12:55 PM, musicmaster said:

I am puzzled. Prestashop used -home until 1.4. With 1.5 it got a new theme and attached _default behind all the image formats. Are we now going back to the 1.4 naming convention?

It simply shouldn't matter which image type names a theme uses. There's a database table storing these image types and the whole point of this table is to allow changing these names. A theme can define any image type name it feels a need for. This was "always" the case.

Since 1.1.0, the theme name gets prefixed to this image type name. Code for this was also "always" there, it was just entirely broken.

With this code being fixed, thirty bees allows now distinct image types in distinct themes. thirty bees features multishop, each shop can have a different theme and each theme can have its own idea of image sizes. Image type 'home' in theme 1 can have an entire different size than image type 'home' in theme 2, after all.

And then there are modules entirely ignoring all this and hardcoding image names, as if there was always just one shop, just one theme and this theme always had defined image types the module wants. A static world view, just like 1990.

Care was taken of these hardcoded image types as well, of course. Requests for images not existing on disk get forwarded to PageNotFoundController, which then tries to find the best match actually existing. Last resort of this controller is to send this camera image, so in the case discussed here it apparently gets activated as expected.

Apparently there's a situation possible where the fallback mechanism doesn't find what it could find. Debugging can start in these two locations:

https://github.com/thirtybees/thirtybees/blob/1.1.x/controllers/front/PageNotFoundController.php#L57

https://github.com/thirtybees/thirtybees/blob/1.1.x/classes/ImageType.php#L241

[Traumflug]

2 hours ago, zen said:

Also there is way  too much images sizes for produits... only 3 or 4 will be enough and will help to maintain an image directory light.

Jungle drums say, Google still ranks layouts with exactly matching image sizes higher than those using one downloaded image for all these small representations/icons.

If you changed your theme to get away with fewer image types, don't hesitate to remove the no longer needed ones from the list. Bonus points for also removing them from the theme's config.xml (which gets read at theme installation time, only).

[Occam]

50 minutes ago, Traumflug said:

It simply shouldn't matter which image type names a theme uses. There's a database table storing these image types and the whole point of this table is to allow changing these names. A theme can define any image type name it feels a need for. This was "always" the case.

1. I'm afraid, I wouldn't agree, Markus. This would be ok if there weren't third party modules that use standard naming convention and don't consult any database entries.

50 minutes ago, Traumflug said:

And then there are modules entirely ignoring all this and hardcoding image names, as if there was always just one shop, just one theme and this theme always had defined image types the module wants. A static world view, just like 1990.

For a start-up like thirty bees a statement like that sounds pretty presumptuous. Shouldn't thirty bees remain compatible for now?

2. Thirty bees 1.1.0 stores different names depending on the fact if you use only one or several languages.

Example = 1 language: Niara_home

Example > 1 language: en-default-Niara_home, de-default-Niara_home, es-default-Niara_home etc.

The latter will be found, the first not, as you may read form this exemplary code from product.tpl:

src="{$img_prod_dir|escape:'html':'UTF-8'}{$lang_iso|escape:'html':'UTF-8'}-default-large.jpg"
srcset="{$img_prod_dir|escape:'html':'UTF-8'}{$lang_iso|escape:'html':'UTF-8'}-default-large.jpg"

Not to mention the fact that the theme installer doesn't configure a default_large master file for Niara.

There's something fishy about it

Edited September 16, 2019 by Occam

[musicmaster]

3 hours ago, Traumflug said:

It simply shouldn't matter which image type names a theme uses. There's a database table storing these image types and the whole point of this table is to allow changing these names. A theme can define any image type name it feels a need for. This was "always" the case.

Try to install a fresh TB 1.10 with the Niara theme and you will see dead image links in the new products section. That module is looking for medium_default and that is not available as only Niara image formats are generated.

I doubt whether the PageNotFoundController can be a good solution. Modules expects a certain format and when they receive another format their layout can become seriously damaged. 

 

[datakick]

I propose this pull request to strengthen backwards compatibility. @Mark, could you verify that it fixes your issue?

[Traumflug]

22 hours ago, Occam said:

50 minutes ago, Traumflug said:

And then there are modules entirely ignoring all this and hardcoding image names, as if there was always just one shop, just one theme and this theme always had defined image types the module wants. A static world view, just like 1990.

For a start-up like thirty bees a statement like that sounds pretty presumptuous. Shouldn't thirty bees remain compatible for now?

thirty bees' message isn't to stick in the 1990's. thirty bees' message is to fix bugs. That's what happened.

Sometimes fixing one bug exposes another bug. In such cases the right thing is not to revert the bugfix, but to fix the other bug as well.

[Traumflug]

6 hours ago, datakick said:

I propose this pull request to strengthen backwards compatibility. @Mark, could you verify that it fixes your issue?

Not sure which pull request you're talking about. I think the best solution is to let the module search available image types for the best match to the desired size. Another approach would be to let the module register it's own image type. This should reasonably work for all themes and arbitrary image names, then.

[Traumflug]

20 hours ago, musicmaster said:

Try to install a fresh TB 1.10 with the Niara theme and you will see dead image links in the new products section. That module is looking for medium_default

I see it now. The obvious quick fix is to change this name in the template. views/templates/hook/blocknewproducts.tpl, line 33. Names for image sizes were changed already.

[Occam]

I'm afraid you missed the point. This is not about fixing bugs, this is about maintaining compatibility.

[datakick]

26 minutes ago, Traumflug said:

I think the best solution is to let the module search available image types for the best match to the desired size.

Yes, the best solution would be to fix all modules. Unfortunately that's not realistic solution. There are many modules that uses hardcoded `large_default` or `home_default` image types. These modules don't work on 1.1.0 anymore. 

[Traumflug]

26 minutes ago, datakick said:

Unfortunately that's not realistic solution. There are many modules that uses hardcoded `large_default` or `home_default` image types. These modules don't work on 1.1.0 anymore. 

Dealing with this class of retrocompatibility would mean to try not only with appending _default, but also with removing this part of the name, right?