El Patron

La sortie de PrestaShop 9 a malheureusement été un désastre en termes de gestion de version. La version 9.0.0 a été présentée comme la version « actuelle » à télécharger, ce qui a donné aux nouveaux administrateurs — ainsi qu’aux marchands existants — l’impression qu’il était sûr d’installer ou de mettre à jour, alors que ce n’était clairement pas le cas. S’appuyer sur la communauté pour tester une version majeure sur des boutiques en production est un très mauvais modèle, et de nombreux marchands en ont subi les conséquences. Espérons qu’avec la nouvelle direction de PrestaShop, cette mauvaise pratique cessera et que les futures versions majeures ne seront plus mises en avant comme étant prêtes pour la production avant de l’être réellement. Ce n’est qu’avec la version bêta de PrestaShop 9.1 que PrestaShop a clairement indiqué qu’elle n’est pas destinée aux administrateurs “classiques” et non techniques, ni à une mise à jour de boutiques en production. Tant qu’une version 9.x réellement stable n’existe pas, PrestaShop 9 doit être évité en production, en particulier par les utilisateurs non techniques.

Hi sorry this happened to you, it's stressful for sure. In future always make updates to a staging copy (a subdomain for example) to test change before considering moving to production. Did you contact the theme developer for assistance? Also I can replicate the issue from the front office. A 508 does not happen “randomly.” It means something exceeded a resource cap and the host intervened. The logs will tell you what process triggered it and the host can tell you which limit stopped it. Until those two pieces of information are reviewed, everything else is speculation. It's very important you collect information form the hosting error log and that your hosting tell you exactly what was exceeded. If they say it did not then they basically did not do their homework. The lazy people will be replaced by AI. At this point, the most important step is to review the server error logs at the exact time the 508 occurs. Please check: PHP error log Webserver error log (Apache / Nginx) Look specifically for: Allowed memory size exhausted Maximum execution time exceeded Fatal PHP errors Repeating errors or the same endpoint being logged multiple times (often back-office AJAX calls)

as I mentioned above, you will need to make other changes, this should not be a surprise now. It's best you open your own topic to get help rather than using others post.

Bonjour, C’est encore un problème courant avec PrestaShop Checkout. D’après mon expérience, ce module pose des soucis récurrents depuis des années : moyens de paiement qui ne s’affichent pas, erreurs de configuration comme « Config is not set », problèmes de synchronisation avec PayPal ou Stripe, etc. Je recommande de désactiver puis désinstaller complètement PrestaShop Checkout. À la place, utilisez les modules de paiement natifs et indépendants, beaucoup plus stables et plus simples à maintenir : Module officiel Stripe (paiement par carte bancaire) Module officiel PayPal Ces deux modules sont gratuits sur PrestaShop Addons et s’intègrent directement au tunnel de commande natif, sans la couche supplémentaire introduite par PrestaShop Checkout. Dans la majorité des cas, le simple fait de supprimer PrestaShop Checkout et de revenir au fonctionnement natif permet de résoudre immédiatement ce type de problème. Bonne journée, Fred

