wakabayashi

Thx! Unfortunately the problem turns out to be serious. The database is corrupted. The reason why this happened is unclear. Our downtime is now more than a day. But now we decided to setup a new server. At least afterwards we will have a really powerful one ☺️

Is there any guy with experience in server administration? All my sites are down, due to a MariaDB issue. I don't know, how to fix it myself and need (paid) help from an experienced server admin. Edit: ok I probably found a guy, that can fix it 🤞

I am testing an almost clean installation. I am trying to change sorting of filters in the blocklayered module. Does that work for you? When saving, nothing happens here. Talking about this stuff: I also have problems with indexing, but that could also be my fault!? 😳

Does it work with {$product.id_product_attribute}?

I just tried to install a clean tb 1.3.0. Got this one:

Are you sure you have bought/installed PS 1.6 version? I never saw such a function registerJavascript() in TB or PS 1.6. If you are sure, that you have a 1.6 module, then it would mean that the module is not recognizing TB as 1.6 and delivers 1.7 as default.

No one?

Oh ok. As it turned out, the bug was anyway already fixed by the tb team ☺️ Hopefully you can upgrade soon. Im my case it worked nicely.

Hm interesting. Cause somehow this felt a little different before I upgraded to bleeding edge. I normally got en exception when mixing both. Not sure, why this behaviour is a bit different now. But anyway it's not a big deal 😊

I believe this module breaks debug saving under AdminPerformance. Only when I deinstall the module completly, the saving works again.

Are you still using this? I have fixed this issue: https://github.com/thirtybees/thirtybees/pull/1406/files If it works out for you as well, we could implement into the core! 😎

Is there anyone willing to test it? This will be quite a huge rewrite, so we should test this carefully before adding to the core. I have now a raw version, that seems to work pretty well already. But I am sure there are issues left...

No. We create just the predefined values, when we need them. Obviously that would be more comfortable if it's possible inside the product edit.

That was my guess. It's more comfortable. But IMO we could also just allow to add "normal" features directly. But ok, maybe there is another reason why it was designed like that.

I have made a little video of my progress. I am not at all at the finish line, but I wanted to get a feedback. Would this be helpful for other merchants? IMO the selection of features will be much more comfortable with chosen plugin (as you can search). And the displayable helps to give additional information, but doesn't mess up with a filter. I guess this feature would even allow to use groups in a filter. Imagine you don't want your customers to filter all countries. You could then set values like "Asia", "Europe" and so on. And for in the displayable field you write the correct country 😉 Just one of many possible usecases. feature-handling.webm

I am rewritting the feature functionality a bit. As often, the code is a bit messy and unclear. In TB we have a distinction for predefined and custom feature_values. Which one do you use and why? I formyself use only the predefined. @datakick I wonder, if this distinction is even neeed and why it's only allowed to use one of the both?

{include file="../../helpers/form/form.tpl" fields=[['form' => ['input' => [['type' => 'text', 'name' => 'buddy', 'lang' => true]]]]]} I will try using something like this. Not super nice ofc, but IMO a lot better than duplicate code over and over again... Will keep you updated, if something like this is working or not.

Very hard to reproduce. Now I managed to see a product double as well. Strangely once there is an addition "tax included".

What is the best way to add multiple lang fields in BO? I am working on the admin-dev\themes\default\template\controllers\products\features.tpl file. I just want to add another lang field like the custom value field. Is this seriously that complex or is there another way? I would believe that I could use an "include" or so. 🙄

Good Point. I thought about that once too. Back then I thought, the prefix/suffix would allow the default usage of units. So that you could define it directly in a feature to always add "mm" for example. But now thinking again, I guess you are right. The "displayable" is more flexible and simpler. The unit thing could be implemented anyway (but for now it's not important). Damn why did I already start to code 😂 Luckily most things will stay similair. So in general you like the idea and you would merge it, if it's well tested?

Yeah it's done with checkboxes. IMO we can improve this with chosen components. For myself I will also implement a prefix/suffix feature. I will propose this for publicity too, but we will see, if there is any interest for it. Prefix and Suffix can help filter modules. An example. You use a feature "Awards" and have the feature_value "Oscar". Then you can use suffix for the year. So it will be displayed "Oscar (1997)". But the filter value is still just "Oscar". I hope the concept is more or less clear 🙂 It can also be helpful for Units 😏

Anybody else preferring chosen select compared to the default select? @datakick is there a reason, why it was not used? If you like it, I will make a PR.

Finally I updated yesterday to bleeding edge. Seems to work fine. 😎 👍 Will now looking into multiple features and improve it 🙂

Probably its a module delivered by your theme. Maybe the module is even called "sellingpoints"!? Otherwise I would search for "html" and "configurator/configuration" in modules list and check them all.

Is there any news on that? Is it really not compatible with v3? I get more SPAM recently over the contact form with v2.