wakabayashi

I plan to finish this project soon. I have done so much now and need to stop, otherwise it will never get to an end. Here are some highlights: Consistent webp support in core (upload product images in webp is now possible) Modules can simply use core image system instead of implementing themself (beesblog was used as a test and simply supports now webp too). Just use AdminController and objectModels and image implementation takes minutes instead of days… Getting an image link was never so easy: all entity types are working with Link::getGenericImageLink(). This function also returns the source image, if you let $imageType empty. All image entities support now usage of $link_rewrite New we don't try to guess if 'home', 'home_default' and 'Niara_default' are all the same image type. We add all image type names to the db. First this may shock, how many different image types are used. But we introduce an alias system, that let you merge them. So a merchant has full control. Category image and category image thumbnail are now handled separately, so no more bugs on this. This is true for all other object model classes. They can add as many image inputs as they want. Image quality can possibly raise. I noticed some dubious places, were source file were possibly reduced in quality. So that meant, that image quality was actually lower than expected. I personally plan to use webp and 95 quality. I guess that raises quality and could even reduce size compared to old jpg system 😉 Employee image is now showed instead of icon-user. Default images were fixed (this was a complete mess). Now you can simply upload it under localization -> language and you are fine. Generation of retina images was improved a bit (no more blurry image generation). But I am still not totally convinced about this feature. The implementation doesn't check anywhere, if a retina display requesting an image or just a normal display. In general a huge amount of hardcoded stuff was removed and replaced by clean methods/constants. I would expect, that we can add new image extensions like "AVIF" quite quickly now. But I haven't tested this yet. Unfortunately plesk doesn't support AVIF yet and I don't want to install this manually on my server. So who is excited and ready to help testing this? To make clear, why this isn't a simple PR:

@SLiCK_303 Thanks a lot for your message. Yeah I will go back to this, but I am not totally sure how and when. Somehow the module is overloaded with features, I guess. Your help is very much welcomed. That was always very helpful for me! @datakick pointed out to me, that there as some php warnings. I wanted to fix them long time ago, but forgot again to finish. Just way too much work right now. Btw the other post is SPAM. You should delete the quotation, as there is a link in it...

Yes, it's no core functionality. I agree. But as a module it's very interesting IMO. On all social media plattforms it's becoming "normal" that you tag products on posts/images/videos. Maybe I can do that one day, but won't promise anything as I have already a lot of "projects" open 😉 In general I am making good progress on the image rewrite. I am now testing things with Beesblogmodule. With my rewrite almost all custom image stuff can be dropped there. Instead you just define this in BeesBlogPost::$definition: 'images' => [ 'beesblogposts' => [ 'inputName' => 'post_image', 'path' => _PS_IMG_DIR_.'beesblog/posts/', 'imageTypes' => [ ['name' => 'beesblog_post', 'width' => 800, 'height' => 500] ] ] ] It's going to be a lot of fun (almost no work) as a dev to use images 😎 Merchants will have consistent webp support 😏

How do you like me now? 🤣 Ok, there are still a lot of issues left in scenes. But the video shows that this hidden feature is not completly death 🤭 scenes.webm

Did anyone ever use scenes sucessfully? I mean years back... This seems to be horribly broken since years. But actually I would like this feature 😕 Anyone (@e-com) interested in bringing this back? Help needed... 🤕 I can not even find any saving process of the table tb_scene_products!? Edit: I just made some progess on this 🤓

That's right. This is one of the things, I was working on a few weeks ago. Unfortunately I got interrupted by other jobs and private stuff. But I will go back on this very soon 😏

With that unclear information, you will never get a reasonable answer... Please provide examples, details or links 😉 For jolisearch you would have to contact the module dev.

I guess, you have tested some stuff and have an old file on the server. Is this possible? If yes. I could imagine, that you have something like echo $variable or print_r($variable)

@e-com I hope, you are making progress on this 😊 I guess you have access to GPT-4, right? Is it much better in practice than GPT-3 or is it overhyped right now?

