wakabayashi

Isnt there a file, that states this error? Probably you can edit this file and it will work again. Not the nicest fix idea, but maybe a quick win. Maybe afterwards you should redo the core updater under php 7.4. Please also tell, which modules aren't compatible. That may help other customers too...

I have started with some improvements... Returns: Refunds: Are they useful for anyone else?

@jnsgioia I have looked one hour into it. There is some issue, but it's not about the separator but about some character in your data. You use "¾". This seems to break in the new version. @datakick My knowledge is not too good about special characters. I can imagine, that the fix or at least the understanding of the problem is much easier for you.

Thanks a lot! Your example is great to underline my point. The fact, that you need "Shipped" and "Shipped - Unpaid" shows the problem I see in the current system. I have thought about this "solution" too, but it would ask for a lot of additional states in my case. I wonder about a few things: "Being prepared for shipping". How do you know, if its paid? Wouldn't you need there two states as well? "Refunded". Does this mean, that this products are always returned and sellable again? Are you using AdvancedStockManagement? Cause if yes, there happens an auto restock imo. You are from germany, right? Looks like a DACH setup, like mine. Sorry for the questions, but I really think this system could need some cleanups/improvements.

If you update to a php 8 version, this could likely become an issue, if the modules aren't updated anymore. But basically this has not much to do with TB. If you stay on older php version, I don't expect too much issues. The problem is only: end of month only php 8 has further support.

I wonder, how you handle your order states? Do you have some custom states like "Customer complaint" or anything like this? If yes, when do you activate "shipped" or "paid"? I have looked into the code and IMO it's not possible to set this things correctly up. Here are my order states. Would be interesting to see, how other merchants are using this feature:

I don't know exactly, what you are talking about. Do you mean 1.4 vs 1.3? Can you provide the csv file? Do you get any specific error?

I am back to this topic. Was quite fun to read the old posts. I have to admit, that my understanding of returns and refunds was a bit naive. My understanding and coding skills are much better now. Who is still using RMA or (partial) refunds? I want to improve this features for my customers. If there is interest in the community I could supply some stuff as PR. Any ideas/wishes? What I plan at least (line-trough) => implemented): Possibility to create rma-slips without an action from an employee. Explanation: In some country the customer has anyway the right, to send products back. Improving the order-slip & return lists. Linking id_order to the actual order. Adding Customer Name to the lists. Allowing returns for non-paid orders. Either adding a configuration switch or just allow it default. There is actually not much relation between payment and a product return. Possibility to make the textarea optional on rma.

Either a cache issue or you didn't delete/change it in the right module. Which module is that? Which theme are you using?

A lot of exciting ideas. But I am looking most for this support ticketing system. Is this a standalone solution or does it use any external service?

And again you don't give the import file that makes the shit... My guess is like datakick: the shit was already long there, you just didn't know it.

Instead of supplying a real bug report (with the file you import, that makes the shit), you prefer to switch the platform. Sorry to say it, but you have no idea what it means.

If this is the full list, there is not much to worry about it. I don't know why, but for me there were also quite a lot vendor files...

Are these all files from the /vendor/ folder?

And some people thought this project is dead 🤔 😅 Good work! Pull request coming from me for sure 🤗

Ja, da haste Recht. Im Prinzip gibt es schon sehr ähnliches. Generell ist es nicht so schwer, so etwas zu programmieren. Aber jeder Shopbetreiber will es halt ein bisschen anders...

Ja, das kann ich gut verstehen. Bezüglich PayPal Modul habe ich keine Ahnung. Wir bieten kein PayPal mehr an, da die in der Schweiz absurd hohe/freche Preise hatten. Wir nutzen einen Dienstleister (Payrexx), mit welchem wir den Rest machen können. Für dich wäre wohl das Pendant Stripe. Für Stripe gibt es ja auch ein offizielles TB Modul. Wie immer gilt: testen, testen, testen 😉

Also mit dem HTML Block wird es zurzeit kaum gehen. Dazu bräuchte man ein wirklich gutes Shortcode Module. Generell etwas, das ich begrüssen würde. Andere Module wird es bestimmt geben, die das können. Programmiertechnisch ist das relativ einfach. Die Herausforderung ist eher mit allen Themes kompatibel zu sein.

Wir verschicken auch auf Rechnung. Handeln das aber selber ab. Nutzen halt Bonitätsprüfungen und bei heiklen Fällen wird Vorauszahlung verlangt. Das ist aber nicht in allen Branchen/Ländern durchführbar. Tendenziell erhält man wohl in einem allgemeinen deutschsprachigen Forum (z.B. sellerforum) bessere Antworten auf dieses Thema.

Is this module php 8 ready? At the moment I got some php warnings like: Return type of Revws\ReviewList::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /modules/revws/classes/review-list.php on line 44PHP message: PHP Deprecated: Return type of Revws\FrontApp::jsonSerialize() should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /modules/revws/classes/front-app.php on line 186" while reading response header from upstream

Why is this Module needed for you? I can not even find it on github. I guess it's no more part of tb, cause MichaelD left long ago 😞

Ok, nice to see that opinions are aligned. Right now, I don't know enough about the whole mechanism and it seems to be quite a huge rewrite. But I can imagine, that I will submit something in the future. With webp and some cleanups on image formats I could save more than 50% of the filesize. 😳 But I still need to figure out, what concequences it has to the BO.

I am working on my new theme and webP support is a big deal of it. Since we have now over 30k products data size is kind of an issue. Right now, when you enable webp. The original image is saved as jpg. I did change this behaviour to webp. So when I upload I only have webp files. But this leads to issues in BO -> jpg is hardcoded there. Why does actually the theme need to support webp? Is it not kind of the server, that needs to support it? Cause my idea was now: give the merchant a simple select, which formats he wants to use and then this is used for all uploaded images in FO and BO. What do you think?

Yeah, I feel ya. Keep us updated, if you make progress! While I don't plan anything like this, it's still very interesting to follow!

Oh ok. That sounds interesting. A main issue I see in such projects: hold up data quality high. How to make sure, that you are "merging" excact same products, but not slightly different ones. I have to do this for 20 suppliers or so. And you can't imagine, how big their data mess is...