zod

Probably it is fixed with this: https://github.com/PrestaShop/PrestaShop/pull/33573 But i just updated to 8.1.2 because it has the fix, and did not break going from 8.0.4 to major release 8.1.2.

It is not caused by that, I am logged out. It is missing some required modules of the original Prestashop, and after further investigation, it seems both "PrestaShop Marketplace in your Back Office" and "Tips & Updates".

You use the wrong field, it is not "SKU" but "Reference".

I was going crazy with this, also the out_of_stock column in product table is useless, it never changes and it is not the correct parameter. In fact, out_of_stock is in the stock_available table!!! DAAAMN!!!

It seems that out_of_stock in product table doesn't apply, there is another out_of_stock in table stock_available that is the one used by Prestashop. I lost a lot of time to figure out this. Even modifying via Back Office, that is not clear, because the value never changes in product table. I cleared all and reimported using out_of_stock value 2, and all is fine now.

I had the same problem, the required module is not "PrestaShop Marketplace in your Back Office", but "Tips & Updates". I deactivated both for optimization, but i guess the latter is required to access the modules' repository.

I tested the solution here (as fresh install Prestashop 1.7.7.1) and it worked.

Stesso problema aggiornando da PS 1.7.6.8 a 1.7.7.1 7 tabelle con questo problema SQL 1.7.7.0 1709 in ALTER TABLE `smb_configuration` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Index column size too large. The maximum column size is 767 bytes. SQL 1.7.7.0 1709 in ALTER TABLE `smb_connections_source` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Index column size too large. The maximum column size is 767 bytes. SQL 1.7.7.0 1709 in ALTER TABLE `smb_customer` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Index column size too large. The maximum column size is 767 bytes. SQL 1.7.7.0 1709 in ALTER TABLE `smb_employee` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Index column size too large. The maximum column size is 767 bytes. SQL 1.7.7.0 1709 in ALTER TABLE `smb_order_state` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Index column size too large. The maximum column size is 767 bytes. SQL 1.7.7.0 1709 in ALTER TABLE `smb_page_type` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Index column size too large. The maximum column size is 767 bytes. SQL 1.7.7.0 1709 in ALTER TABLE `smb_smarty_cache` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci: Index column size too large. The maximum column size is 767 bytes. Ho provato a fare una installazione nuova, sempre 1.7.7.1, ha dato lo stesso problema, bloccandosi al 13%. Con errore: Errore SQL nella query Index column size too large. The maximum column size is 767 bytes. Ho risolto seguendo queste istruzioni, è sicuramente un bug che devono risolvere:

I prefere the inclusion via block because i could use the same javascript library in more than a single page. For example, I added Fancybox + a little init code, so, working with some "containers" with class "openfancy" it is a code like this: {block name='javascript_bottom' append} <script src="//code.jquery.com/jquery-3.3.1.min.js"></script> <link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/fancyapps/[email protected]/dist/jquery.fancybox.min.css" /> <script src="https://cdn.jsdelivr.net/gh/fancyapps/[email protected]/dist/jquery.fancybox.min.js"></script> <script> document.addEventListener("DOMContentLoaded", function (event) { $(".openfancy a").fancybox(); }); </script> {/block} Easy and effective.

Quello di cui stai parlando non è il funzionamento originale di Prestashop. Tu non vuoi un e-commerce, ma un Marketplace (Come Amazon, Ebay, Mano Mano ecc...), e per fare questo serve ben oltre un pagamento diversificato. Serve una interfaccia frontend attraverso cui gli artigiani si caricano i prodotti, si mettono sconti, trattano con i clienti, ricevono ordini, spediscono, cambiano status agli ordini... e certamente ricevono anche pagamenti. Ci sono temi e moduli specifici per fare questo, ma sinceramente non ne ho provato nemmeno uno, credo serva parecchio lavoro di messa a punto.

No, that way I think you fixed.

You shall not remove modules by FTP, never, because they are registered as installed and active in database. For this reason you have problems. Remove modules only by Prestashop Admin. I suggested to fix the bug modifying the culprit file, that easy fix should work. Previously, I suggested to replace the module with old version (download provided), and that works too, but a replace is different than deletetion, the module is running but with updated files. Now try to restore the folder in your Prestashop.

The table is ps_emailsubscription

In my case the shop is an old PS 1.6, and we want Geolocation just for starting point, to set language and country, to show some special product prices. If it fails it is no harm, it goes default. After all, when the customer is registered, it is his own address that rules the country. So, the geolocation can be the free database version, even if not accurate 100%, it is just a commodity. The real problem is that we don't want the original behaviour that Prestashop intended, we don't want it as filter that blocks anyone. We never use Prestashop configuration about countries, we want be online for everyone. So my bypass in the isInWhitelistForGeolocation method is good enough for my purpose, anyone is whitelist . Bye

Thank you! 1 hour wasted debugging and searching to finally discover this damn module with this damn option deactive!!! Why they did this in 1.7??? Who had the brilliant idea to deactive by default the email in the contact form???