datakick

This has been fixed. If anyone is interested what went on, here's s summary. Thirtybees contains vendor directory that have third party libraries that core depend on. We need smarty template engine to render templates, guzzle http client to send http requests to api server, tcpdf library to generate pdf, and others. These dependencies causes few problems some libraries have different implementaions for different PHP versions -- that's the reason why we have different PHP builds. We can do that as long as the library interface remains the same by having these libraries in the core vendor directory, they are autoloaded first. This can cause conflicts with modules In this particular case, we updated library mobiledetect/mobiledetectlib to latest version 4.8.09. That versions depends on yet another library psr/cache version 3.0. Previous versions of this library did not have this dependency. After update, core vendor directory contained psr/cache version 3. Unfortunately, a lot of modules (for example mollie) also uses this library, and have it in their respective vendor directory (modules/mollie/vendor). But because this library is already loaded by core, it will not be loaded from module vendor. If the module uses different version of library, than things can go bad very quickly. And that's what happened here - mollie requires psr/cache v1, but got psr/cache v3, and PHP raised exception. The fix was for us to remove the original library mobiledetect/mobiledetectlib from core -- it was replaced by library module tbdetectmobile. Now, this is not the complete fix, because there is still a compatibility problems between tbdetectmobile and mollie module -- both modules can't be installed at once. But at least it's not conflict between core and mollie module. We have released the tbdetectmobile module in different versions, that you can choose from very old version for PHP7.4 - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.0.0 version for php8 that does not have dependency on psr/cache - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.1.0 version for php8 that have dependency on psr/cache - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.2.0 If you have a module that depends on psr/cache v1, you can't use tbdetectmobile v1.2, but you can use tbdetectmobile v1.1 It's a mess, I know, but it's the best solution I could found. In the future, we will release another version of tbdetectmobile that will change namespace of library dependencies, so it does not pollute global namespace. With that in place, the module will work correctly even if there is another module that have its own version of psr/cache library. Until that is done, you need to manually choose the correct version of the this module to use. It would be great if all modules did that -- but we can't really force that on third party modules. Side note: the mobile detection is used by core for two things only: to display mobile theme variant. As far as I know, almost none of the themes support this -- there needs to be a /mobile/ directory inside your theme that contains overrides for themes. If this directory exists, then thirty bees will use templates from this directory when request comes from mobile device. to disable some modules on mobiles/tables: Some third party modules might also depend on mobile detection. But, generally speaking, if you don't use these features, then you don't have a need for device detection, and you don't have to install the tbdetectmobile at all. Without this module, the response will be always identical for mobiles, tables, and desktop. With this module installed, the response can be different.

It's very hard to fix something that dev can't reproduce. At that point, it's just a guesswork. If anyone can provide a reprosteps, I'd be happy to device fix. I could try to come with fix blindly. But you know, it's not optimal. We could spend hours to refactor the way this module handles the response, which is a dangerous task. It could introduce new bugs or issues, and there is no guarantee that that work would fix the problem at hand. So the motivation is not really there.

yes, you should. At the moment it's not critical, this requirement is for future features. But it's better to be prepared

Since this is a bug in core, module update won't help. @jnsgioia this is fixed in bleeding edge. You can try to update your store, and retest

Hi, can you post the stacktrace from the error message? This does not look like a bug in module, but like a bug in the core.

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.