wakabayashi

Well you are on 1.3 and I am kind of 1.5 tb version. That could explain some differences. I now tested it for my version with the new image system. As I told you, I replaced 'medium' with 'category_medium' (3 places). Afterwards I uploaded a thumbnail. I did nothing else. In my case it cleanly generated the file 6-category_medium.webp (yours is probably jpg) in 67x67px (as I set it up). So it all worked as expected for me. Anyway: If my proposal is not working for you. I think you have to wait for my rewrite being merged. Afterwards you should upgrade to the bleeding edge and you will be fine. I expect my rewrite being finished in 1-2 weeks. But the merge will take additional time as at the moment 56 files are involved. So in a good case I would say in a month we have this integrated. In the worst case: Datakick will refuse my PR 😅

Hmm. I can not test this right now, as I have seriously changed files on my testserver. Either you are "wrong" and it's more a caching issue or so. Or there is another bug. Imo there should be a file in "c" folder and with name "category_medium". But yeah probably it doesn't work in FO and maybe that's the reason, why you think saving doesn't work. Which theme are you using? Search for category.tpl and replace there 'medium' with 'category_medium' too.

@Cassim I believe to quick fix for you would be to replace ImageType::getFormatedName('medium') with ImageType::getFormatedName('category_medium') in AdminCategoriesController.php. Obviously this works only for your setup and we can't do this in the core right now.

Looked into this, as I am rewriting the whole image usage in tb. The main issue here is ImageType::getFormatedName(). It's not been able to return 'category_medium'. We could improve this function by adding $imageTypes and $entityType stuff there. But it gets more complex, not sure if it helps in the long run. To have a very clean solution, we actually should get rid off all this ImageType::getFormatedName(). Instead we offer a select configuration somewhere. That's actually no difference, to how modules should integrate image usage, right @datakick? Somehow this doesn't seem to be a quick fix 😳

Good to see you could quickly solve the stressful issue 🙂 I am no expert at all on this field. But in plesk I can quite simply chose different php versions per site. Still I wanna add: Not even php 7 is supported anymore. If some creepy guys find a hole in an old php version like 5.6, you might be very vulnerable. It's always better, to update when you have time and no stress, as you can test a lot of stuff.

It has been a week now. No stupid spam emails since then. Will keep you updated 😏

