datakick

The fact that the database is located on different server connected by stunnel is unrelated. This is just a red herring. Let me reiterate what we know: during installation, database is created from scratch as is empty the theme is installed when index.php?installTheme=true request is processed by php server. This is the only place in install process that calls the theme install method the error is throws only if theme is already installed -- the record in database exists The only explanation for this error to occur is that the index.php?installTheme=true request was processed twice by your php server. If you browser does not send the request twice, then there must be some other component in your infrastructure that duplicates / repeat this ajax call. For example, there could be a load balancer or proxy server. Maybe proxy server is misconfigured, and re-send the request to your php server if the response is not received promptly (this might actually explain why it works when db and php are on the same server. Communication via stunnel is bound to have higher latency) Look into your php server access_log to verify how many times the installTheme request was received.

Not possible. Just... no. The only way this could happen is if your browser sent two ajax requests to install theme. That's very unlikely. Very, very unlikely. Unfortunately it's possible, but only if you have some very weird caching browser extension, adblocker, etc. Or maybe some server redirection.... who knows. Look into browser console, Network tab, and see what requests are send during installation. There should be only one request with installTheme=true

Yes, cron is one possible implementation for Work Queue Executor. Not the only one, though 🙂 There should be some implementations that does not need any additional configuration, implementation that works right out of the box after the installation. This will be true for Immediate and Deferred executors. Then we can have advanced executors (standalone, cron-based,...), but for them to work properly additional infrastructure will need to be implemented. For cron-based implementation there will have to be cron endpoint. For standalone, there will need to be redis + requirement for VPS to run dedicated php cli application...

The link does not work, because MaxMind no longer offers download to unregistered users. You can sign up here, and then download the database for free: https://www.maxmind.com/en/geolite2/signup?lang=en

Sorry about the delay, I totally forgot about this one 🙂 This new tracking feature in 1.3.0 is basically a mechanism to send anonymous usage data to thirty bees api server. We made very sure that no personal or even domain information are being shared with using this mechanism, so it's aligned with GDPR requirements. At the moment we track only the very basic info about the installation: php version, installed php extensions, database version, and basic server settings (max exec time, memory limit, etc). In the future, this mechanism will be extended to track other informations like feature usage. Why do we need this information? There are couple of reasons, of course. First of all, we are investing a lot of effort and money into this thirty bees enterprise. And we need to have some way to actually measure the adoption of the software. When we were considering purchasing thirty bees we discovered that nobody actually knew how many stores are using this software in the wild. That's not good really. Without this information, it's quite hard to prepare business plan, monetization strategy, or whatnot. Merchants are using google analytics, matomo, or other tracking software to gather this information about their visitors. We are using this new feature to do the same. This first reason behind this feature is not something that merchants benefits from, thats for us. But there are other reasons that have (or will have) direct impact on merchants. With the collected statistics we can much better plan the development. For example, we are considering dropping support for some php versions - one of the reasons being that it makes it very hard to update dependencies / third party libraries might not support older version of php. But we don't want to just drop the support out of the blue, and leave merchants in the bind. Before we do such drastic thing, we want to be sure that the impact will be minimal. Another example: feature usage, that we currently do not track, but we want to - if we knew how many merchants are actually using some feature (ASM, multistore, theme, module), we can much better plan our efforts. If we knew that only 5% of merchants are using ASM, then probably it's not a good idea to spend a lot of effort in fixing the bugs, but maybe it's time to consider dropping this feature from the core (moving to module) instead. Php extensions are another interesting info to have, as it can answer the questions about potential features that might depend on some extension. Regarding consents. As I already wrote, the collected data are anonymised, there's no law or regulation that requires for us to obtain a consent. Regardless, we want to have the merchants the ability to decide if they want to help us collect this info or not. Unfortunately there wasn't enough time to implement all aspects of this consent mechanism. Currently, there is only a database table that governs consents. If you do not want to allow sending the info to api server, you can update table `tb_tracking_consent` and nothing will be sent to us. Of course, changing the consent in DB is not very user friendly 🙂 In the next major release there will be UI for this. There were other, more imporant tasks, to implement for 1.3.0. These consents will gain more importance once there are more 'personal' type of data to be collected. Work queue is a mechanism to run tasks outside of the main execution thread 🙂 Yeah, I know. That didn't help much. During execution of php script there might be some tasks that do not need to be executed immediately. For example, when you change order status, an email might be send. Sending email can actually take a lot of time, and that impacts the page response time. Employees have to wait couple of seconds just to see the result of this simple operation. Also, what happens if the smtp server is currently down? Yeah, the process will fail, back office page will display error message, and employee do not know what happened. With work queue we do not send emails. Instead, we just describe the 'Send email' operation as a task, and submit it to work queue executor, and immediately continue. Work queue executor will ensure that the task is executed as soon as possible. The task description can be serialized and stored somewhere. This allows us to actually run work queue executors on different servers, or in different process on the same server. It also allows us to try to recover from errors -- for example, if sending email fails, we can retry it later after some delay. There are a lot of operations that can be converted to work queue tasks. Clearing cache, generating images, webservice calls, cleanup tasks, and more. By converting these operations to work queue tasks, we can also trigger them differently. We can have a cli tool to actually run these tasks -- so you can ssh to your server and run command to clear cache, or regenerate the images. These tasks can also be scheduled using build-in scheduler. In 1.3.0, we only introduced the basic mechanisms for work queue, mostly because of scheduler that we needed. There is still a lot of work on this functionality. For example, we need to actually implement different types of work queue executors. Currently, we only have 'Immediate executor', that runs submitted tasks immediately in the context of the current thread. But in the next release, we will introduce new type of executors. There will be immediate executor -- currently available, executed tasks immediately in the context of the thread. Does not support retrying. There is not really a benefit, apart from error handling. deferred executor -- the tasks will be executed in the context of the php thread, but only **after** the response is send to the user (not all servers supports this feature, though). This will increase page response time. standalone executor -- standalone php application that can run on the same server or on other server as well. Will receive the work queue tasks via some queue (redis, kafka, memcache...). This is solution for serious merchants that want to run high performant stores I'm happy to answer any questions.

