Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


Popular Content

Showing content with the highest reputation on 11/07/2021 in all areas

  1. 3 points
    On top of my head here's the most pressing issue with TB that can be fixed with this solution - order finalizing. When customer clicks on "Confirm my order" it usually takes up to 5-10 seconds to refresh the page. In the meantime emails are sent, order is made, etc. This mechanism could potentially reduce the time in this vital step and improve UX. I had numerous questions about this issue from inpatient clients clicking numerous time or even 'having issues on the last step'....
  2. 2 points
    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.
  3. 1 point
    Hello all, I am curently working on a Bootstrap 5 theme for Thirtybees and would like to share it with the community at least for the basic version. I need your help in order to finish it, while completing this task I'd like that you can report here the good and the bad things about the theme, so i can fix it or improve it and ask for new testing before I put it on github and manage it on that platform, as it's way more easy for me to do it here for start. And here is the admin back office that can let you use the ThemeMaster module, that will help you to customize your own design, it's very first version and don't hesitate to ask for things to manage from this module : https://cisero.zengraph.com/admin007/ user: demo@demo.com pass: demodemo So let's start it, I hope to finish it before january 2022, it also depends on your returns. PS: I am sure many pages still need to be done, you can list it on your post and I'll update it here and this first message. =================== Known bugs to be fixed ================== ... ... ...
  • Create New...