datakick

That's weird. Your group 'Trusted Members' should have no quota for messenger: Maybe some cache issue, or something like that. I've flushed and regenerated members statistics, maybe that will help. If not, let me know, I'll raise an issue on forum software github.

Third party module issue - missing table. Either the module was not properly installed, or it's a bug in the module.

sorry, the lines range to delete is 98 - 104

As @the.rampage.rado wrote, you can install tb1.5 using custom target functionality. However, it doesn't make much sense to do that. There were a lot of bug fixes and security issues fixed since 1.5. Since you are already updating your store, you should migrate directly to newest version. There is no guarantee that you would not experienced similar 'compatibility' issues with modules on 1.5 as well. You will have to fixed them eventually, so why not now. Also, when you run older version of thirty bees, you will not be able to update some modules to newest versions. For example, custompayments v1.3.0 requires thirty bees 1.6.0, and there are other modules as well. You can still use older versions of those module, of course.

Delete lines 74 ... 104, and replace them with $this->_is_mobile = Context::getContext()->isMobile();

1) you have to check permissions for directory /modules/ and all it's subdirectories, recursively -- there may be some directory deep in the directory tree that doesn't have proper permissions 2) check ownership of the directories / files. Permission 755 means that only owner can write. Maybe some directory is owned by different user -- it needs to be owned by the user used by your php process.

I'm afraid this is won't work. You can create conditions for order object, not for order products. The condition would have to be something like 'Order contains products from manufacturer XXX', and that's too complicated to implement. But I believe you can achieve the desired outcome using build-in Cart Rules. leave cart rule 'Code' empty so it is applied automatically in condition, set product restriction like this and in action, use 'Send a free gift' Should work out of the box

Conditions are specific to used trigger. What trigger are you using, and what action do you want to perform?

This is not 100% completed functionality -- it can be used perfectly fine, and it is being used by core, but there is still a piece missing that can make this very useful. There are couple of main use cases for this workqueue system: execute some task in isolation, and potentially in different thread/process defer execution of task for some time execute some task on regular basis (cronjob replacement) There are a lot of tasks in the core/modules that we want to be executed, but we don't really care about the result, or even when exactly the task finishes. A few examples: generate image thumbnails for a product sending email Currently, when we call Mail::send() method, the system is trying to synchronously deliver an email to smtp server. This can take a lot of time, and delays page response time. Order confirmation page can take few seconds to display because of this. Work queue system can help with this. We can describe the 'Send email task', and pass it to work queue system to execute it later, and the original process can continue its work. The email will be eventually sent, depending on the workqueue executor implementation. Unfortunately, currently exists only one Work Queue Executor implementation -- immediate executor. This implementation executes the task immediately, synchronously -- so there is no real benefits. We have plans are to implement different executors stand alone executor - there would be a dedicated worker process(es) that run as a cli php application (maybe even on different servers). The task would be serialized, saved in some queue (db, redis,...), end workers would pick it up and execute them. This is most advanced, most complicated, but also provides the most benefits cron-based executor -- tasks would be serialized and saved somewhere (db, redis), and executed on periodical cron events (every minute or so, for example) end-of-process executor -- the task would be executed in the same process that it initialized, but at different time. Instead of execute the task immediately, it would be executed after the response has been sent to browser, just before script end It would be up to store owner to decide, and set up, which executor they want to use. I'm currently running a variant of stand-alone executor on my site. It's not a complete solution, just a proof of concept, but it works quite nicely. But back to your question. To use this system, you need to Implement WorkQueueTaskCallable class. The execute method accepts $parameters. It can be anything, but it's a good idea to somehow encapsulate the shape of that parameters. Example task that generates image thumbnails/types can look like this: class GeneratImageTypesForImageTask implements WorkQueueTaskCallable { static function createTask(Image $image): WorkQueueTask { $parameters = [ 'imageId' => (int)$image->id ]; return WorkQueueTask::createTask( GenerateImageForProductTask::class, $parameters, WorkQueueContext::fromContext(Context::getContext()) ); } public function execute(WorkQueueContext $context, array $parameters) { $image = new Image((int)$parameters['imageId']); // ... todo - generate all image types for this image } } To execute this task, somewhe in core/module you need to get instance of WorkQueueClient, and enqueue the task: //... $image = new Image((int)$parameters['imageId']); $workQueueClient = ServiceLocator::getInstance()->getWorkQueueClient(); $workQueueClient->enqueue(GeneratImageTypesForImageTask::createTask($image)); And that's it. If you want to schedule execution of the task, you can create a Scheduled Task and save it to database. $payload property of scheduled task is passed as $parameters to callable.

I don't really know, you will have to test and let us know 🙂 I never used APCu in production, only on dev site. I don't like the idea that cache is part of the php process, I prefer standalone caching solution (redis for me)

Did your server used all those 32M of the cache memory? It's possible that it will allocate another segment only when your are running out of the memory

This is correct behaviour. The cache is being enabled selectively only when the module requests this (by providing $cacheId parameter to isCached / display methods) If we were to enable caching globally, then it would basically do the full-page cache functionality. That's not what we want, because we don't have an option to invalidate the cache entries when something changes. Full Page Cache tries to solve this problem it tries to determine when to invalidate page cache entry depending on page entity id (when cached entity is changed, PageCache::invalidateEntity is called, flushing all related cache entires) it punches holes for dynamic hooks These both operations are not perfect, and do not work in 100% of cases. That's why it's not really recommended to use FPC on most sites. But it is still much better solution then to enable smarty cache globally for all templates. That would be an absolute disaster.

Note: immediately after the cache is cleared, I also get empty data. But after I load front office, the apcu_cache_info returns correct information.

I don't have that module installed, and it works

Yes, that looks strange. On my testing site, the result looks something like this: Array ( [num_slots] => 4099 [ttl] => 0 [num_hits] => 159 [num_misses] => 38 [num_inserts] => 19 [num_entries] => 9 [expunges] => 0 [start_time] => 1733902049 [mem_size] => 56488 [memory_type] => mmap [cache_list] => Array ( [0] => Array ( [info] => smarty~themes/niara/modules/blocksearch/blocksearch-top.tpl~blocksearch-top|1|1|1|1|8 [ttl] => 31536000 [num_hits] => 21 [mtime] => 1733902049 [creation_time] => 1733902049 [deletion_time] => 0 [access_time] => 1733902266 [ref_count] => 0 [mem_size] => 1792 ) ) ) Looks like your server is not using the case. Did you set "Smarty caching type" to "Server side cache"? Note that all these settings are multistore, so check that as well.