wakabayashi

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...

Man it's not my day. 🤕 Sorry! Yeah it's there with the right prefix - obviously. Looks clean, right?

Maybe other merchants can check, if they have it. 🤔

This table does not exist for me 🙃 #1146 - Tabelle 'tb_scheduled_task' existiert nicht And core updater doesn't show anything wrong under "database".

Yes there is no doubt about this. It was already there, when we switched to PS. And this feels like last life ^^ I guess, that @musicmaster would also prefer the flag beeing on "shipped". But yeah I see your point.

@datakick right. It depends on countries and also, if the order is already paid. As I said: we learnt to live with it. It surely nothing that is worth a big rewrite right now. It's better to have a clean return/refund process as well. Then you shouldn't be in need to edit any invoices.

As I said imo it would be better to have it blocked, when the order is shipped. When you generated the shipping label, the products are still in your hands. In this time a lot can happen (customer calls, sends email and so on). It's a typical thing, that a dev doesn't expect, but in practice it happens a lot.

It's not shipped, but when the delivery-slip was generated. I personally don't like this much. Shipped would be more logical imo. But we learnt to live with it ^^