What the error means o Your shop is running PrestaShop 1.7.2.1 + PHP 7.0 o Your database server is MySQL 8.x (often via ProxySQL on port 6033) o MySQL 8 defaults users to caching_sha2_password o PHP 7.0 cannot authenticate with that plugin o Result: Back Office pages that rely on PDO/Doctrine (Catalog, Modules, etc.) throw 500 errors This explains why parts of the Front Office may still load while major Back Office sections are missing or broken. Immediate fix (fastest) Option 1 – change the existing DB user auth plugin o Ask your host to switch the DB user to mysql_native_password o If the username and password stay the same, no PrestaShop change is required o If the password changes, update it in PrestaShop CLI example (host or root access): o ALTER USER 'db_user'@'%' IDENTIFIED WITH mysql_native_password BY 'new_password'; o FLUSH PRIVILEGES; Same fix via phpMyAdmin (if you have access) Log in to phpMyAdmin Go to User accounts Click Edit privileges on the DB user used by PrestaShop Click Change password Re-enter the password and ensure authentication is set to mysql_native_password Save (Some hosts expose the auth plugin selector directly; others apply it automatically when resetting the password.) Option 2 – create a new DB user o Create a new user using mysql_native_password o Grant it full privileges on the PrestaShop database o Update PrestaShop to use the new DB credentials Where to update PrestaShop (only if needed) o /app/config/parameters.php (PrestaShop 1.7) database_user database_password host / port (if changed) What to confirm with your host o Are you connecting through ProxySQL (port 6033) or directly to MySQL? o What authentication plugin is assigned to the DB user used by PrestaShop? o Can they switch that user (or create a new one) using mysql_native_password? Root cause (important) o PrestaShop 1.7.2.1 and PHP 7.0 are long end-of-life o They are increasingly incompatible with modern MySQL defaults o This will keep happening unless: the DB engine is aligned to legacy compatibility (e.g. MariaDB), or the shop is upgraded to a supported PrestaShop + PHP stack This is a server compatibility issue, not a module or PrestaShop bug. and now the rant: Note to whom it may concern When selecting hosting, it is critical that you control PHP and MySQL versioning. Many issues like this are not caused by PrestaShop itself, but by hosting providers that: o upgrade PHP or MySQL automatically o do not check what applications are hosted o provide no warning before breaking compatibility This is why using a hosting environment where you explicitly control PHP and MySQL versions is essential. A control panel such as Plesk makes this straightforward and prevents surprises. Without that level of control, many users eventually discover their hosting “suddenly broke” after an upgrade they did not request or approve. In short: hosting choices matter, especially for legacy or long-running PrestaShop installations.

