musicmaster

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|peterpan@gmail.com¤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.

That is the issue I mentioned here: add {$matches=[]} on line 30

If things are more stable under PHP 8.0, try working there to fix the problems before going to 8.1. When you can fix problems by just looking in the error log your webshop can keep running.

In small companies without stock management it is common that a delivery slip is printed, someone goes out to collect the order, finds that something is missing and then calls the customer to adapt the order. Some customers almost make a habit of calling with changes to an order they already placed. Those are quite major functionalities to delete. So I am in favor of at least keeping this functionality as a backoffice option that can be switched on.

1. Make sure you have the latest version of Thirty Bees and the modules Why bother with error messages that are solved in later versions? 2. Make the fixes under PHP 7.4 The show-stopping errors under PHP 8.1 are warnings under PHP 7.4. So it is much easier to fix them there. You just need to take the trouble to look in the error log of the server. Don't be lazy and fix all the problems that you find here. The worst that can happen this way is that your site is one minute offline when you upload a fix with a syntax error. And that can always be fixed quickly by going back to the original. Even PHP 8.0 is less strict than 8.1. So use that if you aren't allowed to go back to 7.4. After you switch to a lower PHP version you should empty the cache. 3. Smarty compiled files can be read Smarty "compiles" the template (".tpl") files into a kind of php files that can be found under the /cache/smarty/compile directory. The errors happen in this compiled version. For example: /cache/smarty/compile/fe/8c/6b/fe1_0.file.breadcrumb.tpl.php When you open such files in a text editor you will see that they are rather lightly processed versions of the original (in this case breadcrumb.tpl). At the top of such a file you will find a link to the original file. In this case the original is rather obvious, but note that their is no path in the compiled file name. So when you have an error in for example "view.tpl" you really need to look at the top of this compiled file to see the source. Next there is the line number. The line number in this compiled file is not the same as that in the original tpl file. Often it works to subtract 2 from the number (the compiled files have an extra header of two lines). If not you will have to use your creativity. search for variable names and other characteristic text to find the problematic line. 4. Look what Thirty Bees did Themes are very similar. So there is a good chance that Thirty Bees encountered the same problems that you see with your theme and solved them. So if you are not sure how to solve a bug you can have a look at the same file in the Niara or the Community Theme theme and look how it was solved there. 5. Look how I solved it for Panda In this post you will find how I solved it for Panda. It provides some explanation about what the problems are and how they are solved.