the.rampage.rado

Are they really not sent or they end up in the junk folder? It happens to me from time to time and I think it's because of the information in the templates, some filter somewhere think these emails are spam but let's the test emails through (so I don't believe you have bad rep problem or you are blacklisted).

New owner, new spam bot... 😄

No issues for me when using apcu

If you are not VAT registered you don't have to charge VAT for any sale (UK, EU, outside-EU). I doubt something will change about that.

It's not a but, you can't edit whatever you want. If you want changes like that you have to make tweaks to your theme/module

This checkbox makes only the combination default. The order in which the images are shown is decided in the image upload window.

The guest account can be converted to registered user but it's not needed. If the user does not register an account with you he/she may not order from you again. If they do they can reenter all their data if the browser does not autopopulate it for them (rarely) so no need to turn off this feature imo.

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?