datakick

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.

You have to configure your php server error reporting. Access logs are nice and all, but totally useless for troubleshooting. For that, we need error logs. This is the template that works with old version of homeslider module. If you have newest version, you have to adjust your theme template accordingly. Look at the changes in niara for inspiration: https://github.com/thirtybees/niara/commit/15e5338e628fca184a339d6cde66c961bfeb8169 This was fixed a long time ago. Update your themeconfigurator module to newest version. Make sure you are using thirty bees variant -- if the author is prestashop, delete the module, and install it again from tb repository.

There's no simple solution, it's a name conflict. One of the implementation will have to change the name. This time, the conflict is between core and module. But it could very easily be conflict between two modules, if they both use same names in global namespace. Module authors should be careful to not pollute global namespace much. If they need to do so, they should use some prefixed variables. For example, i used 'revwsData' for my only global javascript variable in my revws module. This variable is an json object of other variables. There is very low chance for conflict this way. Declaring global variable 'displayPrice' was not very smart. It was not smart by AWP module author. And it was not smart by tb developers to declare this new function in global namespace as well. But what's done is done. I'm not sure what tb modules and themes adopted this new javascript function, so it would be quite risky to move it to some namespace now. You can ask module author to change their implementation, as nothing depends on that.

In xml, the language attribute contains iso code. When you import data to your thirtybees, you have to map these iso codes to language internal IDs. On every installation these ids can be different, depending on order in which you have installed the languages. That's one of the reasons why revws did not put language id into the xml file in the first place. When mapping 'Revws ID Language' field to xml file: 1) click on Advanced mapping 2) Then select attribute "language" from <Reviews> node: 3) Then click on 'Add new transformation', and select 'Find record' -- this will allow you to search for language using iso code stored inside xml attribute 4) select Languages and ISO code And that's it. During import, datakick will take value 'de' from xml file , use it to find Language by iso code, and store language primary ID inside revws Language ID field.

Thanks, fixed in bleeding edge.

I'm not really sure if your problem is caused by smarty. To replace smarty, you can download previous version of thirty bees from here https://thirtybees.com/download-specific/ , unzip it, and copy /vendor/smarty directory into your installation. That might be enough (or it will break your store). Backup the original /vendor/smarty somewhere.