the.rampage.rado

Both systems use different type of hashing the passwords so the "old" system passwords will never give the proper "answer" to the new system when they try to log in so they will receive the "wrong pass" message. But if you have logged in before and now you're not able to do probably this is separate errror. Try clearing all caches and try logging in in incognito mode (or different browser).

Give us link to work with. With this screenshot we are not able to grasp what module or where it is hooked...

Very highly doubt this is related. As I advised you should have created backup of your DB. Now after the fixes - create backup of the after situation and restore your old one to check if this spinning button is fixed. If not you can restore the after situation and continue with the fixes while you search for solution to this issue.

Hi there I would like to post this here as I lost couple of hours yesterday trying to identify the issue with my oldest shop and because of it's nature (migrated from PS, etc) I would like to have a discussion here and find if this applies to current TB installations aswell. Years ago I had few categories like 'Basketballs' in my shop. They were long gone because I made new shop for this and other sports and left the current one with just one sport. Because I would like to reintroduce other brands selling basketball and other ball sports I had to make new category Basketball and then under it Basketballs. When I added products there the breadcrumbs in my front shop were all messed up. Instead of Home>Basketball>Basketballs there were other old deleted categories in there, one of which was Basketballs also, something like: Home>Basketball>old_category>other_oldcategory>Basketballs>Basketballs The issue is that because of the new TB category SEO URLs w/o ID in them the system picks the oldes SEO URL that matches and puts it in the navigation (with it's parent category). First of all I was - WTF!? The issue is gone after I manually deleted the old categories from DB from ps_category_lang (they should be deleted from other tables as well but I've lost the IDs and it's working now, so I'm not bothered). The old deleted categories were not showing in the category tree structure in BO. I have a brand new TB demo instalation and now I'll try to reproduce the issue there as well. EDIT: the TB demo with the latest updates behaves normally and deletes the category from all tables. So this issue should be because of the migration from PS or even before that. Can somebody with migrated old shop as mine make this test and search for the deleted category in ps_category_lang (and the other category tables) so we can find out if this can be reproduced?

Yes, I found out that if you make 2 instances in 2 windows side by side and start from different points in the list it's nearly twice faster. No automated way to apply all of them currently and probably there won't be one as some fixes rely on other to complete. 30 minutes - 1 hour of 'work' for 1000 fixes.

Backup your DB and apply all of them. Nothing should change in your FO or BO. One (or few of them) may not get fixed with the button because of bug in the module which was identified and will be fixed in the next release. You can find my thread in the forum with the same question and the solution to this issue.

The magic of TB - it always has white background... 😄 I imagine your Niara has dark background color and you want your product to be visible with transpartent background?

Great! Thank you onem ore time @datakick ! Perfect as always! Can we expect the same amount of differences in other tables aswell? (in this one -4 rows)

SHOW CREATE TABLE ps_page_cache ps_page_cache CREATE TABLE `ps_page_cache` ( `id_page_cache` int(11) unsigned NOT NULL AUTO_INCREMENT, `cache_hash` char(32) COLLATE utf8mb4_unicode_ci NOT NULL, `id_currency` int(11) unsigned DEFAULT NULL, `id_language` int(11) unsigned DEFAULT NULL, `id_country` int(11) unsigned DEFAULT NULL, `id_shop` int(11) unsigned DEFAULT NULL, `cache` text COLLATE utf8mb4_unicode_ci NOT NULL, `cache_size` int(10) unsigned DEFAULT NULL, `entity_type` varchar(12) COLLATE utf8mb4_unicode_ci NOT NULL, `id_entity` int(11) unsigned DEFAULT NULL, PRIMARY KEY (`id_page_cache`), KEY `cache_hash` (`cache_hash`), KEY `id_currency` (`id_currency`), KEY `id_language` (`id_language`), KEY `id_country` (`id_country`), KEY `id_shop` (`id_shop`), KEY `id_entity` (`id_entity`), KEY `entity_type` (`entity_type`), KEY `cache_combo` (`cache_hash`,`id_currency`,`id_language`,`id_country`,`id_shop`) ) ENGINE=InnoDB AUTO_INCREMENT=2451 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

And here's the table structure:

I don't know if this is of any help?

Different primary key in table ps_page_cache Does not want to fix itself. What does it do and what I can do about fixing it? :) 50 minutes later, on 2 devices ..... so far - no observable change...

I'll start to do them... :) 992 fixes in just one of the shops... :)

OK, thanks @Traumflug! What about the encoding? Can some characters get corrupted (I'm using Cyrillic mostly).

How safe is to apply the fixes there? I have 3 shops on TB, 2 of them I've updated recently to edge and the schema check is working again. This time there are lots and lots of 'fixes' most of them are size related: Column ps_access.id_profile has data type int(10) unsigned instead of int(11) unsigned But some of them offer to change the encoding: Table ps_store should use character set utf8mb4/utf8mb4_unicode_ci instead of utf8/utf8_general_ci And some of them I don't even know what they do: Column ps_product_attribute.ecotax has data type decimal(17,6) instead of decimal(20,6) The most conserning things are the encoding related. As far as I read the proposed one is better but could there be some some data corruption if I apply those fixes? (backups are always made, no need to advise on that :) )

Did you try switching mainenance on and off again? Did you try debug mode?

Give us a link.

If you change themes few more times it can get even 'prettier'... First of all - what you changed before maintanence? Surely it can't be just taxes. Second - after changing themes they do some minor adjustments that we don't need when debugging this issue - do you have recen backup you can revert to? If not does your host make daily incremental backups that you can use?

That's strange! Can you have some other override from prior captcha modules?

Can you screenshot the settings of the module?

Do you have the latest version of recaptcha? Because all of them except the latest one had this bug where the user/bot did not need to check the box if BO settings of the module if you use the 'Login atempts' (it has to be 0) The working version is 1.1.2. If you have it but it's still not working - please uninstall and delete the module folder (if present) then reinstall. It stopped all spam from contact forms in all of my TB sites.

Yes and if you don't want your theme to show Accessories in front page you can change this string to something else. If you like you can add 'Same category slider' if you want to show this automatically with no human touch.

If you have removed the product from BO (in contrast to disabling it) you can use .htaccess redirect to 301 redirect the old nonfunctioning address to something similar or to category page where it was located. Alternative is to redirect to homepage. If the product is disabled but present in BO you can make the redirect from product page. This is better(ish) for SEO and better for user experience.

Yes, sorry we were playing around :) As for today - TB does not support PHP7.4

OK, keep us updated if we can help with anything else 😉