datakick

What I meant with PHP is that module developers might not opt for using templates for some views. Sometimes it makes sense to generate html markup directly from PHP. For example, I've seen markdown interpreter module -- this allowed you to write your product description in markdown language, and the module converted it to html. For that, some php library was used, only customized to inject proper css classes to the output. Bootstrap css classes, mind you. Such module would not work properly on different tech stack, not without rewriting this php customization. With js -- a lot of modules use javascript to construct and replace DOM tree dynamically. In that case, bootstrap classes and building blocks are hardcoded inside javascript code. How hard it would be to rewrite this functionality to work properly with different css framework depends on how similar these frameworks are. For example, bootstrap's rows/columns abstraction are not always available.

Almost all frontend modules will be affected, if the new theme will be based on different technology stack. I assume some of them will be easy to adjust -- simply rewrite the views and use scaffolding blocks from new framework. For some modules it will be much harder, as it might require rewriting parts of js and/or php. It's not reasonable to think that module authors will do this kind of modifications, at least not until the theme is well adopted by the community. Will this new group provide technical support for all these modules, and help with views/js adjustments? If not, I'm afraid the new theme would not be adopted by general audience. Technical people like @wakabayashi might have no problems adjusting those few modules they are using for the new theme, but ordinary merchants wouldn't know how to modify module templates. They want something that works out of the box. Just my 2 cents

I don't think there is any such mechanism in the core. You might have some module installed (blackhole for bots, for example). Maybe some security apache module. Or the crawler could be flagged by couldflare or similar proxy you might be using

The module is quite nicely written. It logs a lot of interesting information if enabled. Make sure logging is enabled, and then look into Advanced Parameters > Logs, there might be some hints

One of the problem is module compatibility. You can create a nice new theme based on new technologies, like Tailwind, but you will have hard time integrating it with third party modules, as they expect the basic setup to be available - bootstrap and jquery. Which means that you will have to modify/adjust a lot of modules templates

The module depends on a PS settings that was never implemented in thirtybees. In prestashop there is a flag named PS_SSL_ENABLED_EVERYWHERE, because for some reason PS_SSL_ENABLED is not enough for them. In prestashop world, you need to as the system 'Please use SSL. Thank you, that's so nice that it works on standard front controllers. And now, if you could, please use SSL everywhere, even for modules controllers'. Anyway, my rant about this will not help much. To fix this issue, simply run this SQL command -- it will add this flag to configuration table (you might need to change tb_configuration and adjust db prefix). The module will use it, and the rest of the system will ignore it insert into tb_configuration(name, value, date_add, date_upd) values ('PS_SSL_ENABLED_EVERYWHERE', true, now(), now()); Note that this is not the 'true' compatibility issue. The module would now work with ps version 1.6.1.11 either (this is the compatibility baseline), but only with latest 1.6.1.24. But that doesn't mean we shouldn't do something about this. Quick search in github shows that a lot of modules are using this switch, so we might emulate it dynamically to make the life easier and avoid unnecessary problems.

Please PM me the module, I can have a look. It might be just incorrect checking

You can download my Consequences module and use it to block the outgoing email. I'm using it myself.

This is not usually what happens. Spammers use email addresses of real people, not their own. They are abusing your server to act as a sender of spam mails. Of course, they occasionally use their own email address to check that the emails are sent, but in most cases they use real email addresses. The most efficient way to mitigate this is to block outgoing contact_form emails. Spammers will have no reason to abuse your website, if it does not send emails to end users

This is already fixed bug. You can either update to bleeding edge, or apply this fix: https://github.com/thirtybees/thirtybees/commit/a7cd6399183897306cbbd77cac13a4f525344bb8

That's strange. There are few possible reasons for this, none of them very likely the file is not readable -- check file permissions the smarty context is misconfigured -- maybe some module changed include path to different location... very unlikely I don't think update to 1.2 would solve this,... but of course it may 🙂I wouldn't worry about modules compatibility, they should work as fine on 1.2 as on 1.1

I'm afraid this is almost impossible to fix. Core does not know what payment options exists, they are not enumerated anywhere. It only knows about modules that implement 'payment' hook, but what payment options each module provides is big unknown. When the payment is processed, payment module gets a chance to create/validate an order, and during this step provides information about the payment to be stored inside order. Because this info is not available to the core itself, we can't really use it during back office order creation, not without invoking payment process itself.

Ensure that file <admin>/themes/default/template/controllers/logs/employee_field.tpl exists -- replace <admin> with your admin directory. If it does not exists, you should use core updater to sync your codebase

Hi @Dolfijn, I can't reproduce this issue on latest niara/community theme. The price calculation works correctly for all calculations and volume discounts. This looks like a bug specific to your old ps16 theme. I'm glad you already have a solution, maybe it will help others that comes with old ps16 default theme.

@Dolfijn what theme do you use? Both product.js and product.tpl are part of the theme. If there is a bug, we can fix it inside community-default-theme and niara, but it will still be part of third party themes.