datakick

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

No, "Block Facebook Share" works only on product page. It should be simple enough to modify the module to work with cms hooks (displayCMSTop or displayCMSBelow), as the module does almost nothing. You should register selected hook in install section implement hook handler hookDisplayCMSTop -- almost copy of existing hook, only different way to resolve url for cms page

That's hard to tell, it depends on what modules you are using. For example, I've seen module thats send abandoned carts emails to raise 500 errors after the old carts were deleted. Some modules (for example my revws) uses guest table as a.persistent identifier to identify anonymous visitors (revws is using that to allow anonymous visitors to edit / delete their reviews. Pruning data from guests table will break this functionality). And there are more. To improve performance, on a clean installation without additional modules, it's safe to delete old carts (tb _cart, tb_cart_products, tb_cart_cart_rule,...) delete old entries from (tb_log) delete old visitor-related entires (tb_guests, tb_connections, tb_connections_source) prune tb_mail entries It can be hard to do that manually. There are modules that do that in a safe way on a regular basis.

Yes, it's safe

Indeed, the composer dependency of this module do not work properly with the composer dependencies inside core. We really need some way to have composer dependency isolated (to support different versions in every module). But that will be very hard task to implement. Meanwhile, I've released a new version of tbspreadsheetdatasource for thirty bees 1.6.0. Please update the module, and it should work again

The autoload directory is to add your custom css files, not for overriding existing css. But for css, that's usually what you want. Add your css rules that have higher priority, so browser will use it. For example, if the css rule you want to change look like this: .sf-menu { float: left; margin-bottom: 1em; } and you want to change margin-bottom, you can create css file that contains only change: .sf-menu { margin-bottom: 2em !important; } Browser will use all rules and merge them together. Because of !important keyword, the your custom value for margin will be used. So -- do not copy the original file, but only copy rules you want to change.