datakick

@x97wehner what tb version are you using? Is it bleeding edge? Please confirm

More and more users blocks google analytics nowadays. With self-hosted tracking tool the situation is much better as it's hard(er) for blockers to detect and block it. So, I'd say that self-hosted Matomo will give you more precise data. Still not 100% accurate, but better than GA. But it's not really that important. We are not using these tools to look at transactional data, we are using it to look at aggregated data. And from this point of view, data collected by GA will have very similar characteristics as data collected by Matomo. For me, the real question is which solution offers better tools to analyze collected datasets.

You should look what is in ajax response -- open browser javascript console, switch to network tab, and find the request that loads the rule. On related note: I can see something strange on your frontoffice: Those rnrnrnrn characters shouldn't be there. They probably meant to be \r\n characters -- linebreak. You should find the source of this unwanted output and fix it. It is quite likely that this will fix your conseqs issue as well (but maybe not)

With new version of tb there comes new version of smarty, which changes how things works sometimes. In old version of smarty, $carrier variable would hold value of last item after the {foreach} cycle has ended. So the original template code worked, but it just Delivery time for the last carrier in the list only. New version of smarty works the same, *unless* $carrier variable is defined before the {foreach} cycle starts. If $carrier variable already existed in global scope, then after {foreach} cycle ends, the original value is recovered. With this changed semantics the template no longer works. I'm not sure what the intention of this code in this template was. But it looks very likely that @yaniv14 is right, and that author really meant to do show delivery time for all carries. So to fix this particular case, we can use yaniv's proposed fix - this would change template output, but that's probably correct rename iteration variable from $carrier to something else. This would keep the template output the same I vote for #1

This kind of error happens when ajax response contains some extra text. This is often the case when you have enabled debug mode, and there is some php warning or notice. I have retested this on my server, and I don't have the same problem. So it's probably some issue on your server

Revws module expected image type home to exists. If it does, it should work, even for legacy mode. Anyway, this is the code that would need to be updated

Great to have some SysAdmin aboard, that's another group of problems this forum can help with now!

I've just released new version 0.4.0 PACKAGE REPOSITORY There are some automations that almost every merchant using my module created. For example, everyone created their own version of reward for review rule. Even though rule creation process is very simple and easy to understand, this repetition seems unnecessary. So I decided to come up with list of prepared solutions that you can simply import to your store and modify. You will find new tab named Packages that will let you browse through packages stored on central repository. At the moment there are only few packages, but I'll add more. Also, if you create some cool automation, please export it, and send it to me. After careful validation and verification, I will add it to the repository. This needs to be manual process to prevent any hacking attempt NEW CONDITIONS There are two new conditions you can use to build your rules starts with - evaluates to true if text starts with specific prefix ends with - evaluates to true if text ends with specific suffix

Nobody is abandoning this module. If there's something broken in the module, it will be fixed. In the same way bugs are fixed in other modules. But that doesn't necessarily mean that new functionality will be implemented. For example, support for newer version of ES server. It would be nice to have, of course, but there's just no free capacity to do that. Now, what is wrong with the module that needs to be fixed? I haven't seen any new bug reports. If you did encounter any, please file github issue. Make sure you include reprosteps so we can reproduce the problem.

I'm not sure if this module is worth the trouble. I mean, it can be extremely useful for anyone with huge amount of products, but it's not for an ordinary merchants. I believe there is less than 5% of the tb community that actually have needs for it. And these merchants can usually afford to purchase some commercial alternative, one that comes with support. Or they can hire developer to set this module for them. I'm not against another crowdfunding project, but it would be better if it was something useful for entire community. Maybe some advanced order editing module, dran'n'drop cms page builder, shortcode system to use in html editor, or whatnot.

I think the problem is in the highlighted section -- there's no src attribute in this <script> tag, so the whole snippet doesn't do anything. It just declares few variables, but doesn't utilize them in any way

That will happen only *after* referred customer make some purchase.

You didn't say if you updated thirtybees recently

New version 1.0.4 of the beesblog module has been released. There's a new feature that allows you to associate blog post with products. I personally find it quite handy 🙂

This happens when you try to add email address that has already been added. That's not a bug, it's a feature 🙂 But I guess the error message should be more clear about this

I have no problems creating orders from back office

There were indeed some problems regarding referral link. - in some cases, the module would choose unsupported encryption method -- the link wouldn't contain valid information - but even if the link was well formed, it wasn't properly handled. So the association between sponsor and sponsored customer wasn't created automatically I've submitted and released a fix. Try to update module

I've just released new versions 1.1.0 and 2.1.0 (premium). The only change in these versions is integration with my new conseqs module. Module now offers 4 triggers that you can use to implement your automations. For example, you can reward customer with discount coupon for submitting a review

Thanks for this testing, really appreciate it. If you could, please test against bleeding edge as well. Many 1.0.8 errors are already fixed

It would definitely make sense to have that. The problem is that this is ObjectModel defined by module, so it is loaded and plugged in into the thirtybees system only when some function of revws module is executed (hook, ajax call,...). So it's hard to detect that it even exists. I have a plan to scan modules directory, and look for all php files that extends ObjectModel class. That will ultimately allow me to support even object models defined by modules. But this task has low priority now

Prior 1.0.8, core used to be more benevolent to validation errors in configuration keys. Configuration::get() and Configuration::update() allowed keys that didn't meet validation criteria, like in this case (extra space). It might look like completely unnecessary check - after all, it worked so far, so why change it? Well, it actually worked only in this particular place. But it caused bugs and problems in other places. For example, Configuration is a subclass of ObjectModel. So we don't need to use Configuration::get() method, we can also load configuration entries using ObjectModel interface. For this particular entry, if we try to load it from db and immediately save it back, an exception would be thrown. That's beecause `key` field would not pass validation check enforced by ObjectModel. And that's very, very wrong. No developer would ever expect this // load configuration entry from database $config = new Configuration($configId); // and save it back without any change $config->save(); // we might never get here because save throwed exception By being more strict, and enforcing higher quality standards for modules, thirtybees is preventing these kind of weird bugs. Unfortunately, sometimes it's necessary to patch modules. But that's all right, after all, they contain bug.

I'll try to reproduce this issue on my local environment. I might take your offer if I fail to reproduce it locally

Apply this fix: https://github.com/thirtybees/elasticsearch/commit/49bfd11fd7e673d547de6115a13972a650c60f31

I've released another version 0.3.0 From feature point of view, this version brings only two new actions: Create Voucher you can now dynamically create vouchers for your customers example use case is to award your customer for posting review on your shop Award loyalty points this action is works with standard loyalty module, and it will appear only if you have this module installed and enabled it will allow you to give your customer additional loyalty points for their action for example, you can give them loyalty points for reviews, for page visits, etc... Changes in licensing: This version also changes licensing structure of this module. I decided to abandon trial-version model. Instead, I offer this as a free module with limited number of rules you can create. If you reach the rule limit, you will have to purchase license (or delete those you don't need). I made this change because I believe module like this might benefit from big user base. My hope is that its users will create interesting integration and share them with other folks.

My module should work with any payment module that implements standard displayPaymentEU hook. Mollie does implement it, so there shouldn't be any blocking issue. Regarding demo version -- this module is released under trial license. You can download it from my store, and you'll get 14 days to evaluate it for free