PrestaHeroes.com

https://prestaheroes.com/collections/performance

That’s really nice—fresh and well executed. It does take a moment to adjust, but only because it’s modern, which honestly is rare to see in most PrestaShop builds. My only real feedback is at checkout: I’d strongly consider removing the Privacy Policy and Terms & Conditions blocks unless they are legally required in your country. They tend to be visually distracting at a critical conversion step. PrestaShop is very EU-opinionated by default, and although you’ve already cleaned up a lot of that, GDPR/TOS elements are still enabled out of the box. On non-EU builds, this is one of the first things I remove. One additional UX note on the product list: when a product has attributes, showing “Add to cart” can be misleading. You may want to switch that to “Select options” (or similar). Ideally, this would open a quick-view modal rather than sending the visitor to the product page, which helps keep them in the browsing flow. Overall—great work. It’s genuinely refreshing to see something clean, modern, and thoughtfully executed in PrestaShop.

Hi here is link to PS9 parent/child .doc

Performance optimization should become a priority as soon as you notice backend sluggishness or intermittent frontend delays, not only when traffic is high. In PrestaShop, performance issues tend to accumulate quietly as products, categories, combinations, and modules grow. The good news is that the biggest gains usually come from a few foundational improvements rather than drastic changes. When optimization should move to the top of the list If you’re seeing any of the following, it’s time: Back office pages loading slowly (especially product edit, orders, or modules) Delays when adding or editing products and combinations Random frontend slowness despite modest traffic Timeouts during imports, indexing, or cache operations These symptoms almost always point to database and storage bottlenecks rather than PrestaShop itself. High-impact optimizations that deliver early results NVMe-SSD hosting If your store is still on traditional SSD or shared hosting, moving to NVMe-SSD storage is often the single biggest improvement. PrestaShop is extremely database-heavy, and NVMe drastically reduces I/O latency. Back-office actions frequently feel several times faster immediately after migration, with no code changes or risk. MySQL tuning Default MySQL settings are rarely appropriate for a growing PrestaShop store. Proper tuning of InnoDB memory, temporary tables, and slow queries makes a noticeable difference in both the back office and front office. I’ve written several practical, PrestaShop-specific articles on this here: 👉 https://prestaheroes.com/blogs/mysql-optimization Module discipline Every enabled module adds queries and hooks. Disable anything you’re not actively using, review modules that hook into every page (header, footer, display hooks), and avoid overlapping functionality such as multiple SEO or analytics tools. This alone can remove hundreds of unnecessary queries on larger shops. Key takeaway Most PrestaShop performance problems start with storage and the database, not traffic volume or themes. Upgrading to NVMe-SSD hosting, tuning MySQL for your catalog size, and keeping module usage intentional will usually restore backend responsiveness and frontend stability long before performance becomes a crisis. Addressing this early is far easier — and far cheaper — than waiting until the shop becomes painful to manage. For nearly all shop administrators, there comes a point where having an experienced agency involved makes sense — not to add “voodoo” performance modules, but to improve performance in a safe, measurable way. PrestaShop tuning is genuinely complex, and many of the most effective gains come from proper database configuration and upgraded hosting rather than front-end tricks. Improving the underlying infrastructure, especially storage and MySQL performance, often delivers significant, reliable speed improvements without risking shop stability.

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.