datakick

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.

The error makes it clear that database migration was not performed. This could happen either update process failed -- you confirmed this is not the case you have some override that blocks core updater to discover new database schema changes. This is the most likely case Check if you have override for Combination - check if file /override/classes/Combination.php exists. I bet it exists, and it contains something like public static $definition = [...] If that's the case, you will have to modify it to include the new changes from core.

Indeed. Looks like a bug in translation system, when $this->l() does not accept strings with quotes, only with single apostrophes. Oh my... The fix is here: https://github.com/thirtybees/tbcontactformrecipientfilter/commit/0318e7a56d261a21e92fc9960aff6ed3bd80b66d The fix of the actual bug (translation strings extraction in core) will be hopefully in next version.

You don't need to 🙂 the email address is entered on contact form, for non-logged in customers

yes, they should. Try to send customer message using email address with .ru email 🙂

There is a built in customer merge functionality exactly for this purpose

Indeed. I fixed this, you should see the other module as well now

list of modules is fetched from https://api.thirtybees.com/updates/modules/all.json Modules zip files locations are listed in the json file. Usually it's github, but some premium modules have different location.

As this is not a bug, I will not be releasing a new version to fix it. It is common that module template sometimes needs to be adjusted in order to work properly with your theme (or in this case with other module). You can simply edit file /modules/revws/views/templates/hook/home.tpl and change col-sm-12 to col-xs-12. Or, you could modify the template of the other module in a similar way.

The problem is that two templates, from different modules, use different bootstrap class. Bootstrap does not like this You need to choose which class you want (col-xs-12 or col-sm-12) and then edit and change one of the template