Ok finally I am getting back to coding / tb-work 🥵 Actually I agree with all your examples, but isn't my PR at least giving a bit more options to get accurate numbers? Nothing is worse than before, but instead you can at least create a simple system: 0.5% + €0.25 Before this was only possible for payments. Now it's also possible for shipping. In general we can argue till death, how much detailed settings we want to have in configs. Accounting can get complex, as I will demonstrate later in this post. IMO we should not try to become an acocunting software, but give merchants an approximation of their profits. In my example I calculate for all orders a profit and display it on the order detail page. Let me show you a (fictive) example: We use this now since 2-3 months. It's sick what we learned about our gains. Never thought that before. Not sure if there is any interest to include this in core. It could also be a functionality of a module. In ASM we have some kind of tracking. But you are right: it's hard to calculate a precise order profit, especially when prices are changing. When I was studying econmics it was also kind of a "hot" topic. Imagine such an process (it happens in my store): You buy product-x for 30€ from your supplier. You set the selling price to 45€. It's inflation and the supplier raises his wholesale price to 50€. - You sell your item for 45€ to customer 1. You reorder one item and set the selling price to 70€. You sell the item for 70€ to customer 2. What is your gain of the first order with customer 1? I don't know, what practice (and tax law) say. But the answer can be tricky imo. A lot of people would say, you made a gain of 15€. Ok then let's calculate the second order. This gain is: 70€-50€ = 20€. So total gain: 15€ + 20€ = 35€. I throw in, that you actually lost 5€ by the first order. Don't believe it? Ok let's imagine the same story like this: Same. Same. You react immediately and raise the price to 70€. Customer 1 doesn't buy the product now (it's too expensive in his opinion). You don't reorder. Same. What was the gain for the first order? Well its 0 as customer 1 didn't buy anything. What is your gain with customer 2: 70€ - 30€ = 40 €. Total gain: 0€ + 40€ = 40€. Oops 🙈 As I argued above: we lost 5€ with the first order 😅 Ok I admit: my story is also not always true. Third story goes like this: Same. Same. - Same. Now you say: fuck you supplier. I don't reorder with this wholesale price (as maybe nobody will pay 70€). What is your gain by first order? Obviously 15€. So your gain of order 1 depends basically on your decision, if you will reorder or not. Anybody is welcomed to bring up arguments against my point - it's in my opinion a very interesting topic. @datakick I saw now your comment on github. I have no problem to use such a system. I agree, that the idea of saving parameters with a time frame is a bit more clean and flexible. I believe it's main advantage is in backward compatibility. You can always change this values to improve your dashboard values. While I saw this as a disadvantage, it's an advantage (but only combined with the time frame ofc)! But there is currently no table, that can handle it, right? Let's keep the technical discussion on github. 😉

I don't use Mollie anymore, so I can't say 🙃

I don't know. I am also not sure, what this would help 🙈 As long as I am happy with turnstile/cloudflare I will support this module.

Do you have the folger \img\tmp?

Same here. No Spam since using this module 😎

Sorry for my late reply. Unfortunately I am very busy right now with internal stuff. I will reply to this in 1-2 weeks. Please keep it open till my answer 🙂

Yeah there is a lot of sceptism about AI. Probably rightly so. But what has it to do, if a merchant uses AI as a tool? When talking about text generation: either the text is good or not...

I don't think this will be that binary (yes/no). They also stated somewhere: as long as your texts are good, they have no problems with it. But if "good" means above average, you either have to use AI better than competitors or you should make manual corrections. I plan the latter. Always read the text from AI and rewrite it a little, so it gets even better 😏 What I also notice: I generate 5 texts from AI for the same product. In each text a like some parts and some I don't... Also want to say: these things can change so quickly. Each advise today can be wrong tomorrow. Maybe it takes only 2-3 an AI writes better than 95% of copywriters 😳

Thanks a lot for your explanation. I can feel you and I am very interested in your experiences in this field - keep us updated 🤗 We did this in the past. Sometimes you find a good copywriter to a reasonable price. But soon their prices raises as they get too many work offers. But you have to spend hours/days to find such a guy on a plattform like Fiverr. Others write worse than a 14 children. But ok now the game is anyway played differently 😅 This is the only thing I don't understand in your post. Where does the 5k tokens come from? I don't think, you want a description of 4000 words or so!? Does it just take multiple tries, to get a result back, that you like? Edit: Btw... Are you a merchant yourself? I always thought you would be a dev 🙈

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 😃