Yeah there are some issues with it. I remember, that I have at least outcommented the following: if ($orderStatus->logable && (string) $cartTotalPaid !== (string) $amountPaid) { $idOrderState = Configuration::get('PS_OS_ERROR'); } in validateOrder() of PaymentModule.php But surely that is not a clean solution. In general this problem is also a bit related to a messy order status handling. (These kind of problems are also known by our loved brother: https://github.com/PrestaShop/PrestaShop/discussions/31038)

@datakick What is your opinion about this copy method: https://github.com/thirtybees/thirtybees/blob/main/install-dev/models/install.php#L567-L572 I am concerned as we just save a png like it would be a jpg. Browsers can probably handle that, but I think it's not very good. What would be the correct way to really change $imageExtension in TB? Obviously ImageManager::resize() could do this, but as no resize is involved, I dunno, if it's good to use or if we should make a new (simpler) function for it? If I understand correct, it would be possible With Image::create() and Image::write() afterwards.

Right. As you correctly noticed, we have to change isCorrectImageFileExt() a bit, so that 'webp' is accepted there 🙂 Thats why I introduced a function getAllowedImageExtensions(). At the moment is quite raw, but in general this function should return the image types that are allowed to upload. Plan is to replace all hardcoded stuff with this function. So that a extension is always (or never) supported.

Oh ok. Didn't know that this is an existing bug. I personally could live with the simple solution (bottom screenshot). But ok, it's not popular to remove any existing feature, so it's better to fix this cleanly.

@datakick What is something like this good for: https://github.com/thirtybees/thirtybees/blob/main/classes/Language.php#L629-L643? English language might not even be installed and in my installation there are no such files Why do we need this files in all folders (category, manufacturer and so on)? Wouldn't it make more sense, to just store them in folder language ('l')? I have seen multiple such similair usecases. 🙃 @e-com Thanks for your link. I will look into it, but right now I am a bit overhelmed with all other things related to this rewrite ^^ Could you shortly explain what/why is not working with webp? Cause we have a webp support. I know, that it's not possible to upload webp images in BO for products. But that is actually just because of hardcoded values in some controller. In general I believe, that there is no issue with generating webp images... Might be wrong of course 🥵 As you are very active and experienced dev, will you help to check my rewrite once I "finished" it? There will be bugs or at least stuff, I haven't taken into account. It's not possible for me to forseen/test every detail. 🙈

Damn my brain seems to be damaged 🤕 Yeah, that's (obviously) the best solution. The hardcoding is just working by "luck". A theme could not even have something like 'home', 'home_default', 'niara_home' or whatever. That's actually where my idea ImageTypeBySize() came from. But you are right: if module devs give a select option, actually there would be no problem at all.

Ok, I have never thought that way. But yeah it makes sense to me too (at least in theory). So if this is true, it bascially means, that a module dev should "never" width="" height="" in a tpl file, right? But imo opinion it needs to be clear, what kind of type a module dev needs to load (in every situation). I guess that is what you mean by "Nowhere in the templates we should see strings constants." Haha, actually as almost always, when we have a lot of code for a single functionality 😅 Ok, anyway I will try to continue my rewrite as good as possible. But this PR will be huge (lots of files invovled) and serious checks will be needed. I see more and more the need of this: https://github.com/thirtybees/thirtybees/pull/938. I believe, it's almost impossible, to have always a 100% clean image folder, that is also performant.

This sucker nerves me too 😂 If you are using cloudflare, you might want give "turnstile" a try. I have coded a thirtybees module for it: I am using this module only since today. So I still will need to see, if it reduces the spammers...

@ukclearance what is your expierence? I have now updated the module. I recommend you to use the new version. It allows a bit more settings: Note: custom submits is a VERY basic implementation. If turnstile turns out to be effective. I can improve this module in the future. From today I use it on my live shop too... I am bored of this shitty spam emails (even with google captcha) 🥵

@datakick I am bit surprised how many function we have about getting ImageTypes and Image Link. It seems to me, that this is often about guessing, how an image type could be named. Multiple times we even search for something like '_default'. Why is this needed? I had the idea to use ImageTypes in a different way. There are a few thoughts: A theme designer always knows the image_type name (he has no problem to generate a link) A core dev and module dev don't know the images types for sure. (they might have a problem) BUT: always when you want to get an image_type it's actually about sizing (correct me if this is wrong?). So why don't we create a function getImageTypeBySize($min_height, $min_width), that does return the best existing/matching image_type. Of course we could then even improve this by something getImageLinkBySize(). Couldn't we drop then all the "guessing" like: Link::getProductImageUri() Link::getProductDefaultImageUri() ImageType::resolveImageTypeNameWithoutCache() These things are actually not totally related to image extension, but it's quite complicated to cleanup files at some points. It's very hard to forseen, what happens if you replace a hardcoded '.jpg' with something like $imageExtension that could be everything.

@the.rampage.rado Btw can you tell me more about the Warehouse usage of jpg? How and where are this images be loaded? Is this in a tpl file and '.jpg' is hardcoded?

That's what the fallback mechanism is good for. Sure I will hold them too. The question is in which Extension we should hold them. At the moment it's forced to be always jpg. I don't like that. I guess it's best to hold the format, that was uploaded.

I plan to really simplify things (get rid of some code). Some questions arise in this context... The idea is, that you select one image format and that all generated files (thumbnails) are saved in this format. Should it be possible to hold original files in the original file format? Let's say you use webp, but upload a png. Should the original file always be converted in webp or should it be possible to hold it as png? The later makes things more complex and bit slower. Which formats should we allow to upload in BO? jpg, gif, png and webp? Which formats should be allowed for thumbnails. jpg and webp for sure, but png as well? Edit: Also I hope that we can get a more consistent wording. The word "type" is used for at least 3 different things. It can mean entityType (product), imageType (cart_default) or imageExtension (jpg). It makes hard, to read the code like this.

Project of consistent webp support (and image cleanup in general) started: https://github.com/eschiendorfer/thirtybees/tree/cleanWebpSupport Help by another dev is welcomed 😅

Ok I have submitted a PR https://github.com/thirtybees/thirtybees/pull/1623. This will allow the usage of fixed fees for carriers. It will also save the costs to the DB. Which means, that your old order profits don't change, if you change your costs config values 🙂

Da hast du völlig Recht. TB ist in vielen Dingen funktionsstark, aber das geht auf Kosten der Einfachheit. Da könnte man viel herausholen.

What is the advantage of it? You can also just install a new theme 🙂

Oh sorry. I was not aware of such a functionality in core 😵

You give no information at all how this technically worked... Won't be possible to give any sensible answer. Is it a module? Is it handled on php, javascript or smarty? Core Updater can delete additional files. Even files, that were added manually by yourself but were placed in a core folder. Maybe it's related to a missing or old file. But ok that's just wild guessing from my side.