datakick

You should first look into source database ps_customer table and compare data with target db. SELECT id_customer, passwd FROM ps_customer ORDER BY id_customer LIMIT 10 Verify few customers. If the data are different, you can keep this conversation here, as it's a bug in the copy tool. If the data are the same, though, then the issue is somewhere else. You either didn't copied the _COOKIE_KEY_ and_COOKIE_IV_ settings from source to target server. Or maybe you used some sort of custom login functionality in your original server in the first place (maybe some auth module, or whatnot)

Of course you can. You just have to first update your thirty bees using coreupdater to PHP 7.4 build. There would be compile/syntax errors if you tried to run code that is using PHP8 syntax on PHP7. It's been discussed on this forum already. Try search.

This module is not PHP8 ready. https://github.com/thirtybees/nocaptcharecaptcha/issues/12

Update module to new version 2.2.4.

Did you check /themes/<theme>/modules/homeslider/homeslider.tpl override inside your theme, as described in one of the posts above?

Most likely caused by password column size -- it should be 60 chars long. You can use core updater database schema verification to find all database differences, and fix them.

Chex does not impact standard order flow. If module is enabled, it simply replace it. Since this is bug in standard OPC flow, I doubt that it has anything to do with the module.

This is how dashboard_zone_one.tpl looks in version module version 1.3.0: https://github.com/thirtybees/dashactivity/blob/master/views/templates/hook/dashboard_zone_one.tpl There is no reference to $allow_push. Please double check module version. If it's indeed 1.3.0, and the file looks the same as in the link, than it will be caching issue.

Looks like the same problem as @musicmasterencountered here: The problem will be with some module calling Link::getAdminLink with invalid paramter. I have added new check to the code: https://github.com/thirtybees/thirtybees/commit/125bc3039f5e4d6cb490288e073a751c50e29f9a If the method Link::getAdminLink is called with invalid parameter, system will raise warning instead of error. You can update to bleeding edge, the fix is already there. Note that you still have to fix the module, as in the future this will throw an error again.

can you show the stacktrace as well?

This does not look like an issue with chex. Once you enable chex, the order page is skipped, and user is redirected to module controller. This error comes from standard order controller.

Update dashactivity module to the latest version 1.3.0

That is not a fix, that's just code location that needs to be fixed.

your /img/ directory is probably not writeable, so module failed to create subdirectory homeslider inside it. You might need to create this subdirectory manually (via ftp, for example), and set correct permission for it

Did you update the module manually, or automatically? If automatically, all your existing images were wiped out. You will have to re-upload them, and they should be stored inside /img/homeslider directory (if it's writeable)

Known issue: https://github.com/thirtybees/thirtybees/issues/1292

I googled a little bit and it looks like the php8 version is more strict regarding email standards. Something about email sections being delimited by \r\n characters, but switftmailer library we are using for sending emails use \n as a delimiter. Or something like that. Unfortunately, we can't update switftmailer library, as it is no longer maintained. We have to migrate to new email sending library soon (swiftmailer is not PHP8.2 ready anyway), so this problem will be fixed together with it. Meanwhile you will have to use smtp transport if you are on PHP8

To determine locally modified files, core updater asks API sever for a list of files for some revision and PHP version. Unfortunately, previous versions of core updater did not remember PHP version the code base was build for, and always asked for PHP version currently in use. When you switched the PHP version to 8.1, core updater asked api server to send him list of files for revision 05affeeeb438431cc5582d671785b9ce3b9ca0a3 and php version 8.1. Unfortunately, this combination does not exist, because this revision was only build for php7.4 and lower (that version does not officially supports PHP8). There are multiple fixes. 1) downgrade your php version to 7.4 (or whatever you were using before), and then update to bleeding edge. Then you can upgrade php version to 8.1 and update again. 2) alternatively, you can edit your settings.inc.php file, and add entry define('_TB_BUILD_PHP_', '7.4'); This will tell core updater that he should ask for combination 05affeeeb438431cc5582d671785b9ce3b9ca0a3 and php 7.4 Note that new versions of core updater saves information about PHP version the code base was designed for during update, so this problem will not occur in the future. Once you update, this _TB_BUILD_PHP_ constant in settings.inc.php will be created/updated by core updater automatically.

Oh dear, that's a serious issue. Will have to fix that in core updater. Meanwhile, you can do this: download new version of truststore from here: https://raw.githubusercontent.com/thirtybees/thirtybees/main/tools/cacert.pem or from here: cacert.pem and save it inside your thirty bees /tools/cacert.pem . There should already be this file, so just overwrite it.

In core updater settings page, set Verify SSL certificate to 'Disable SSL verification'

This looks like misconfiguration of image types and/or theme. Your 'home' image type has size 129x129 pixels. However, your theme renders this image in a space 197x197. You need to either modify your theme to reflect the image size, or change image size and regenerate images.

Download latest version of coreupdater: https://github.com/thirtybees/coreupdater/releases/download/1.6.1/coreupdater-v1.6.1.zip It comes with its own (and updated) truststore, so it should fix your problem

Also, @musicmaster, could you send me the sql script to populate this ps_search_word so I can try to reproduce this issue, and test how coreupdater handles the situation?

Not sure. You can try to select/group from the table with collation, that should show you offending words that map into the same key in utf8mb4_unicode_ci, but not in utf8mb4_general_ci SELECT id_shop, id_lang, `word` COLLATE utf8mb4_unicode_ci, COUNT(*), GROUP_CONCAT(id_word) as duplicate_ids FROM ps_search_word GROUP BY id_shop, id_lang, `word` COLLATE utf8mb4_unicode_ci HAVING COUNT(*) > 1;

How about restoring data to utf8mb4_general_ci, and then convert table to utf8mb4_unicode_ci (using core updater or manually)?