datakick

I am using bleeding edge on my store, and I know about a lot of people that are using it as well. Works properly for all of us, as far as I know. Every store is unique, of course, considering how flexible the module/override system is. If @Mark has 500 error on bleeding edge, then it's most likely some customization issue. Of course, it can be bug in core, that manifests only in some specific use cases. However, without any error message from debug page or php server log file there is no way to tell what's wrong. Note that currently it's not possible to roll back from bleeding edge back to 1.3.0. The reason is that bleeding edge introduces new database column 'active' in 'tb_category_shop' table. This extra column produces 'ambiguous column' database error on 1.3.0. The fix is to drop this column from db table manually when downgrading from bleeding edge to 1.3.0. Core updater does not do this automatically. Actually, it can't do this, because a lot of third party modules extend core database tables with their own columns. If core updater dropped all of these columns on update... well you can imagine what would happen.

This is generic mechanism that is utilised across multiple areas. It can be used in back office forms, or even by some front office features (modules). Even in back office use, it's always good idea to be cautious. Shop owner could copy and paste some html code, a code that could contain javascript or css. This javascript would make it to shop front office, and that's quite severe security issue. Even if the js is not an attack, it can easily break your pages by throwing javascript errors, and thus preventing your own javascript code to work properly. Similarly, any css inline code can very easily make your pages unusable. While WYSIWYG editors are useful, the backend php should never trust the input. Sanitization of input can help you very much. If you need to enter special html markup into your 'texts', then it's a very good indication that you are doing something wrong. You should modify your theme templates instead, and keep your content clean - just text with some basic formatting options.

There seems to be some injection in bleeding edge, regarding token validation. It is either bug in the core, when token validation is incorrect. Other explanation is that this used to be bug in the core that was fixed recently, but chex somehow depended on it. I will investigate, and either fix the bleeding edge, or the module 🙂

This is fixed now, please update to the latest bleeding edge

Thanks for reporting this, I will incorporate the fix into the mainline. In the future, please file github issue on https://github.com/thirtybees/thirtybees/issues Forum posts are very easy to overlook or forget. If you file issue, it will be tracked until resolved

Check image type sizes. <img> within <picture> has explicit dimensions sourced from image type, maybe that's the reason why in your case the sizes are different. If so, force the size with css rule to match. Or upadte image type dimensions and regenerate the images

Please re-read the first post of this thread. You will see image there that showcase this option -- on individual features, you can enable 'Allow multiple values' functionality.

That's correct. If you migrate from 1.2, just make sure the db is migrated properly, see the first post in this thread. Then, you can enable multiple values for individual features, and that's all.

This sounds like a customization. We should think about enhancing current customization feature to allow for these kind of attributes. Also, it would be beneficial to have the customization saved on the fly, and not force visitors to save customization before they order. How about we start a new thread and discuss our needs in this area? Once we brainstorm the requirements, I can plan this into the backlog

Yes

This is not build in functionality. You can use my conseqs module to create a rule to send email when new recort 'Order Return' is created.

File github issue so it will not be forgotten

Create file phpinfo.php in the root directory of your installation with following content: <?php phpinfo(); And then open www.yourdomain.com/phpinfo.php. It wil tell you what extensions are used

Also, what PHP version are you using?

phpinfo - https://www.php.net/manual/en/function.phpinfo.php

well thats strange. The only reason for this behavior that comes to mind is missing php xml extension

What language have you selected for installation?

The override solution will 100% work. You can also adjust your .htaccess file and redirect the contact page url to 404 there, totally bypassing php code.

Something must be different. I just tested this on community-theme-default on my local installation and it works properly.

Here you can see the differences in HTML markup created by template (red) and javascript (green). You need to modify one of them to match the other:

This is theme issue. The HTML inside cat block can be either created dynamically on client side using javascript after the ajax call(file ajax-cart.js), or directly on your server during standard full-page load, using template blockcart.tpl. I assume your theme modified one of these two approaches (either js or template), so it's a little bit weird. You should investigate, and either revert the change, or modify the other display method accordingly.

Disable error reporting in your php settings.

It's specified in the system requirements: PHP 5.6 - PHP 7.4 with a minimum of 128 MiB RAM I guess it is a good idea to add a runtime check into the application, though. To prevent even starting thirtybees / installation process on non-compatible php version. We plan for 2 releases per year. The next one will be out in about 5 months. I can't promise that the php8 support will be part of it, though. It's not an easy task, considering we want to keep system compatible. The problem is that php8 comes with new reserved class name 'Attribute', but thirty bees / prestashop used this name for years already. Prestashop solved this problem by simply renaming the class in the core, so it's no longer named Attribute. The problem is that this does not fixes issues with any modules that might be using this standard class. We want to come up with a slightly better solution, but it's also little bit complicated to implement.

TB is not compatible with PHP 8 yet. The work on compatiblity is in progress, though. Hopefully the next version 1.4 will be fully php8 compatible. Until then, php 7.4 it is.

Customer data are exposed. Customer service messages aren't. For some reason, order notes are stored as a customer service message/thread.