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.

Install collectlogs module

You need to figure out why the db migration failed. Look into collectlogs, or your server error logs, for more info.

Dirty fix is to edit file override/classes/Hook.php and add following line at the beginning of the class: protected static $_hook_modules_cache_exec = null; Proper fix is to investigate why this override exists in the first place, extract the "reason", and apply it to current codebase version of the overridden method. Otherwise thy system may nit work correctly

There should be no "vicious circle". You are supposed to update from php7.4 to php8 only **after** you have fixed all warnings. You can't update before that. While you are on php7.4, all future errors are displayed in collectlogs module as warnings.

That's true, but after payment completed, the module still needs to process the payment. Payment providers usually maintain some php library that can be used to access and process data from their API. And those libraries are not PHP 7.4 compatible. PHP 7.4 is dead. If you are still using it, you will face more and more problems in the future. For example, you won't be able to use to new versions of stripe or paypal module, and ultimately the old versions will stop working after the api endpoints are closes. If everything works properly on PHP7.4 now, it's the ideal time to slowly fix PHP8 issues on your store, and prepare for update.

If you are running on php8.1, then you had different issue that the one fixed in bleeding edge. Trialing commas are supported since php 8.0

If your store runs on PHP7.4 without errors, you can indeed continue running it on that version. But you should definitely strive for higher PHP version compatibility, and update version once you achieve it. There is no good reason not to do so -- newer versions of PHP are faster, more efficient, and more secure. And of course, you will be able to use modules that are compatible with newer versions of PHP only. For example, I'm not writing new module that implements digital invoices functionality, and because of the library this module uses the minimal supported PHP version will be 8.1. It's not hard, and quite safe, to achieve higher php compatibility. PHP never introduces a breaking change out of the blue. They raise WARNING / DEPRECATIONS in previous version, and introduce breaking change in the next one. We have a great tool named collectlogs to handle those warnings. So the process is: install collectlogs module wait for a while, allow the module to collect deprecation warnings look at the warnings, and fix them rinse and repeat once your store does not generate any warnings for a while, you can safely update your php version Note: some (well, sometimes a lot) warnings are not caused by php native methods, but by libraries / core itself. These warns you about upcoming breaking changes in the library / core itself, not about PHP breaking changes. You can ignore these for the time being, as they have no impact on PHP update. Example of such warning: Note 2: if unsure how to handle fixing the issues, you can always hire some dev do to that for you. In my experience, most stores can be 'fixed' in 2-4 hours, as the fixes are usually trivial. Note 3: there are a lot of fixes described on a forum, especially fixes for themes. Most themes are very similar, so you can apply the same fix to your theme without changes. Note 4: you can also look into niara / community theme github history, to find out how some problem was fixed in that theme. For example, if collects logs tells you there is an issue with breadcrumb.tpl, you can go to https://github.com/thirtybees/niara/ , open breadcrumb.tpl file, and look at the history: https://github.com/thirtybees/niara/commits/master/breadcrumb.tpl

Oh, bummer. Fixed in bleeding edge. Anyway, I strongly suggest everyone to move beyond PHP7.4 -- we can't keep compatibility forever.

Maybe you have enabled Disable non thirty bees modules option in Advanced Parameters > Performance? The name of this config option is stupid -- it means any module that is not installed by default

Then there must be some error during update. Are you sure update completed without errors? What about the exception that is raised when you open the Database tab? The same probably occurs during update. Look into your error logs and find out what is that about.