the.rampage.rado

Be extra careful when removing image formats here as every theme creates what is needed during install. Regarding speeding up image generation - if you're generating your images during manual product creation the only way is to increase the speed of your server (buy better VPS/server). If you are annoyed that image creation times out/is slow during product import - simply don't create the thumbnails during the import but later in a dedicated tab while you do other work. The image section got nice rewrite by @wakabayashi but in the end it has to regenerate the files. Also - don't use jpg, it's 2026. Switch at least to webp, avif is even better if your server/php version supports it. BEFORE you switch the image format and regenerate all images - make sure that your theme can work with the new formats. Take inspiration from Niara and see how you can pass the file extension dynamically. Backup, make the change, then regenerate all thumbnails (Images -> Reset status -> Regenerate all). This will not speed up your generation time but will speed your FO performance and speed score if you approach the quality conservatively.

I basically told Codex to use this and that local repo of Warehouse, upgrade FA to 7.2, use the shims and not make any changes to the actual usage of the font in the theme so I can check if the shim layer works. After I saw that the new icons are loading with the old code calling them (FA3 and 4) I asked it to inspect all the theme files and module and swap the code for the new formatting. The old font files light stay for the initial testing and you will have to put the new FO files where they are expected to be (I beleive in 7.2 they must be in /webfonts folder under theme's /css folder). After that the bot will merge the big global.css file with all the glyph mappings in the FA source css (necessary if you don't want to have an additional call to another css), this adds around 11k lines of css. The only issue I think I had was in FO -> My profile section one of the icons was not rendering properly so I had to change it to similar one in the new package. In total, around 2 hours with all the testing

Warehouse is not made by Sunnytoo. Regarding the php8 support - I managed to make it run on 8.3 with ChatGPT and Codex lately. Minor fixes but... Even managed to update it's FontAwesome to 7.2 with shim for modules and native usage.

Nice. It's always good to run your store to the most current version as there are plenty of bugs fixed and many security flaws too.

So you fixed the error by updating the store to the latest version?

OK, that's right but this issue could 99% be solved by an LLM in like less than 5 minutes. I don't see why there are small merchants that don't pay for some of them to help with such tiny tasks.

Open the error, copy it and give it to the model. Give the model context to work with (I use Codex locally, create a local repository and work in it, it makes all the changes, you have to FTP the files to your test server and check if the fixes work). If you work with ChatGPT or other model where you can't give direct access to a repo you can paste also the php code from the file that is at fault. Usua,lly those fixes are very easy (bringing new php compatibility to the code).

I'm about to release my vibe-coded one, but it's perfect that we have an official one from you guys! Can't wait for the link, so I can test it.

Codex or ChatGPT will fix this in one prompt.

This is the idea of this community.

Which page is that? Homepage? Can you open your BO?

This issue is caused by bots that try to delete already empty cart they create I think.

Sorry, my initial answer was not 100% correct. It is not removed in 1.6 as it is, of course, part of the themes. In Niara it was removed with https://github.com/thirtybees/niara/commit/3ab40e7ae52e0c495a2b67f09131996fb6ed65ea (absolutely the same in the Community theme). If your theme still use it you can approach the issue in a different way:

Delete the line. There is no need for this anymore. Or update to 1.6 stable. Where this is removed.

I took few days off.... 😉

Do you have proposal how to fix this 'bug'? I believe it's architecture change that breaks compatibility with many things.

Yes, now drop the spam 🙂

I hope I have something to show in the recent days.

Yes, by using it you don't have to change your csv format. But of course it skips the whole column and if you need some data from there it becomes a problem.

I'm giving an example with Excel: In this case id 2 and 3 will override the price with 0 and not simply skip the import and leave whatever price there was. Empty cell = ;; You are missing one more separator; you are starting with ID, which is empty in the example and you should have it as ;1;test;;; If your example with only 1 row you can set up your import template to ignore those columns: But of course, this does not work in my example above as you won't import any price for 1, 4 and 5.

Yes, I created a feature proposal. Will update you if I can work out something with Codex. We have to be careful which fields we allow this for. If the whole column is empty, you can simply not import it. You can keep it in the csv that generates it, but you can skip it in the import template. But of course, if the column is partially populated, this does not work, as the fields that have nothing between the separators will also be overwritten.

I assume you have a csv column that is partially populated and you want to keep the data in your db for the rows you have no value in the csv? If so currently, no - you can't do this in the importer. If of course your whole column is empty you can simply not import it but I doubt this is your problem. Created a new issue to track this: https://github.com/thirtybees/thirtybees/issues/2120

Yes, the idea is generally targeted to multistore installations so we can achieve better coherence with FO branding and not use style-neutral templates. But it can also be useful for merchants using various modules from separate developers to track, detect, and unify them in one style. For example, currently my revws emails are quite different from my core ones. Yes, you can do that when using one shop by changing the module email template, but you have to keep a map of the modules that have emails and track this on every module update. Using the module, you will create a module email template override and use it instead of the standard one. Can you give some screenshots of the empty templates you use? The inspiration for this module came from one long forgotten one my theme developer supplied, but it is no longer packed with the theme, I even failed to find it in old backups of the template so no logic is shared at all.

Hi forum, I'm 'working' on a small module that swaps the default email templates with new custom ones that can be configured in BO - for v1 - only colors and email logo, more additions later. It also detects missing email templates during sending, so the merchant can later add them. The idea is to have granular per-shop control over the styling and the theme used. We would have the opportunity to have multiple themes and use them simultaneously for different shops. What current templates do you use? Are you stuck (as I am) to the default ones, or have you created/adapted the code to follow your FO design more closely? Can you add screenshots?

@vir - Because I have some ideas, can you help me with your workflow? How do you plan to proceed with those requests? What you envision is your optimal workflow in BO? Where are you located and what are your local requirements for delivery refunds in such cases?