musicmaster

Does this also solve the double login phenomena that I see on a stable 1.4? The first time nothing happens and the second time i am in.

Fine. Keep your new keys. But then don't import customer tables from other shops.

The employee and the customer tables use the same encryption. So either you import them both from the old shop and use its Cookie and Rijndael keys or you create them both in the new shop.

That is not a problem

Yes, you can. But it is ridiculous. A typical shop has 200 tables. BTW: yesterday there was an update of Copy_shopdata

Please share the error message that you get. It may enable people on the forum to analyze your problem. You may change irrelevant parts of it that might identify the server.

When you have error 500 you should enable debug mode: https://www.prestashop.com/forums/topic/224525-how-to-turn-on-error-reporting-for-debug-information-blank-page-500-internal-server-error/

It looks like you are crossing the PS 1.6.0-1.6.1 barrier. In 1.6.0 the default has value 1 and the other value 0. In 1.6.1 (and TB) the NULL value is used instead of 0. That enables the system to make the field a unique key - what makes it imposible to have more than one default. NULLs are excepted from this unique requirement. However, zeroes do trigger duplicate key errors. You are likely to experience similar problems with pictures.

Did you copy the keys in Settings.inc.php?

When in Phpmyadmin I change utf8mb4_general_ci into utf8mb4_unicode_ci for the column I get a unique key error message. When I use Core Updater it doesn't show any reaction to my click on the "apply fix" button. When i look in the browser console I see that the system returned a "success" response. However, the warning is still in its list.

I am moving a shop from PS 1.6 to a new TB installation. When I try to copy the content of the ps_search_word table I get a duplicate key problem. The problem is related to the collation. In the old shop it was utf8_general_ci. In the new one it is utf8mb4_unicode_ci. The problem is to be in the unicode vs general part (copying to utf8mb4_general_ci works ok). As I understand it some data normalization is needed to solve this. But how do I do that?

Note also that the latest version supports generation of webp pictures. For big formats there are still some issues with transparent background - they will be solved soon.

Yes

I have in Prestools a function with which you can reduce the server error log so that each error message only is listed once (the most recent version). Maybe such a thing is an idea for Thirty Bees too?

Thank you for the fix. You have made a lot of changes. That makes it hard to understand the side effects and thus hard to copy.

SunnyToo has its own blockviewed_mod. However, when I look at the code it looks like they have the same implementation with as only difference that TB uses hookHeader and ST uses hookDisplayHeader.

This looks strange. The property "nav_last_visited_category" can only be found in the SunnyToo module stproductlinknav. De omschrijving van die module is "This module adds Next and Previous links on the product page." Maar die module heeft versie 1.0 en is in voorgaande jaren nooit een probleem geweest.

I was wrong. There is always just one product in the cookie. So there is no problem there. However, in the meantime I caught a cookie that is problematic. It looks like this: date_add|2021-12-27 17:40:23¤id_lang|1¤id_currency|1¤viewed|2005,1292,563,341,7534,414,2262,1974,1380,7041,409,3875,367,475,244,6043,3342,3573,1930,5861,367,6383,7668,6156,287,250,5899,3449,1316,3391,7386,370,2272,7526,732,1683,5917,5641,2151,384,1352,3330,7744,490,282,5847,1683,7380,7567,418,4312,4311,563,4520,1974,363,7663,336,5867,7666,184,879,3425,266,4353,7018,468,5966,6341,6367,2005,5528,490,2800,3330,7388,5561,2272,6374,3075,528,4385,2272,7383,7727,5917,3079,3622,3293,5867,3429,7679,7640,1683,3931,370,6486,303,1683,6067,3486,6485,7630,7881,6488,6414,3130,7630,6485,2005,6352,490,5918,7862,463,4462,2339,3342,7731,7431,5612,2339,4089,2800,328,7679,3130,7641,1683,384,382,1345,4321,5445,2367,401,329,6135,3109,302,357,6482,7427,5454,786,3477,2271,7384,4328,4317,4379,1694,3330,6134,543,2005,418,1683,6958,543,148,143,6344,4318,1153,4089,3198,7383,7630,6383,7017,7882,1329,5654,498,2266,3162,3028,3790,3671,1609,3429,382,367,397,6129,7017,414,1928,6041,4161,1991,3338,368,2005,4161,6041,397,1928,1961,2310,7897,4367,6488,4374,6390,5844,1860,543,6035,2257,5612,3942,6107,3520,3028,6096,6906,7879,7873,6131,2738,1351,6149,3155,427,6131,440,543,306,435,6058,7344,7383,1927,7231,145,7534,1341,2955,3276,3851,7872,5235,310,6043,6211,6119,543,1683,7643,3260,1860,3360,4405,1292,2005,610,1963,6140,6368,1108,7525,7888,692,5372,4399,2279,7525,7388,1694,7734,3939,1108,7679,578,692,514,3254,154,3342,3332,5507,3461,1683,6165,239,7872,7861,7635,3400,7886,3376,7111,1683,7731,543,5854,3380,7860,6180,7866,2299,2563,890,5612,7871,495,7872,7012,6134,6375,7871,214,606,2005,218,5836,3547,2256,7388,4129,1694,1868,156,6165,521,414,7640,2903,4386,1974,7004,7528,4129,4128¤nav_last_visited_category|150¤id_guest|7789982¤id_connections|6882358¤st_category_columns_nbr|2¤last_visited_category|34¤gaClientId|4Avfdcimq5uO¤id_cart|54602¤ga_cart|{"4129":{"id":"4129-1496","name":"chocoletter-deco-melk-220-gram","category":"chocoladeletters","brand":"","variant":"a","type":"typical","position":"0","quantity":1,"list":"cart","url":"","price":"6.38"}}¤checksum|3699172910 When encrypted this cookie takes 4168 bytes and causes the error message.

