wakabayashi

Meta Title and Meta descriptions aren't always taken into account, thats true. Our site seem to have quite a good reputation at google and they take our input often 1 to 1. But actually that's exactly the reason why I want to start with such fields: they aren't that important. Category descriptions are read by real customers. So you have to make sure, that there is no bullshit in the text 😅 For me it would be too risky to take the GPT text 1 to 1 atm. I don't have any tokens yet. Do you have? Do you have an approximate value, what a category description text costs?

Will you make this module public? Atm I don't want to use it 100% that way (maybe for meta descriptions yes). Not having to start from zero, to using ChatGPT would be super cool 😀

I have had this idea too. But for our store it's not a top priority, that's why I never have looked deeper into it. I can only say, that I would do it, like you: saving the translation "normally" in BO and refresh when the main language is updated. Deepl is probably the best translation. So your plan sounds good to me 😉

This was my first idea. I thought, that size 1500 would be a benefit, but yeah this is probably a detail. My main point was, to prevent the scaling down of the actual object on an image. Both solutions wil work for this purpose 🙂

I am not totally sure, if I understand you right. My idea was something like $widthOfRetinaImage = min(2*$imageType['width'], $widthOfSourceFile); $widthOfRetinaImage = max($imageType['width'], $widthOfRetinaImage); So that the width is always between $imageType['width'] and 2*$imageType['width'], but no blurry happens. Was that your idea too?

I agree on your post. Your ideas are good. Some of them might be up to modules, others are part of the core. You are also right with this 😅

Hm but the image is scaled down in browser afterwards. I agree that scaling up (blurry) and then scale them down afterwards is very stupid. But not doing it means, that the actual object of the image becomes smaller. IMO this is worse, than the other... Here you see what I mean: https://thirtybees.genzo.ch/de/coffee-and-tea/Coffee/coffee-beans. On not so large displays, it's just having a lot of white ^^ Well ok, at least I know now, that I haven't broke it 😃

Still working day and night on this. Always find new stuff, that looks messy and can be simplified. Atm I have created a system, that even Product Images can be generated by Link::getGenericImageLink(). Image urls look like: /products/17-Niara_large/tea-cans2x.webp /categories/4-Niara_category/Coffee2x.webp /categories/thumb/4-Niara_medium/Coffee2x.webp Tests will show, if this is a bad idea or if its great to reduce code complexity. I believe, that way we will gain some new possibilities: We can quite easily give the merchants rewrite options for image urls In the long run we can (probably) add new image entites. This means that a module could use the core to generate thumbnails as well. But now something happened to me, which I need some feedback. Are retina images currently working? I don't use this setting on my live store, but played with it right now. Please check out the following to links: https://thirtybees.genzo.ch/products/19-Niara_thickbox/tea-cans.webp https://thirtybees.genzo.ch/products/19-Niara_thickbox/tea-cans2x.webp It basically adds just white space around the image (probably due to a not big enough source image). Does the current system work like this as well? Looks wrong to me, but I am not totally sure.

While trying to continue the rewrite and adding configuration selects, I noticed, that we have a general problem in image proccessing. Especially in this category controller. Cause normally when you upload an imageFile, you expect, that all imageTypes are generated for this imageFile. All entities do it like that. Only AdminCategoryController does missuse this concept: Here an imageFile upload is linked (hardcoded) to a specific imageType. I don't like this at all. And it doesn't make super much sense, that we have this on categories but not on manufacturers and suppliers (both missing link_rewrite btw). I will try to rewrite this, so that we generate all imageTypes for 'image' and 'thumb' in AdminCategoryController. If it works, it would also be no big deal to add a second image upload for other product listing pages as manufacturer or suppplier. My ultimate goal is actually to have a consistent proccess over all entityTypes. In a perfect world we would probably even have ps_image for all entityTypes (but yeah that's not gonna happen soon).

Btw try to upload both in jpg extension. Maybe there is an issue with png. Just to show, that I am not talking shit:

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) 🥵