wakabayashi

Yeah I understand your point. I am personally just not a fan of mixed currencies in the same table, that are not marked by name or so. But ok it's not so an important thing. More important is to fix the bug, which is really there...

This makes sense imo. Also PS has this approach, but lacked of consistency. @datakick If I see it correctly, the columns "purchase_supplier_price" and "original_wholesale_price" are stored in shops default currency. The other numbers in orders currency. My proposal would be, that we use for all numbers order currency. As we have the conversion rate, we can simply calculate them back. What do you think? This is actually what most devs would expect. They surely don't always recheck which column is in which currency. Ok I admit, that these columns probably weren't used a lot ^^ If you agre, I would make a PR.

To me it's also questionable in which currency all the numbers of an order (ps_orders and ps_order_detail table) are (or should be) saved. @datakick do you know that? Are they ALL saved in the currency that the customer used? Are they ALL saved in the default currency? Or is there a mixture? Only this understanding would allow a serious usage of these numbers. After testing a bit, I think most values are in currency, which the customer chosed. But not all. That's why it's no surprise that devs use it wrongly.

Nobody? Looking deeper into all these numbers, I have to say: PS did a solid job in saving the numbers. But a horrible job calaculation/accounting. There are a lot of places, where the system is just doing dubious things. Best example is statsordersprofit... If you have a simple setup without multiple currencies, it might be solid. If your shop has multiple currencies (suppliers) and a lot of price changes (suppliers) it's useless. But I can't fix this without other merchants, supplying me with their data.

I am not totally sure. Maybe it works to create an override.js file and add the whole function. Then make sure that override.js is loaded after tools.js. It might work, but I really haven't used this before. Let me know 🤗

Looking a bit into earnings I checked out order_detail table. In my case, it seems that the column purchase_supplier_price is always calculated wrongly. This column should show the price, you need to pay if you reorder the product at the supplier. The currency is your default currency. That's where my issue comes from instead of $price/$currencyRate it does $price*currencyRate... Can you please check, if it's the same in yours? (only relevant when you set up supplier price in a different currency) It's also helpful, if you show me a screenshot of your currency rates:

@Beeta This things are quite tricky. Are you an experienced dev? I don't know exactly, what you are trying to achieve. But if it's only about "involic prestabay". It could be easier to modify this module a very little. You could set up a little cronjob and search for new/modified products by date_add or date_upd. Then you trigger the module "involvic prestabay" hook function (but not the hook itself).

I don't know him personally and haven't used his version. But he is an experienced PS Dev and seems to invest a lot of time. So we would surely benefit, if he joins our community (and I guess he would benefit too).

PR are out: https://github.com/thirtybees/thirtybees/pull/1582 https://github.com/thirtybees/niara/pull/65 At the moment only the password confirmation handling was changed in Niara. The birthday is still handled the old way. The deletion apply was not implemented yet, as I am not sure, if it's really wanted.

No other opinions on this topic?

Oh yeah this makes sense 🙂

I would do the same ^^ The module above is crap?

It would be easy to add another configuration switch, but I dont like this idea as the BO is already now bloated with configurations. Somehow we need a proper form handler that allows required/optional setting for each field and allows to add custom fields. Obviously that's a huge and complex task, that won't come soon. I would recommend you, to just use CSS and hide the birthday field 🙂 Thought that too. But also thought, if somebody goes on your computer, while you are logged in... That's why I want to secure password change, email change and account deletion. The rest isnt too critical imo. Saving payment infos on tb is crazy imo, I would never do it. Yeah I thought so, that this feature could even be a must in some countries. In general I don't think that all GDPR settings should be in core. Actually there is a module, but maybe it was never finished (?) https://github.com/thirtybees/tbgdpr. I don't need GDPR and don't know the rules, that's why I won't work on this deeply. How are you handling it now?

