El Patron

Let me give you the simplest and most reliable way to resolve a repeatedly hacked shop, assuming you cannot locate the malicious payload. Recommended clean approach Install a fresh copy of PrestaShop Use the same major version you are currently running (or the latest patch of that version) Do NOT move to PS9 at this time Install it on a subdomain (for example: new.yoursite.com) Migrate only trusted data Use Migration Pro (from PrestaShop Addons) Transfer: Products / catalog Customers Orders Groups, categories, and core shop data Manually reintroduce themes and modules Bring over only: Your theme Paid or well-known third-party modules Custom data PrestaShop does not manage Why this works: If the malware payload exists in core files or the database or rouge unused file, it is left behind. The only remaining risk is a compromised module or theme you choose to reinstall. Before going live Avoid random free modules or unknown developers. PrestaShop forum has allowed unvetted free modules that not only competes with legitimate PS developers but also are not vetted at all...use at your own detriment. This has been issue we hope that new PS owners will solve, PS has been advised for years to stop this practice but they have not. Validate modules using the official PrestaShop validator: https://validator.prestashop.com/ Remove anything you do not absolutely need Alternative You can hire an experienced agency or a well-known developer to locate and remove the payload directly. Be aware that even for professionals this can be difficult, and for non-technical admins it is often close to impossible. This rebuild-and-migrate approach is how infected PrestaShop shops are properly cleaned. Good luck.

CHATGTP or other Claude, Gemini can take your feed, then simply tell it what you want to do and it's done. If you prefer a module, any of these three can create the module for you.

Note importante concernant PrestaShop 9 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.

https://prestaheroes.com/blogs/prestashop-alerts/prestashop-s-ownership-change-exposed-a-deeper-problem-why-shopify-ate-its-liver

A few important clarifications that are often glossed over in the forum: PrestaShop 9.0.x was marketed as stable In reality, it behaved more like an extended release candidate. Core workflows (including International → Locations → States/Provinces) have produced regressions, validation errors, and UI inconsistencies that simply did not exist in mature 1.7 or 8.x branches. Current reality: 9.1 is still beta The currently announced 9.1.x line is explicitly a beta. By definition: It is not intended for common use It assumes advanced users, staging environments, and log-level debugging Merchants should expect breakage, schema changes, and unfinished features That alone should have been communicated much more clearly. Community “testing” ≠ informed consent Year after year, the same pattern repeats: A major version is labeled “ready” Merchants upgrade in good faith Real-world issues surface The community ends up discovering and reporting problems post-release I highly recommend and what should be stated by seasoned PrestaShop users is that PS9 is not ready, to not use ps9 but an earlier version or just find another ecommerce platform, there are plenty and none use the business module that PrestaShop uses. PrestaShop lost so much market share doing things like this, ps9 has NO must have feature, PrestaShop does this so people have to repurchase modules and themes, none of which are very good. If you want a stable PrestaShop then use 8.2.3. I challenge other forum members to speak the truth to new users and who got tricked in ps9, use any previous stable version. Hopefully the new owners of PrestaShop will put an end to this, I think they will.

The first thing I recommend is reviewing competitor shops within your product vertical. Look closely at the features, UX patterns, and trust signals they implement, and identify what your own store is missing or under-delivering on. Customization must always be balanced with update safety. Best practice is to apply all changes on a staging environment first, take full backups of production, and only then deploy tested changes live. From an infrastructure perspective, follow proven best practices: use the best hosting your budget reasonably supports, SSD or NVMe storage, PHP-FPM with dedicated resources, and—something many overlook—properly tuning MySQL instead of relying on default out-of-the-box settings. From experience, store owners and administrators can only take a business so far on their own. To scale meaningfully, you eventually need an agency or technical partner that understands your product vertical, actively analyzes competitors, identifies missed opportunities, and brings stronger ideas to the table—someone focused on taking the business to the next level rather than simply maintaining the status quo.

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