Temporary workaround (if you cannot upgrade immediately) This is a known bug in PrestaShop 9.0.2, not a configuration issue. The back office State form sends country_id as a string, but the core command expects an integer, which causes the fatal error when adding or editing states. You can apply a temporary core patch until you upgrade. o File to edit: /src/Core/Form/IdentifiableObject/DataHandler/StateFormDataHandler.php o Find the code that creates AddStateCommand (or EditStateCommand), similar to: new AddStateCommand( $data['country_id'], $data['iso_code'], $data['name'], $data['enabled'] ); o Fix by casting country_id to int: $countryId = (int) $data['country_id']; new AddStateCommand( $countryId, $data['iso_code'], $data['name'], $data['enabled'] ); o Clear cache after the change: Advanced Parameters → Performance → Clear cache (or delete /var/cache/*)

maybe this helps, also always post the exact prestashop version and php version. How to check if the Experimental Product Page is enabled In the Back Office, go to: Advanced Parameters → New & Experimental Features Look for: New Product Page (or similar wording) If it is enabled, you are using the experimental Symfony product editor How to disable it (recommended for stability) To revert to the stable, legacy product page: Go to: Advanced Parameters → New & Experimental Features Disable: New / Experimental Product Page Save Clear cache: o Back Office: Advanced Parameters → Performance → Clear cache o Or manually delete /var/cache/* on the server Log out and log back into the Back Office After this, product editing and duplication will use the legacy product controller, which is significantly more stable and does not suffer from the endless-clone issue.

If you view the page source, you’ll see that links on forum topics are marked as nofollow. This is a hint to search engines not to pass ranking value (and often not to index the linked content, although they sometimes still do). Because of this, it’s usually better to search outside the PrestaShop forum if you’re looking for broader or more complete results. AI tools can also be helpful, as they often surface relevant PrestaShop GitHub issues, which tend to contain much more useful technical detail. You can do the same with regular Google or other search engines by explicitly including terms like: PrestaShop GitHub issue or PrestaShop GitHub question.

Hi, 30 bees cloned prestashop 1.6 so you use migration pro, see addons, it 'should' work. Moving forward, wait for 9.1 of PrestaShop or ps8.2.3

good luck

perfect, I have moved many clients to fast host uk, even in US as they have different centers you can choose. for vps, these all have nvme, the last two I recommend, it's like a fish tank you wish you had gotten larger. on. https://www.fasthosts.co.uk/virtual-private-servers for dedicated (recommended if you have a budget and don't share will with others) https://www.fasthosts.co.uk/dedicated-servers screen shot of our hosting move project template https://app.screencast.com/twVwYk6W0MEfQ Export Data From Back Office (Only What Is Allowed) On PrestaShop Hosted you do not have: FTP / SFTP phpMyAdmin SQL tools Database dumps File system access You can only export data via the Back Office using CSV: Categories Products Customers Orders Addresses Discounts (limited) This is the only data you can take with you. Install a Clean PrestaShop on New Hosting (on temporary domain, they are cheap) On the new hosting provider: Install a fresh PrestaShop (same or newer major version) Configure PHP, memory, cron, mail, SSL Do not attempt to “clone” Hosted — it is not possible Import Data in the Correct Order Using the CSV files: Categories Products Customers Orders Discounts / rules Notes: IDs will not match the Hosted store Because PrestaShop Hosted does not give you access to the original database or its auto-increment counters, and the new store necessarily creates its own records from scratch. An experienced person/agency it's possible to match but it beyond scope of what I can describe here. Order history is informational (not transactional) Customer passwords usually carry over, but should be tested Rebuild Everything Else Manually The following cannot be exported from Hosted and must be rebuilt: Theme Modules Module configuration Payment gateways Shipping rules Taxes SEO URLs (partial recovery only) Email templates Performance configuration Custom logic possibly inventory This is the largest part of the work. Validate, Then Switch DNS Fully test on staging Verify checkout, payments, emails, pricing Switch DNS once validated re export new customers

Hi — this may help, and @Daresh is also correct. now we discuss 101 times...loool Using phpMyAdmin, you can sort your database by table size and row count to quickly identify which tables are growing abnormally. Without doing this, you are essentially guessing and won’t know where the actual bloat is coming from. Be aware that some modules store caches and logs in database tables, and these can grow very large over time if not managed properly. How to find large tables using phpMyAdmin: Log in to phpMyAdmin from your hosting control panel. Select your PrestaShop database from the left sidebar. Click the Structure tab (this is the default view). Scroll to the bottom of the table list and ensure the following columns are visible: Rows Data length Index length Size Click the Size column header to sort tables by total size (Data + Index). Alternatively, click Rows to sort by row count and identify log- or cache-heavy tables. Tables that stand out as unusually large are typically the source of database growth and performance issues. Here is an article that outlines common PrestaShop tables that tend to grow large, and which ones can typically be safely emptied or pruned (depending on your setup): https://prestaheroes.com/blogs/mysql-optimization/which-large-prestashop-tables-can-be-dropped-or-emptied-safely

please share with me where your main customer country or region

Generic SQL: convert BGN → EUR (simple products) Assumptions Prices were originally entered in BGN Default currency is now EUR Table prefix is ps_ (change if different) Conversion rate: 1 EUR = 1.95583 BGN Rounded to 2 decimals -- Convert base product prices from BGN to EUR UPDATE ps_product SET price = ROUND(price / 1.95583, 2), wholesale_price = ROUND(wholesale_price / 1.95583, 2); -- Convert shop-scoped prices (used even in single-shop installs) UPDATE ps_product_shop SET price = ROUND(price / 1.95583, 2), wholesale_price = ROUND(wholesale_price / 1.95583, 2); ⚠️ Important This SQL only updates simple product base prices. If you use any of the following, additional SQL statements are required because prices are stored in other tables: Product combinations / attributes (size, color, etc.) Specific prices (sales, discounts) Cart rules / vouchers with fixed amounts Shipping prices stored in the database • Make a full database backup first • Test on staging if possible • Put the shop in maintenance mode • Do NOT modify historical orders