datakick

Tax calculator needs specific address, it is not based only on countries. For example in US sales tax can be different in different states/counties/cities/postcode ranges. Thirty bees actually displays price for selected delivery address. The problem is that in most cases the address is not selected before you go to checkout page. You can test it: go to checkout page, create new address for example in the US, and then go back to your catalog. You should see your prices displayed without tax. If you choose address in different EU country you should see prices for that country. We could make a module that would create 'dummy' addresses on the fly based on your geolocation (by default) allowed you to select your country in some select box on front office (explicit selection) and make sure that the dummy address is actually deleted before you go to checkout page I do something similar in chex module to determine final price.

In my opinion there have to be some sort of 'complete' button, otherwise different issues would occur. For example, removing product from cart by mistake. I can add some prominent 'Save changes' button that appears only when there are some modifications, but is has to be there.

gridhtml module is not compatible with thirty bees since version 1.0.4 - its functionality was merged into core. This module was probably uninstalled in the past, but was still present on filesystem in /modules/ directory. Unfortunately, thirty bees sometimes have to load and instantiate even non-installed modules. For example, when module's config.xml file is missing, or if language-specific version of this xml file is missing (config_cs.xml, config_nl.xml,....). This config.xml file is sort of a cache that contains basic information about module (name, description, author). When you open Modules page in admin, system opens all these config.xml files in order to display information about modules that are available on your system. If config file is missing in module directory, system have to instantiate the module and extract info from module instance properties. This is very stupid approach, and also very dangerous. Because it actually loads module main php file, and executes any executable code. The code may be malicious. In this case, the main module file contains class that can no longer be instantiated. Thus the exception. And it's also explains why store owner didn't encounter the issue -- they may use different language than you do. We know and track this issue. However, it's very hard to fix. The alternative is static analysis of module main php file during runtime. That is very, very complicated.

It's in because it is useful feature, and there is no security issue with it.

Not necessary on 1.4.0

Yes, the fix applies for any combination of customization fields.

what problem with attached picture?

Thanks for investigation, I've filed github issue for this: https://github.com/thirtybees/thirtybees/issues/1612

I've tested and indeed SQL generated by orders page was not properly validated. This is probably caused by recent update of SQL parser library, which now generate more verbose syntax tree. I've fixed the validation logic, so now (in bleeding edge) the order sql query can be validated and saved. If you find any other list sql queries that can't be processed by sql manager, please file issue on github. Provide full SQL that can't be processed.

Yes, such functionality was never implemented. Thirty bees always saved product base price as tax excluded. On product page you can enter price tax included, but all that does is that system will calculate price without tax using default country tax rate, and save this info into database.

I don't think this is php7.3 vs php7.4 issue. More likely tb1.3 vs tb1.4 issue. In tb1.4 we no longer silently ignore invalid SQL queries, but we throw exceptions instead. This module generates and executes invalid SQL query. In tb1.3, line $totalAbandonedCart = Tools::displayPrice((float)Db::getInstance()->getValue($qr), $currency); would result with $totalAbandonedCart variable containing 0.0. The same result would be if you executed this: $totalAbandonedCart = Tools::displayPrice((float)Db::getInstance()->getValue("SELECT 1 FROM table_that_does_not_exists"), $currency); In TB1.4 this throws exception. There is obviously something fishy in the code, and we shouldn't try hide it. If you need previous functionality, you can enable it in Advanced Parameters > Performance. I strongly advice against that. You should contact module author and have this fixed instead.

Yes, it is possible. However there is no step-by-step process that I can describe. Why do you insist on using php7.2?

When you download 'code' from gihub as zip file, and then extract it, it creates directory named after branch. In this case, the directory is 'genzo_turnstile-master'. You need to rename this directory to 'genzo_turnstile'. Then you can either zip this directory and upload it via back office, or you can upload this directly into /modules/ using ftp.

Best solution would be to enable php7.4 on target server. If you can't do that, then you can use core updater on source server and update to codebase for PHP7.2, then copy that to your target server. Note that this can be done for 1.4.0. If you are on bleeding edge (1.5.0), php 7.2 is not supported anymore. Php 7.4 is lowest version

I'm not sure if the module is compatible with TB1.0.8. It is possible it uses some functions and methods that are available in newer version only. Anyway, it looks like problem is with module update. Have you tried uninstalling the module completely, and installing from scratch? That might work.

You can remove all except 'hover' -- that one is created by a module. I hate it when modules modify core database tables, but they do that sometimes. And thus making system more fragile and error-prone, specially when those columns do not have default values, are part of keys, etc.

It may or may not be bug in module. Usually, it's just some copy'n'paste issue, or forgotten piece of code. But I have seen modules that had spelling mistake in handler function, and therefore didn't work as designed. Fixing those spelling mistakes actually fixed some bug in the module (in this particular case, it was cache invalidation) In any case, module author should look at it. For core modules, we have already fixed most of these issues. For example, blockcategories is fixed in version 3.0.3 https://github.com/thirtybees/blockcategories/commit/f242b651ff078c1b69474f4a028fa2fe336fe695

