datakick

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.

Awesome. I'm personally using Redis as a caching engine, and it works like a charm. I opted for Redis because I deploy components on different digital ocean droplets - mysql and redis run on different server than php. For people running everything on single server APCu will probably be a faster and simpler solution. It might be less stable solution when server is under heavy load, but generally it should work fine. Regarding FPC -- it can be great solution if your store does not contain a lot of dynamic data. If you tweak it correctly, punch the right holes for right hooks, it can be blazing fast. Problem is that nobody can tweak it correctly unless they look into modules code. Smarty cache invalidation, on the other hand, is governed by modules themselves. Module author is responsible for proper cache handling, and they usually do it right. For most folks, using smarty cache should be go-to solution.

Hi everyone, We have just pushed new functionality into bleeding edge, and I would like to ask for testing if possible. We have added another option for smarty caching engine -- beside 'File System' and 'MySQL', you can now choose to store smarty cache inside Server Side Cache: When enabled, thirty bees will use cache implementation selected in Server Side Cache section: The most interesting options are Redis and Memcache -- these are extremely fast in-memory key-value stores. Please test and let me know if you find any problems.

Never seen issue like that. There were no changes in hook execution/evaluation in 1.4.0. Maybe this is related to smarty library update.

This has been fixed in https://github.com/thirtybees/community-theme-default/commit/017ebd1a72336d043b26f383984e67a0254a3f63 Either update your theme to latest version, or manually apply the fix.

When you look at code usage of purchase_supplier_price, then it looks like the amount was supposed to be stored in order currency. For example, AdminStatsController divides the amount by conversion rate. However, usage of `original_wholesale_price` is more complicated (and buggy). For example, statsbestcategories: IFNULL(SUM( CASE WHEN cp.`original_wholesale_price` <> "0.000000" THEN cp.`original_wholesale_price` * cp.`product_quantity` WHEN pa.`wholesale_price` <> "0.000000" THEN pa.`wholesale_price` * cp.`product_quantity` WHEN pr.`wholesale_price` <> "0.000000" THEN pr.`wholesale_price` * cp.`product_quantity` END ), 0) / o.conversion_rate AS totalWholeSalePriceSold this does sum of all original_wholesale_price if exists, or wholesale_price from product if not. This sum is then divided by conversion rate, suggesting that the amount should be in order currency. However, in product cuntext, the amount is stored in default currency. So this stats never worked again. I suggest we fix this as well, and save original_wholesale_price in order currency as well. Then let's fix the stats sql

This is nice bug. Calling __destruct on connection instance make this instance unusable, but does not remove it from connection pool. Sequence like this would fail: Db::getInstance(_PS_USE_SQL_SLAVE_)->__destruct(); Db::getInstance(_PS_USE_SQL_SLAVE_)->execute('select * from table'); Tracked in issue https://github.com/thirtybees/thirtybees/issues/1600

Probably override in your theme. Read here:

Again, there is NOTHING to fix here, from the thirty bees perspective. Thirty bees / ps16 always performed geolocation using maxmind database. Because maxmind stopped supporting database version 1, we had to fix it. When we were doing that, we though that it's a good thing to make this 'detect country' functionality pluggable, instead of depending on single implementation. So we extracted it to separate maxmind geolocation module. We support both this new module, and geolocation functionality in core core. If you use these two together, you will have the same functionality that always existed. This new pluggable architecture allowed ME (not thirty bees) to create another module that gets the geolocation information from cloudflare. This module is mine. I made it myself, in my free time. It is new functionality. It is not part of thirty bees native modules. From thirty bees perspective, this is just ordinary module by third party developer. You don't have any rights to go on this forum and demand changes to that module. It is absurd. It is like you creating a new issue in thirty bees project demanding changes to Panda theme.

You are mistaken. I have not marked this request as an enhancement. I have simply closed it as an invalid request. There is absolutely nothing to implement in thirty bees core here. Core does not know anything about individual geolocation modules, and therefore it can't check if those modules are correctly set up. That check should be responsibility of individual modules -- if not configured properly, module can simply not offer itself as an geolocation option. Your request is basically an enhancement request for my free CLOUDFLARE GEOIP module. Thirty bees core issue tracker is not the right place to submit enhancement requests for third party modules. That's the reason why I closed the issue. Nevertheless, I copied your request to my personal to-do list. This is module that I have implemented in my free time, and I offered for free on my website to the community. As a free module, it was released "as it is". I agree that your proposed enhancement make sense. But it has very low priority, especially since most users didn't have any problems settings things up. This is not a bug in the module, it works nicely if you setup cloudflare correctly (and have no intermediate proxy that might block these http headers). I have a big backlog of more pressing issues for my premium modules that have priority, and very little time to work on those. If this is really a pressing issue for you maybe you could try to fix it. After all, it's just "simple to do since its just data in a header."

Indeed, this was javascript bug. I've released new version 0.9.1 that fixes this one.

Both modules runs without problems even on PHP 8.2 As I wrote before - this looks like a theme issue. Your theme overrides template for these modules, and these overrides are causing issues.

Any changes to core files will be wiped out when you update your store using core updater. You have been warned 🙂

It's true that bleeding edge is not intended for production use. I personally use it on my production server, but that's because I know what I'm doing, and I'm fine with the risk 🙂 Bleeding edge changes quite often, and sometimes it contains some new bugs. This version should be deployed to testing environment, if you have any. If not, I strongly suggest you to create one -- so you can continuously test the upcoming release, and see if you are in need for any modifications. And provide feedback to us if you encounter any issue, so we have a chance to fix it before official release. For production, I recommend you use 1.4.x branch -- it can be found in 'Custom target'. This is bleeding edge for upcoming bugfix release 1.4.1. The diference between main (bleeding edge) and 1.4.x is that main contains bugfixes, new feature work, refactoring, code maintenance, etc. On the other hand, 1.4.x receives only well understood bug fixes. There are no new features or refactoring that could cause unnecessary troubles. One could argue that 1.4.x is more stable than stable release 🙂