wakabayashi

Ich glaube, es wäre ein bisschen riskant, das alles in einer Schleife ablaufen zu lassen. Das Feature ist neu...

😂 👌

Just to make sure: have you heard from "revws" module? It's developped from an active member here and it's much better than the default review module. There is a free and a paid version: https://store.getdatakick.com/en/revws-free

Diese Funktion wurde nicht von Markus implementiert. Die Funktion wurde - soviel ich weiss - mit Absicht nicht eingebaut...

Why can't you just import your database backup into the new database? But TBH, if you have no expierence at all with such actions, I would hire somebody.

I agree with @toplakd Invoices are attached correctly in our case too.

Thx a lot @toplakd and @datakick! I hope once this corona thing is a bit less severe, I can contribute again some stuff on github myself. So I really appreciate everyone, who drives this project forward 🤗

Ah I finally understand how you handle it. Yeah this makes actually sense. 😊 Bad that it's not working as expected 😅 In my use case the problemlays a bit deeper, as my orders often aren't paid when the order gets placed... And you can not add an order with payment amount=0

The payment value won't be updated in this case, does it?

And what would you do, if you remove some products?

When you change an order, you will probably also have this red warning like: The amount of payment doesn't fit the order amount.

Hard to say. I can't remember any such issue. Have you tried to delete all cookies?

I don't think this fix will change anything on payment amount...

IMO you need to integreate APIs/Hooks for payment modules. If you edit an order, you can not just assume, that the paid value has changed. In practice there are multiple cases. Sometimes there happens a refund, sometimes the order hasn't been paid at all at this point.

I am quite sure that, it is not a bug, but bad design. The ps was designed, that every order is paid during checkout. As well they are kind of expecting, that an order doesn't get changed. I know, that my answer isn't really helpful. I am voting for years, for a better way of handling this. But it's very hard to achieve. The concequences are hard to forseen. For the payment case, I believe that a payment module should call a hook, so the amount get's corrected...

You have very nice products. Love them! I just quickly checked the categories and products a bit. I believe, customized text should be improved. I would add that above addToCart Button.

@justinrosander welcome to our forum 🙂 Try to deactivate Demo-Modus on the top right.

I am not from the official team, but my answer still would be: YES! We all know: if tb would now just give a shit on 1.6 support. It would die immediately. In my opionion it's much more likely that 1.6 won't work anymore, since smarty, php, or any browser forces for updates. When such a technical change will hapen, nobody can tell. But it will happen. And with some modifications the old ps modules can probably be even used after this kind of revolution. So really don't worry too much. You have anyway no alternative 😆

@Theo You are argumenting as ps 1.6 would be an alive project. It will die sooner or later. Devs won't upgrade their 1.6 modules at some point (I believe some devs already left or focus only on 1.7). But as an example: in our country there soon will be a new way of invoicing. It will happen with QR Code. If I am lucky, there will still be a ps dev that says: "oh ok, 1.6 will still bring enough revenue. I will publish a new module." but what, if not? We are living in digital age. Time is moving fast. What if browser come up with new rules? What if a new php version isn't compatible with 1.6 modules? TB is now great, but if there is no plan to move forward, the project will die for sure. In Short: The 1.6 modules support gives tb a basement right now, but it won't save tb for the future. AGAIN: Nobody said, that this basement should be errupted now for no reason.

@Theo You are too nervous. Nobody stated that 1.6 compability will be given up soon. And as you stated yourself, the modules are working right now. The point @toplakd wanted to make (and I completly agree on it). This project has to move forward. This is done with so much attention, that almost every 1.6 ps module is working out of the box. But seriously this project is now 3 years old. The most of the 1.6 ps merchant's now won't switch over. They have had enough time. How long do you wanna wait for them? Btw: I use the advanced search 4 module too. It's feature rich, but actually crap. It's slows down your shop so much... Look at @toplakd shop. He has a very slim setup without many external modules. He doesn't even need the smarty cache to have a super fast website. When it comes to feature values. I propose since years, that multiple values should be supported from the core. External module don't help here much as the multiple values won't be used by other external modules then...

Beacause you don't have smarty cache enabled, probably.

@rubben1985 the folder I posted myself cache/smarty/cache

@datakick I have checked my issue again. I found out, that the hook, which is called in a tpl file is cached strangely. My structure is like this: blocknewproducts displays blocknewproducts_home.tpl blocknewproducts_home.tpl includes product-list-slider.tpl product-list-slider calls {hook h='productImageHover' id_product=$product.id_product rewrite=$product.link_rewrite name={$product.name}} blockspecials-home|20200303|1|3|1|1|1|19 is the path to cache file followed by some more folders. But the cache of the hook is just not multistore ready. Strangely it only happens for the first time the hook is called. For some reason there are also cached files (yellow folders) of the called hook. But the imagehover module doesn't make this cache itself... @rubben1985 how does your cached folder structure look like?

Probably because this versions are outdated.

Works normal here. Never used this tool before, is it worth it?