Yes, that is the fallback mechanism, but that works for front office only. We will probably have to extend it to support back office image links as well -- those image urls can be relative, does not contain image types, etc. Maybe it will work without changes, I'm not sure.

Ftp to your server, edit file /themes/ptsvshop-template/modules/blockcart/dropdown.tpl and look for line {assign var='free_ship' value=count($cart->getDeliveryAddressesWithoutCarriers(true, $errors))} or something similar to it Change it to look like this: {assign var='free_ship' value=count($cart->getDeliveryAddressesWithoutCarriers(true))} What has to be changed is highlighted in the link I posted above.

Your theme contains override for blockcart.tpl template. You will have to update it to be compatible with PHP8. Look here for inspiration: https://github.com/thirtybees/niara/commit/1f9629157606620748b3b5e769d621d9ccdfc751

We are not a product company. I would like that, but that's just not realistic. As you wrote -- there isn't enough resources for that. We would need product team (maybe even multiple product teams, for different feature areas). Each team would have to compose of: few developers to implement new things Product manager that would understand the given domain, plan new features, communicate with external stakeholders (merchants) and incorporate their feedback into the roadmap QA engineers, as new code have a great tendency to break compatibility and other stuff Tech and docs writer to communicate new features to target audience We would need at least one such team. But more would be better - one of them focusing on warehousing, other on front end features, etc. And then, we would need marketing and sales team to promote the new stuff product team would be creating. All of that might bring new users for the system. That's not revenue, though. We would need some monetization strategy that would utilize this big user base -- maybe module selling. What else? Maybe support or custom development, but that does not scale well. To get there, we would need a serious investor that would give us hundreds of thousands of euros. And we would burn through them in no time. That's not realistic. Therefore, we went for the second best think. We created a support-based company. We provide limited maintenance and no new features development. We don't actually need huge user base to fill ours support capacity. Since we are not developing a product, I don't see much reasons why to include you into any decision making. You guys would talk a lot, decide on a nice set of great new features you want us to implement, and then be upset that we do not do that. Because we don't have that resources. We could include you into bug prioritisation, that's true. You could tell us what bugs give you the biggest headaches, and we can try to fix them first. Please read what I wrote in previous post. We are maintaining things. Maintenance indeed consists of countless little things that should not be visible to end user, ideally. We fix warnings before new version of PHP upgrades them to errors. It's like removing skin marks before they turn into cancer. We do fix a lot of bugs. Some of them might not affect you. Some of them affect you only a couple times a year. Is there a bug that is causing you trouble every day? I personally don't know about any. If you experience some, please let us know. Once again -- there is no bug in geolocation feature in the core. You have complained about configuration of a third party module. That' s the problem of that module, not core. It's like you were complaining to the car manufacturer that the radio you purchased somewhere and installed into the car does not have a volume button. I agree that volume button is important, but it is not a bug in the car. The new warehousing module is build for Smile specifically. It replaces his current external ERP integration, so the scope and functionality requirements are very clear. There is nothing to discuss with community, because the first version is not intended for you, really. We don't need to burned ourselves with additional feature requests at this moment. There is a huge task backlog already. Once this initial version is completed, it will be released as a paid module. That will be the time for community to test it, and we will take notes and requests for further enhancements.

This message comes when session is not found. For some reason, file manager requires PHP sessions. We should definitely rewrite that and depend on cookies only. But at the moment that is how it is. You should check that you have sessions set up correctly -- some servers have this disabled, use /dev/null as a session storage, etc.

Module version 1.0.4 was not php8 compatible. Try new version 1.0.5

There is still explicit dependency. This captcha would not work unless your module knows about the front office page. For example, imagine that somebody uses third party OPC module. This module calls all the hooks, so the captcha would be displayed correctly. However, your module will not be able to validate it, because the front controller is not the standard one.

I don't think this is bug in core. It's bug in theme, though. srcset="{$imageUrl|escape:'html':'UTF-8'} 211w" The url in srcset attribute is escaped using 'html' escape. Spaces are allowed in html. It should be escaped using 'url' srcset="{$imageUrl|escape:'url':'UTF-8'} 211w" Space in url would be url-encoded to %20 You are right that this could be prevented by forcing image types to not allow spaces. It might make sense to do so, but it would also be very hard to roll out. Change like this would break a lot of stuff, like .htaccess rules, nginx config, force merchants to regenerate all images (and prune old ones), etc... Also, it would only hide the actually bug, which is the escaping in theme (and other templates). Note that his bug is not related to image types only. For example, if you deployed thirty bees in subdirectory that contains space, you would have the same problem. This time, invalid url would look like this: https://www.server.com/subdirectory with space/img/1234-Niara_home.jpg It would break srcset as well. And there might be other uses cases when wrong escaping can play a role.