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

 

 

[Occam]

11 minutes ago, Traumflug said:

but also with removing this part of the name, right?

????

[Traumflug]

21 minutes ago, Occam said:

????

No worries, this is for developers understanding how fallbacks work.

[musicmaster]

The Prestashop solution was to standardize on the --xxx_default. That is the format of the standard theme and of the backoffice. Some themes just used that format. Others used their own format but left the Prestashop format on the disk for the modules and the backoffice. My preference would be to continue that policy. 

I don't like solutions with a notfound routine. It is not transparent and as such confusing. You are bound to get questions from people who notice that things don't work like they expected. Simplicity is a great thing. 

In my opinion highres images are a much bigger problem. I gave up on them after - probably due to some conflict between Panda and Thirty Bees settings - I ended up with four versions of every image.

Edited September 16, 2019 by musicmaster

[datakick]

56 minutes ago, Traumflug said:

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?

Yes, something like this helps in these cases: https://github.com/thirtybees/thirtybees/pull/1057/commits/83060729b33a7065a4f78bd7ded1de56ba198e07

 

[Traumflug]

4 minutes ago, datakick said:

Yes, something like this helps in these cases: https://github.com/thirtybees/thirtybees/pull/1057/commits/83060729b33a7065a4f78bd7ded1de56ba198e07

Excellent!

[zen]

Nice... AND usefull !

[Occam]

1 hour ago, Traumflug said:

No worries, this is for developers understanding how fallbacks work.

Exactly, hence my question marks!

 

40 minutes ago, datakick said:

Yes, something like this helps in these cases: 

No offense, but ... this is just wag the dog! The Niara theme is not so important, that you have to introduce  own functions. It would be much easier if this theme just meets conventions. Period!
And new creations like Niara_smaller and Niara_smallest are not covered either by other modules, because they are simply incompatible. Not to mention the fact that the Niara theme itself does not use underscores in image names.

[datakick]

44 minutes ago, Occam said:

No offense, but ... this is just wag the dog! The Niara theme is not so important, that you have to introduce  own functions. It would be much easier if this theme just meets conventions. Period!

There are no new functions specifically for Niara. The changes to themes and image types are global. 

44 minutes ago, Occam said:

And new creations like Niara_smaller and Niara_smallest are not covered either by other modules, because they are simply incompatible. Not to mention the fact that the Niara theme itself does not use underscores in image names.

What do you talking about? First of all, these image types were already used by community-theme-default. And secondly... they are used by the theme. That's the reason why they exists. Other modules may, or may not use this image type. But in any case they should check that it exists. 

[lesley]

I introduced the smaller and smallest images in the community theme over 2 years ago. https://github.com/thirtybees/community-theme-default/blob/1.0.x/product-list-item.tpl#L14  and the commit that did them, https://github.com/thirtybees/community-theme-default/commit/77f3b8ccd1f8fbf55e438411bd1eabb55ea26d7d#diff-e459bd7ac118329219aefa38093f2d1f

The reason was for performance, we added the modern srcset tags to the theme. We are trying to keep up with standards on both speed and html5. Not all themes will support them, but we want what we release to be as flexible and as fast as possible. 

[datakick]

Let me shed some light on this problematic.

Back in the day the image types were named simply 'home' or 'large', and that worked quite well. But then came multistore, and the ability to have multiple themes.

And now there was a big problem with image type name collisions. Because these two (or even more) themes could use different dimensions for 'home' and 'large' image types, there was a need to have unique image type identifier per theme. Somebody come up with the idea to append theme name to the image type. And because the default theme was named simply default, this resulted in image type names like home_default, large_default, cart_default....

Unfortunately, this new functionality was not adopted well. I believe the reason is partly in generic name of default theme. But of course, there was poor communication of this feature to theme and module developers, and insufficient enforcement from core code. 

The module (and theme) developers weren't expected to use fully qualified image type names in the code. But they did.

They should have use this new feature like this:

$link->getImageUrl($image, $product, ImageType::getFormattedName('home'))

But instead they hardcoded the fully qualified image types like this:

$link->getImageUrl($image, $product, 'home_default')

These hardcoded names in the code resulted in many modules working correctly only in default theme. If some theme developer used this new naming scheme properly, these badly-written modules didn't work with it correctly... bummer. And so theme developers reacted accordingly.

They didn't wait for module developers to fix their modules. They rather dropped this use this new naming scheme altogether, and started using the same image types names as default theme. If you look into your warehouse theme config.xml file, you'll find image type 'home_default' as well. Even though it should be named 'home_warehouse'.

So, after a long and painful transition from 'home' to 'home_default' image types, prestashop ended up in the very same spot it begin. All the themes now used 'xxx_default' image types. And the possibility to use different themes in multistore was once again severely limited.

