PrestaHeroes.com

Hey, if you can attach the module here I can update it to work. Also make sure to include your prestashop version. I would need to know payment received order stat id. or from phpmyadmin or ps sql manager First, get the order_state ID(s) SELECT id_order_state, name FROM ps_order_state_lang WHERE name LIKE '%Payment%' OR name LIKE '%Received%'; Use those IDs in this report query This returns product + total qty for orders whose current status is “Payment Received”, within a date range: SELECT od.product_id, od.product_reference, od.product_name, SUM(od.product_quantity) AS qty_sold FROM ps_orders o JOIN ps_order_detail od ON od.id_order = o.id_order WHERE o.current_state IN (/* put id_order_state(s) here */) AND o.date_add >= '2026-01-01 00:00:00' AND o.date_add <= '2026-01-31 23:59:59' GROUP BY od.product_id, od.product_reference, od.product_name ORDER BY qty_sold DESC;

here is a solution that might help copy robots.txt to robots.custom.txt edit robots.custom.txt and include custom directives etc. add this to top of .htaccess file RewriteEngine On # Serve custom robots file instead of PrestaShop-generated one RewriteRule ^robots\.txt$ /robots.custom.txt [L]

Hans, I know what to do loool I messaged you. Fred

Cette erreur signifie que PrestaShop ne parvient pas à charger son autoloader principal. config/autoload.php tente d’utiliser la classe PrestaShopAutoload, mais le fichier de classe est manquant ou corrompu, ou bien vous avez un mélange de fichiers provenant de différentes versions de PrestaShop. Points à vérifier Dans la racine de votre boutique, vérifiez que ce fichier existe et qu’il est lisible : /classes/PrestaShopAutoload.php Vérifiez également les permissions et le propriétaire des fichiers (dossiers en 755, fichiers en 644). Comment corriger le problème (cas le plus courant) Téléchargez exactement la même version de PrestaShop que celle utilisée par votre boutique. Réuploadez / restaurez au minimum : /classes/PrestaShopAutoload.php (et idéalement tout le dossier /classes/) Si vous avez récemment effectué une mise à jour ou restauré une sauvegarde, il est plus sûr de réuploader les dossiers cœur propres correspondant à cette même version (/classes, /config, /vendor, /src, etc.) afin d’éliminer les fichiers provenant de versions différentes. Après la restauration des fichiers cœur manquants, le front-office et le back-office devraient à nouveau fonctionner. in original english (note you may have been hacked) That error means PrestaShop can’t load its core autoloader. config/autoload.php is trying to use the class PrestaShopAutoload, but the class file is missing/corrupted or you have mixed files from different PrestaShop versions. What to check In your shop root, verify this file exists and is readable: /classes/PrestaShopAutoload.php Check permissions/ownership (folders 755, files 644). How to fix (most common) Download the exact same PrestaShop version as your shop. Re-upload/restore at least: /classes/PrestaShopAutoload.php (and ideally the full /classes/ folder) If you recently upgraded or restored a backup, it’s safer to re-upload the clean core folders for that same version (/classes, /config, /vendor, /src, etc.) to eliminate “mixed version” files. After restoring the missing core files, the front office and back office should load again.

at the end of the day what's important is that the CC intake at checkout is modern. If there is free module, then it would be easy to test, best if you have a staging (test copy) to test changes first. Where does the free module come from? Also stripe very good and has free from addon's, tip avoid prestashop checkout, it's a problem child rather use the native and then add payment modules you need.

PrestaShop does not support customer-entered pricing natively, but this can be implemented properly via a dedicated module (not a core hack). I have the expertise to build this feature so customers can enter an amount, have it validated, and proceed through checkout safely with correct totals, taxes, and reporting. Beyond the feature itself, my agency specializes in full migrations from non-PrestaShop platforms to PrestaShop. This includes preserving existing workflows, data integrity, and SEO while rebuilding the shop to fully leverage PrestaShop’s strengths rather than fighting against them. If you’d like, I’m happy to provide a free, detailed migration and new-shop build plan tailored to your current platform and requirements. Just message me with your email address. Migrations into PrestaShop are something we’ve always excelled at—we enjoy the challenge, go the extra mile, and focus on building a clean, scalable, and well-architected shop from day one.

Hey Stefan, You are currently with what I would call “pirate hosting” — the type of provider that dictates which PHP versions you are allowed to run and can just as easily auto-upgrade PHP without notice, breaking your shop overnight. Over my many years of helping in the forum I have seen 100's of instances of where hosting upgraded the php to level not supported by PS. But there were many that did not post here, that's ridiculous. A proper setup is one where you control the PHP environment. That is exactly what you get with a VPS using Plesk: you decide which PHP versions are installed, which one each domain uses, and nothing changes unless you change it. If a host is charging you extra just to choose or lock a PHP version, that should already be a major red flag. If they will nickel-and-dime you over PHP, imagine what else they are doing behind the scenes — none of it is good. Hosting providers should never dictate your PHP runtime. Unfortunately, many modern hosts build their own “custom” control panels with artificial constraints. This always comes back to bite merchants. I have seen countless shops on this forum go offline after a new PHP version is released and the host rolls it out globally across all accounts. At that point, you are not a customer — you are a beta tester. My honest advice: run away from IONOS. Even OVH — despite its own historical issues — at least allows you to run a proper VPS with NVMe SSD and Plesk, where you stay in control. That said, I do not recommend OVH for U.S.-based users due to their strange support and contractual limitations. Best option is to get a US bases VPS with Plesk, we have big fat fiber pipes to other world and IP is no longer part of seo (i.e. localization) just the domain cctld/gtld. Bottom line: If your host controls your PHP, your shop is living on borrowed time.