It should be safe to use this mechanism as long as you are in control of this external site.

That's correct, this is very sensitive information. This mechanism not only recover and associate the cart with your session, but also authenticate the user -- if the cart belongs to some customer, you would be logged in as this customer. This could be quite dangerous -- anyone who knows cookie key can log in as anybody.

It will be a little bit complicated to make this kind of integration work, though. Yes, you can use webservice to prepare a new cart. This one is quite simple. The problem will be with redirecting user to your store and associating this newly created cart to their session. There is a mechanism in place that allows you to recover cart by passing query parameters recover_cart=<cartId> and token_cart=<secret>. The problem is with the <secret> - that is based on _COOKIE_KEY_ constant, and it's not the best idea to share this information with third party store. For those interested, the value of <secret>=md5(_COOKIE_KEY_.'recover_cart_'.<cartId>), if anyone is interested

I've installed it on my test thirty bees, configured, and it works properly. What does not work for your?

Yes, it's not recognised as a bug. This is expected and wanted behaviour. Some merchants would be angry if we removed this functionality, actually. As was suggested above -- you can modify the core file, or create an override. But you can also install my consequences module, and create rule that will block sending this particular email from your store:

Server-side rendering is so 2010 🙂 We all should acknowledge that the world has moved on. You are probably right. In my modules I personally try not to rely on any framework provided by theme to make module reusable in different environment (revws works properly both on tb themes and in ps17 theme) I'm really excited about this project of yours. Let me know if you need any assistance, or support from core.

Unfortunately even that's not always possible, as there are modules that generate a views using javascript (heavily minified). For example Mollie, avarda payments, revws, etc... But of course, these modules are the outliers. Most modules should be able to tweak and make them to work with new framework. The question is how much work it will be 🙂

Looks nice. I'm quite interested how easily it will integrate with third party modules that were not build with bootstrap 5 in mind. Looking forward for official release of your theme so I can test this aspect

Database collation issue: Heads up guys. New version of mysql/mariadb database are more strict regarding table collations. Error can be thrown when two tables with different charset/collations are used in one query. Unfortunately, this happens for revws automation (premium version) If your automation list is empty now, you are affected. The fix will be released in new version of the revws module. Until then, you can fix it yourself. Execute following sql commands: ALTER TABLE `PREFIX_revws_email` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE `PREFIX_revws_subscription` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; Just replace PREFIX with the correct prefix you are using (tb, ps, ...)

I don't use elasticsearch module in production, but I worked on it lately -- fixing some bugs, adding support for newer ES server, etc. It seemed to be working quite nicely, at least in my limited localhost installation.

Unfortunately crowdin integration is not yet fully automated. Currenty we have a tool that allows us to extract translations from core, themes, and modules. But this tool actually requires working instance of thirty bees, with all modules and themes installed, and export is a manual task. It's not easy to prepare and keep such environment, so we do this only for major release. There is a task item in our backlog regarding automation of this tedious manual task. Once finished, we will have on-the-fly integration between github -> crowdin.

Hi everyone, we have forked and adopted prestashop 1.6 watermark module. From now on we will maintain and extend this module, so if you have some requests or bug issues, don't hesitate to report them. The initial release 1.2.0 is slightly extended version of old ps watermark module. The differences are: watermark source images are no longer kept in watermark module folder, but uploaded to main /img/ directory. This prevents problems with watermark images being lost during module update webp support Important note: If you are currently using ps16 watermark module, please do manual module update -- download zip file and extract it over your existing /modules/watermark module. If you used automatic update, thirty bees would delete current module directory and replace it with new one, and you would loose watermark source image that is stored in module directory. In future, update from 1.2.0 to newer versions will be without issues, because images will be stored outside of the module directory Github repo https://github.com/thirtybees/watermark

There is product customization feature that could be used for this

Ouch, this is beautiful bug: https://github.com/thirtybees/thirtybees/issues/1355 To fix it, either update to bleeding edge, or edit file classes/Cart.php and on line 2398 change if (carrier::useProportionateTax()) { to if (Carrier::useProportionateTax()) {

Hard to tell what's wrong. You should enable debug mode, and then look what does the ajax response looks like. There might be some hints there

@SLiCK_303 could you give me access to your back office so I could investigate the issue further?

This ajax error without any details is most probably mixed http/https CORS issue. Basically, if you - have SSL enabled on your store but access your back office using http:// - have SSL disabled on your store, but access your back office using https:// then the browser can blocks ajax call, because of mixed http/https protocols. I have fixed this issue in core updater and will release a new version soon. Meanwhile, just ensure that you access admin via https:// if you have SSL enabled, or using http:// if you don't.

@Adik do you have override for class Configuration? If so, please consider if it's still needed

core folder is just a very, very small part of the thirty bees codebase. It's like 5%. If you want to update manually, you need to download thirtybees.zip file, and upload entire content to your store (with the exception of install/ directory). After you do this, you need to delete /cache/class_index.php and you should be able to access your system. It is not properly updated, though, as database changes were not applied automatically. You will have to use core updater to figure out what changes to database schema should be fixed

@musicmaster / @Mark thanks for the questions. I don't have time to answer right now, but I'll make sure to reserver some time for detailed explanation of both features later, sometimes during the weekend.