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.