One of the goal of thirtybees is to fix bugs. And this is a huge bug, so it was fixed. This, and many related issues regarding fully-qualified image types were fixed, and the image type name scheme is now enforced by the core. Theme developers can't any more use 'cart_default' image type --> it will be 'warehouse_cart_default' now.

There are some hiccups, of course, but these will be ironed out. Most of the code paths go through the ImageType::getFormatedName method which will make sure the image type are transformed correctly.

Of course, there will be some modules that won't work with this new naming scheme. If the module developer manually concatenate strings to build image url,... well there's not much core can do to help here. Fortunately, there aren't many modules that do such blasphemy. 

[Occam]

Sounds good, really! Plausible and convincing. But after reading your explanation why it should be demanded to avoid such 'blasphemy' I took a quick look into the thirty bees marketplace, and afterwards into PrestaShop Addons. And you know what? There is currently this normative power of the factual that shouldn't be ignored.

[Traumflug]

@Occam, please use PS 1.6. Or better PS 1.5. There is all the broken code you desire so much.

 

[Traumflug]

4 hours ago, datakick said:

Of course, there will be some modules that won't work with this new naming scheme. If the module developer manually concatenate strings to build image url,... well there's not much core can do to help here.

I think the fallback can catch even these. It just needs a bit more fantasy about how module developers break code.

[Occam]

49 minutes ago, Traumflug said:

@Occam, please use PS 1.6. Or better PS 1.5. There is all the broken code you desire so much.

 

😊 Come on, don't get upset. Just stay objective and stop such polemics. I didn't attack you personally and I don't see any reason for it. I really have a lot of sympathy for this project. Otherwise I wouldn't get active here. But that doesn't mean I have to endorse all of your solutions.  

[Traumflug]

There is no polemics, just respect to your wishes. You explicitly want broken code and to get this, moving on to PS 1.6 is the best way to proceed.

[Occam]

6 hours ago, Traumflug said:

There is no polemics, just respect to your wishes. You explicitly want broken code and to get this, moving on to PS 1.6 is the best way to proceed.

We both know this is nonsense. But my priority has always been a fast working shop, easy to handle for users. Perfect clean code as a desideratum, yes. But not on top of the agenda. For a merchant a shop system with some known bugs that may easily be circumvented is a thousand times more useful than a new designed shop system with unexpected bugs lurking everywhere. We face this with PrestaShop 1.7, and unfortunately now with thirty bees 1.1.0. And there is a difference: Prestashop is a known player in ecommerce, thirty bees wants this to be.

However, that said,  I got the subtext of your posts and will withdraw from thirty bees, of course.  I really don't know if you're primarily interested in a functioning shop system as an alternative to Prestashop, or just in satisfying personal vanities. In any case, it seems to be a constant lonely individual fight, even if you are well skilled technically. I wish you good luck. 

[datakick]

33 minutes ago, Occam said:

I got the subtext of your posts and will withdraw from thirty bees

Please don't. I really think it's very important that users keep the developers accountable for their decisions, and remind them about the real-world impact and consequences. And you do the great job here. Granted, you will not receive any love from the developers for this, but it's very beneficial nonetheless. 

[zen]

egos are boring.

Edited September 17, 2019 by zen

[Mark]

Ive just undertaken a bleeding edge update which I believe incorporate's @Traumflug's changes.

 

Unfortunately now I seem to have no images at product.solutions.org.nz

When updating the thumbnails I get

 

Original image is corrupt (/home/solution/public_html/product/img/p/1/9/4/194.jpg) or bad permission on folder

 

[zen]

seems like something is broken ... the url for the pic seems not correct : "/product/" should not be there or it is your root directory on the server for this website.. I doubt this.

but the images path are good : https://product.solutions.org.nz/img/p/1/7/9/179.jpg

this image on the exemple you provide does not exist : 194, so the repport you have when regenerate thumbnails is logic.

But still now, your images settings are not correct.

[Mark]

Ok so I need to know what the settings should be

 

(/solutions is the account in which everything sits)

Edited September 18, 2019 by Mark

[zen]

Mark: "Ok so I need to know what the settings should be "

Zen: The settings are all yours.. it depends on the result you want in your front office.

 

Edited September 18, 2019 by zen

[Mark]

OK so right now I have no images, I have no idea how to change the settings so I have images. The settings I have are at the start of this thread and I believe that they are set by the theme and I dont want want to particularly play with those.

[zen]

How to help somebody who knows better way..i Wonder ?.....

Lucky that that your website is not in production for real

Edited September 18, 2019 by zen

[Mark]

Excuse me, I'm not sure what caused that response from you zen.
My website is in production live and has no images and customers cannot see the products they are trying to buy and making complaints.

I do not know how to fix that and haven't made any suggestions that I have ant better way.

I reached out for help on the settings and still have a broken site