datakick

Yet another version of this module is out. From outsider perspective not much has changed - some ui was moved around, and few bugs were fixed. But under the hood there were many more changes related to review types. Basically, this version brings support to review different types of entities, not only products. I will use this as a foundation to implement store reviews in the future (although that's probably going to be premium feature)

@30knees this error message is not really helpful :) But it seems that Mollie module should have a switch to display real error. Enable this option is module's configuration page and try again

@30knees the problem is in psograph.tpl template, and that's not part of the mollie module. First find out what module uses this template. The problem can be that these two modules can't work together - they both probably set the same smarty variable, thus creating conflict.

It's strange that ps16 module won't run on thirtybees. If there's some compatibility issue, it should be fairy easy to iron out, either in tb core or in module itself. I'd be happy to check your module compatibility for you. On related note - have you tried elasticsearch module? It might be good replacement, and it would speed up your shop as well

Sure, the module itself contains installation procedure

Good. I've created pull requests with the changes to master repository. It seems to be abandoned, though

Note: I've moved this to separate topic

@x97wehner edit this line and change it to look like this: php 'total_to_pay' => Tools::displayPrice($params['total_to_pay'], $params['currencyObj']),

@x97wehner I meant logs stored in file inside log directory: /log/20181120_exception.log

@x97wehner look into /log directory inside your thirtybees installation, there you should see the 'real' error message

Look into your webserver's error log, there should be some information about what's wrong

you need to reset the module. The tab is created during module installation --> when you change installation related code, you need to reinstall the module

Are you using default schema of urls?

Also, open javascript console, and if you find any error, copy and paste it here

You need to provide more information if you want our help: - firefox version - your operation system - thirtybees version - and most importatnly -- your url address

yep, that doc is a good start

https://forum.thirtybees.com/topic/1798/bcc-for-all-outgoing-emails/

@x97wehner I don't have 2checkout account, so I can't verify that the following will work. Could you please check Edit file /modules/checkout/controllers/front/validation.php and change line 40 from php Tools::redirect('index.php?controller=order-confirmation&id_cart='.(int)$cart->id.'&id_module='.(int)$this->module->id.'&id_order='.$checkout->currentOrder); to php Tools::redirect('index.php?controller=order-confirmation&id_cart='.(int)$cart->id.'&id_module='.(int)$this->module->id.'&id_order='.$checkout->currentOrder.'&key='.$customer->secure_key); That should do the trick

@x97wehner what payment module is that? Shouldn't be hard to fix it to work as other payment modules

also ensure that directory /config/xml/themes exists and is writable

@gandalf I don't think we can consider module to be badly-developed just because it uses php filesystem api. I personally have created a few modules that would be impacted by this (their content would not be synchronized by default). Now, there exists thousands of modules out there compatible with ps16/thirtybees. We can't really expect their developers to update them all, or force them to use some fs abstraction layer. It's just too late for that. That said, I still thing application layer is not the right place for this. Especially since there are very few merchants that would actually use this kind of feature.

@gandalf Application is not the right layer that should address this. In fact, it's not even possible with open system like thirtybees. We could fix all places in core that touches filesystem and change it to use this filesystem abstraction layer, but what about third party modules? Any module can use php filesystem functions directly, so this abstraction would be bypassed anyway. You would end up much worse -- some assets would be correctly synchronized, while others would not. And there's nothing thirtybees can do here -- we can't just force module developers to use our filesystem abstraction. If you want to sync files, you need to do that on different / lower level. Either at php server (php module that tweaks filesystem api), or at OS level (map thirtybees installation over distributed virtual volumes).

I think the main reason behind this request are the dynamically generated assets - regenerated thumbnails images, CCC css + js files, etc. But that's mainly infrastructure problem, and should not be solved at application level.

Out of curiosity - you do have dashboard's demo mode disabled, right?

You can migrate productcomments reviews to revws module, though