datakick

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.

It works as expected. Code: <div> {$html = '<a href="https://www.somewhere.com"><strong>Html</strong> code</a>'} {$html|escape:'html'} </div> The |escape:'html' part instructs smarty to escape all html characters and display them. The above smarty code would render something like this: &lt;a href=&quot;https://www.somewhere.com&quot;&gt;&lt;strong&gt;Html&lt;/strong&gt; code&lt;/a&gt; This is exactly what should happen. If you want to treat content of $html variable as html code, do NOT escape it. The question is why it worked for you in 1.3. It should have not. I tested this, and escaping behaved the same way in both 1.3 and 1.4. Maybe there was some override, custom smarty escape modifier, or something like that. But that doesn't matter. You should fix your templates.

There are two distinct things we do in thirty bees company. Firstly, we maintain open source project. This means: we are keeping the codebase afloat - we adjust code to run on newer versions of php, database, php extensions, new versions of dependency libraries. Without this, nobody in 2 years could run thirty bees project on any up-to-date server We fix bugs in core and more than 100 modules, as we assumed responsibility for this code We maintain github repositories for core and those 100 modules. We do code review for new pull requests. We scrub new issues, deciding if the report is bug or enhancement request, trying to reproduce the issue, etc We investigate and implement security patches that are reported by third party security advisors We play the gatekeeper card here, and decide what makes it to the codebase and what not. We hate to do that, because every line that makes it to the codebase becomes our responsibility, and we have to fix all bugs it might cause. So if the PR have tendency to cause a lot of grief, it will not make it to the codebase. We maintain set of api services that provides core updater functionality translations module updates and distribution We maintain forum, trying to help as much as possible We maintain store, web, demo, and other websites. and more If you look closely, you will notice I did not mention new code or features. We don't do that. At least not as part of thirty bees project maintenance. This maintenance is actually what you are paying for, if you are a backer. We do create and release new code under open source license, though. But that code is actually not part of open source project maintenance. Thirty bees company offers paid support and custom development services that anyone can purchase. Smile does exactly this. His private company purchases a lot of support time from thirty bees company, and invest it into the area he is interested in. It was warehousing feature are, packs, feature management, multistore, etc. Some of this new code development is done in core and released for everyone to benefit from. Some of it is implemented in new modules, that are either private, or ready to make available for everyone to buy. This custom development is a private initiative, not a public project by thirty bees. It is paid by third party company. Decision what features will be implemented or enhanced is entirely up to the company that purchased support time. Note that I play the codebase gatekeeper card here as well. I do not allow new code that could break the things for others. Some requests could be implemented very easily in a few minutes, but because they need to be reusable for everyone, it can actually take a few hours or even days to implement that in generic way. Smile is paying for that extra time, even though he does not benefit from it directly. Anyone can contact us, purchase some custom development time, and implement any feature they want. We will be happy to provide that service. Or they can hire third party developer to do that for them. We will do the code review, and merge any PR as long as it does not break things for others. Everyone can contribute to the open source project. And if they do not like the way we do the gatekeeping, they can fork it and maintain their own version. @Mark says that I'm playing the overlord and decide for everyone, and it's true. That what open source maintainers do. Somebody has to be the bad guy that rejects bad contributions. I'm comfortable being that asshole, I'm doing my worst for a good of thirty bees community, at least I believe I do so. Why are we maintaining this open source project? We don't really have to, now do we? I mean, Smile could fork and create his own version of thirty bees, hire me or other developer directly to maintain it for him. He would save a ton of money on development time, as there would be no backwards compatibility issue to solve. We could change anything and tweak everything directly in core. No modules, no overrides. No bugfixes for modules we don't use. No maintanance of code we don't use. We are maintaining the thirty bees project because we like the community, and we like to give back. We will continue to do so as long as we feel that there is a community to work with, and that the community cares. Being a backer means a lot in this context. It helps offset the expenses directly related with code maintenance, and it shows that there are people invested. It's a nice and tangible metric.

That sounds like a good approach. Of course, it is tied very closely to contact controller, but that's probably ok. I think that we could implement some new hook in core to hide this dependency a bit. Contact controller could call hook 'actionValidateContactMessage($message, $email, ...)'. Your module would only have to implement this hook, and return true on success, or array of error strings on validation error.