Hello This is community-theme right? I was just looking into the code. Doesn't look buggy to me, as the other default theme (Niara) uses the same code. Are you using multiple languages?

@datakick Thanks a lot! I did a full reset of the module and INSERTED it afterwards 🙂 This time I was even smart enough to change the PREFIX 🤣 Will this entry be added automatically on upcoming version? I assume that this is a general problem with smarty, as all kind of module folders throw this warnings.

Right now I am cleaning up the identity controller (when customer changes his profile in frontOffice) a little bit. IMO it was done a bit untidy. For my store I will also change the behaviour a little. I wondered, if it's wanted in the core to: Using date field type for birthday instead of three selects (dd-mm-yyyy). Now customer are forced to type their password each time, they change their profile. I want to make this restriction only, if he changes his password or eail. Why? At registration we have optional fields like birthday. Later I hope a customer would complete their profile, but obviously don't want to force them to type their password. As an user I hate such tasks. My brain says: ok sorry, then no birthday. I will implement an account deletion apply function. Important: it's an apply. A merchant will be notified somehow about it and then he can handle it. Of course this will also require the user to type his current password. This could also be implemented by a module, but IMO this functionality is kind of a core thing (at least much more than other things being on core). Opinions?

Noted! I also thought, that in my process I would have to go on both BO pages, which is not so nice. But I have to think about the best implementation to fix this. Other feedbacks are still welcome! 🙂

Houston we (or I?) do have a problem: vendor/smarty/smarty/libs/sysplugins/smarty_internal_runtime_cacheresourcefile.php:76 is bloating my DB 😳

There is no way with to achieve this with the core. Maybe you find a module on prestashop store, that is compatible with PS 1.6, which should work on tb too. Otherwise you would need to hire a DEV that implements this on custom basis. In general it's not a super hard task to implement.

Hallo Bin nicht aus Deutschland, aber da geht es doch um die Umsatzsteuer!? Mir ist nicht klar, was da geändert werden respektive das Modul können müsste.

Sounds even better 😎 But this is only locally right? I mean I can't give a hint to merchant, that he uses an outdated version, right?

@datakick What do you think about a "clearAllLogs" button? When you have fixed a lot/done a shop upgrade, you might want to start with a clean log again.

Please all install this module and report the warnings you got. It will help, to reduce all kind of bugs. For a dev its very helpful to see, if multiple merchants report the same stuff. While it sucks to see these warnings, we also should see new PHP versions as chance to make the system more clean. 🤓

I am still working days (and nights) to push my theme forward. The progress is quite amazing. IMO there is no doubt, that we should go for FrontEnd component system. This in combination with fast ajax requests can lead to a damn good result. And the good: the core needs almost no adjustments. I have only a few very simple overrides... Here is a sneak preview of a fast customer journey: genzo_theme-preview.webm I work often with modals. This gives a much better user experience (especially on mobile devices). But in general it's all about the usage of predefined components: https://www.genzo.ch/tb-framework Here you can see the module "tb_framework". As you click through the Elements/Components you will see a lot of elements, that you saw in the video. Any theme/module can use these components as well. I won't publish my theme/components as they should be unique for my store. But I could open source the technique behind it. Especially the "tb_framework" module. Steps to get a similair result like mine: Somebody builds default components for "tb_framework". Best would be without any framework. Actually I did mine only with TailwindCSS, which means, that it's also possible without any at all. Only exception might be slider functionality. (Ofc I could support this task with my components). A new theme from scratch is created (or maybe existing cisero), that implements the components from "tb_framework". For the theme imo any framework can be used. Core modules are adjusted to use components from "tb_framework" module. (This is not too hard and actually quite fun) My opinion: As this is damn much work, I don't think we will find one guy, that makes this in his free time. A crowdfunding might be needed.

Oh, it's only a couple of weeks ago, when I switched to PHP 8.1 from PHP 7.3 ^^ Sounds like a lot of new work. I will test these things in early 2023...