I had a short look at the content of a cookie and I was flabbergasted. Is it really necessary to story so much information? Here is my cookie (with some changes for privacy that don't change the length): date_add|2022-11-09 19:51:08¤id_lang|1¤id_currency|1¤id_guest|8484987¤id_connections|6812336¤viewed|4128,2595,4130,7073,4127,4074,4075,2686,2691,7513,4127,4126,4129,4128¤nav_last_visited_category|150¤id_compare|0¤id_customer|2422¤customer_lastname|Johnsson¤customer_firstname|Angel¤logged|1¤is_guest|¤passwd|$2y$10$rFACEsbXQnL.ysUP33X3k.TpGCvVuSJ2zxyRbABCDkl7VLsIpixvS¤email|[email protected]¤check_cgv|¤last_visited_category|150¤st_category_columns_nbr|2¤id_cart|53951¤checkedTOS|0¤ga_cart|{"4128":{"id":"4128-3893","name":"chocoletter-deco-puur-220-gram","category":"chocoladeletters","brand":"","variant":"a","type":"typical","position":"0","quantity":1,"list":"cart","url":"","price":"6.38"}}¤checksum|1611188096 This cookie is 716 positions long. After encryption that is 1481. This cookie contains just one product. That product takes nearly 200 positions. That would double with encryption and that would mean that with 13 more products I would cross the 4096 border. I am not sure whether this is my problem. But i find it puzzling.

Blowfish doesn't solve the problem.

When I look at my cookies with a cookie editor I see two cookies whose name starts with "thirtybees". One is 777 long and the other 1049. There are 6 other cookies but they are small. Yet when I look in Chrome's cookie overview it sees 9 cookies with a total size of 178 kb. However, this is in the main shop that has no problems. It is my php script that generates the error and I have no idea why. Is there some way to debug this?

I have a big problem that this year happens for the first time although the code is several years old. So it may be related to the TB update. I have an application where on the product page there is a button. When it is pressed it calls a php script in an iframe. The scripts adds one or more products in the desired way to the cart and then refreshes the page so that the updated cart is shown. The script is not particularly complicated. First it calls the TB with 'require("index.php");' and then it adds products to the cart with calls to '$cart->updateQty('. Previously this worked perfectly. Now it doesn't work for many people and when you look in the browser console why you see this error: set-cookie header is ignored in response from url https:/www.shop.com/addprod.php. The combined size of name and value must be less than or equal 4096 characters. The script doesn't contain code that interacts with the cookie. So it must happen somewhere in the Thirty Bees code - probably when a a product is added to the cart. What causes this error and how can I fix it?

CLeansing the cache might help for the megamenu issue. For the cart issue you should enable debug mode and then look in the network section of your browser console to see what message appears and is translated as "unable to delete". I could do the latter but for that I would need an url. https://www.prestashop.com/forums/topic/994407-how-to-debug-ajax-errors-jqxhr-unexpected-token-technical-error/

Did you look in the server's error log?

I have added that Paypal issue to the list too. But when the TB module works you won't have to worry about that.