PrestaShop 9.0.1 is not a production-ready release. It is effectively beta software, intended only for experienced technical admins and developers who are comfortable debugging PHP/Symfony issues and working in staging environments. Unfortunately, PrestaShop made a serious mistake by presenting early PS9 releases as suitable for general use. This caused new and existing merchants to upgrade in good faith, only to discover breaking issues, incomplete module compatibility, and unstable core behavior.

If your pricing model is truly group-based and fixed, the cleanest approach is: Use Specific Prices by group Hide prices for guests Treat login as a requirement, not an option This avoids customer confusion and keeps pricing predictable.

You did nothing wrong. The problem is that PrestaShop 9.0.2 should never have been presented as a safe upgrade path. Unfortunately, PrestaShop has a long history of publishing major releases as “current” while they are still effectively beta, and PS 9.0.x is a textbook example of this. Merchants upgrade in good faith, only to discover afterward that they’ve become unpaid testers. Why your upgrade failed PrestaShop 9.0.2 is not production-ready: Core regressions still exist Module and theme compatibility is incomplete Critical workflows (checkout, localization, carrier logic, overrides) break silently Error handling assumes developer-level debugging skills This is why even now, newer PS9 releases are labeled beta / for advanced users. That disclaimer came after many merchants were already burned. What you should do now (important) Restore your shop immediately to your last stable backup (PS 8.x or earlier). Do not attempt further fixes on PS 9.0.2 — you will only waste time and money. Continue operating on PrestaShop 8 (latest stable 8.x), which is production-proven and fully supported by the ecosystem. Wait for a genuinely stable PS9 release (not a “current download”, not a beta, not community-tested).

Why You Should Not Start a New Business on PrestaShop 9 (Yet) If you are already encountering issues during installation, that alone is your answer: do not build a new business on PrestaShop 9 at this time. PrestaShop 9 is not a stable, production-ready release for non-technical users. Even PrestaShop has now acknowledged this by labeling newer releases as beta / for advanced users only. Unfortunately, earlier PS9 releases were presented as “current” or suitable for general use, which has caused confusion and real problems for merchants.

The real question is: what new features in later PrestaShop releases actually make upgrading appealing? Historically, PrestaShop’s major releases rarely introduce front-office features that materially increase sales. Most changes are architectural, and the practical consequence is that merchants are forced to repurchase compatible modules and themes. From a merchant’s perspective, this is a poor business model. In my experience, PrestaShop 8 installations have also proven to be more susceptible to hacks than stable 1.7 shops. As for PrestaShop 9, there are only a handful of genuinely new features introduced in 9.0 (for example, unlimited guest checkout using the same email), and even those were broken in 9.0.1. From a revenue and growth standpoint, upgrading PrestaShop itself is rarely what drives results. Increasing sales through new features does not require a platform upgrade. The same functionality can almost always be implemented on 1.7 if you know what features are missing. So how do you identify those gaps? By analyzing competitors in your product vertical and studying best-in-class e-commerce sites such as Walmart or Newegg. Look at what they are doing to improve the visitor experience—navigation, filtering, checkout flow, trust signals, performance—and implement comparable improvements. In short, rather than upgrading to a new PrestaShop version for minimal or no tangible gain, the better investment is to upgrade features that improve user experience and conversion, regardless of the core version.

PrestaShop 9 non è pronto per un utilizzo generale. Per molti mesi la versione 9.0.x è stata presentata come una release “corrente” o utilizzabile, quando in realtà richiedeva un livello di competenza tecnica che la maggior parte dei commercianti e degli amministratori non tecnici non possiede. Solo recentemente PrestaShop ha chiarito ufficialmente che l’attuale versione 9.x è una beta e non è destinata all’uso in produzione da parte di amministratori non tecnici. Questa conferma è in linea con quanto molti sviluppatori e agenzie affermano fin dall’uscita iniziale della 9.0.0. Raccomandazione pratica: Restare su PrestaShop 8.x per i negozi esistenti Scegliere PrestaShop 8.x per qualsiasi nuovo negozio oggi Non tentare l’aggiornamento a PS9 a meno di essere sviluppatori o di disporre di un team tecnico esperto e di un ambiente di staging adeguato PrestaShop 8 rimane, al momento, l’unica opzione stabile e sicura per l’uso in produzione. Ci si augura che, sotto la nuova proprietà di PrestaShop, le future release vengano comunicate in modo più responsabile, con avvisi più chiari e senza presentare versioni principali non mature come pronte per l’adozione generale. La community non dovrebbe essere utilizzata come gruppo di test implicito per software critico in produzione.

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.