El Patron

use webpagetest.org it tells you what/how to change to improve performance some may notice when using lighthouse it mentions this website to remove blocking for .css and .js see my pro modules...your big blocker is your ccc of theme .css....over 2 seconds...

To remove 'Stores' shop parameters-->contact-->stores-->delete the store (assumption you do not have a brick and mortar store)

After you recover (restore?) you can use my module written when my 1.4 shop got hacked. Once installed it will monitor your shop files and detect 'any' change rnd send an alert. You can then action by: restoring the file from vault | commit trusted change to vault. https://prestaheroes.com/collections/all-modules/products/prestavault-malware-trojan-virus-protection immunavy is good to have on your hosting, for plesk but may be one for cpanel. What to do immediately Change all passwords PrestaShop back office users FTP / SFTP Hosting panel Database user Scan for modified files Compare timestamps vs backups Look for: Unexpected .php files PHP code inside /img, /upload, /pdf Modified .htaccess Lock down permissions Files: 644 Folders: 755 Disable unused modules Especially old or unmaintained ones Remove modules you “might use later” Note: AI is excellent in reading and reporting log issues. Check logs Access log Error log ModSecurity log (if enabled) Look for POST requests to upload endpoints

Thanks for posting, but right now there isn’t enough information for anyone to diagnose the issue with card payments in the PayPal module. Before the community can help, please provide the following essential details: Required Information PrestaShop version PHP version PayPal module version Exact error message or behavior (copy-paste text, not just “it doesn’t work”) Screenshots of the configuration page and any errors Server environment (Apache/Nginx, hosting provider, SSL status) Steps you’ve already tried Without this info, helpers would need to ask 15–20 follow-up questions before diagnosing anything, which significantly slows down support. For self-debugging, enable PrestaShop’s debug mode and capture errors/logs this way: https://prestaheroes.com/blogs/prestashop-alerts/how-to-enable-prestashop-debug-mode-v8-v9 Please update your post with the above details and any debug output. Once we have that, we can help troubleshoot

PrestaShop 9 is effectively still in a beta state, regardless of official messaging. The practical recommendation is to either wait for 9.1 or use the latest stable PrestaShop 8.x release. In this cycle, PrestaShop released what would traditionally have been developer-only builds directly to the public, which increases risk for production use. My recommendation and I have deep experience in migrating into PrestaShop all sorts of platforms including custom built systems. hope this helps For Magento 1.9 → PrestaShop 8/9, the most reliable approach is a staged migration using a proven tool, followed by a delta migration at go-live. Tools commonly used Cart2Cart LitExtension How it works Set up a staging PrestaShop (8.1/8.2 recommended). Run a full dry-run migration (products, categories, attributes → combinations, customers, orders). Validate mappings and complete theme, payments, shipping, SEO on staging. Just before launch, run the tool’s delta migration to pull new customers/orders. Switch DNS and verify. Why this is best Multiple test runs without affecting production. Magento stays live while PrestaShop is finalized. Delta migration minimizes downtime and data loss. Notes Customer passwords usually require reset. SEO needs URL mapping + 301 redirects. This approach is the lowest-risk and most predictable way to migrate Magento 1.9 to PrestaShop.

In performance investigations, the most consistently overlooked bottleneck is MySQL itself, not PHP, the theme, or front-office code. Most hosting providers deploy MySQL with very conservative, one-size-fits-all default configurations. These defaults are designed for compatibility and low memory usage across thousands of accounts—not for read/write-heavy eCommerce workloads. As a result, several key performance settings are effectively turned off or set so low that they provide little real benefit. Even a well-built PrestaShop store will feel slow if: MySQL is running close to stock defaults InnoDB buffers are undersized Query and temp tables are forced to spill to disk The database is I/O-bound rather than CPU-bound I’ve written a short series of practical articles focused specifically on MySQL optimization for PrestaShop, based on real audits and production systems: https://prestaheroes.com/blogs/mysql-optimization From a cost-to-benefit perspective, the single biggest win today is storage. Over a long career doing performance work, moving from SATA or network-backed disks to NVMe consistently delivers the largest reduction in query latency. NVMe was once expensive, but it is now common even on mid-range VPS plans. Before chasing theme tweaks or code-level optimizations, make sure: MySQL is tuned for an eCommerce workload You are not constrained by disk I/O Your database is running on NVMe storage In many cases, fixing those fundamentals alone resolves “slow database access” issues without touching application code.

This behaviour is a known bug in PrestaShop 8.1/8.2 where you can click “set as cover” in the product image gallery but it doesn’t persist after saving; it’s been documented on GitHub (for example, Can’t set cover product image — https://github.com/PrestaShop/PrestaShop/issues/34646 and related reports such as https://github.com/PrestaShop/PrestaShop/issues/34534). GitHub+1 As of the latest 8.2.x releases there isn’t an official core fix specifically for this cover image behaviour in those branches, so the reliable workarounds are to disable the “New Product Page” in BO → Advanced Parameters → New & Experimental Features and retry, clear cache, or delete and re-upload images (first uploaded image becomes cover). GitHub

PrestaShop 9 does not include built-in email confirmation (double opt-in / required activation) for customer registration — you must install a module to enforce email verification before the account becomes active. prestashop.com Modules you can link in a forum reply (full URLs): Email Verification (PrestaShop Addons): https://addons.prestashop.com/en/website-security-access/25822-email-verification.html addons.prestashop.com Verificación de Email para la activación del cliente (PrestaShop Addons): https://addons.prestashop.com/es/emails-notificaciones/85224-verificacion-de-email-para-la-activacion-del-cliente.html addons.prestashop.com Email Verification for Customer Account Activation (PrestaShop Addons): https://addons.prestashop.com/en/customer-administration/49611-email-verification-for-customer-account-activation.html addons.prestashop.com Prestashop Account Activation by Email Link (double opt-in) – MyPresta: https://mypresta.eu/modules/front-office-features/account-activation-by-email-link.html mypresta.eu Prestashop Customer Email Verification (FME Modules): https://www.fmemodules.com/en/prestashop-modules/140-email-verification-for-customer-activation.html fmemodules.com Verify Account for Prestashop (CodeCanyon): https://codecanyon.net/item/verify-account-for-prestashop/14427973 CodeCanyon

https://prestaheroes.com/blogs/prestashop-alerts/why-you-should-never-use-free-or-even-paid-modules-from-the-prestashop-forum-without-caution

being sure does not make it true, simply research would prove it does...you don't have the experience to think for sure how it works. then you go on to saying no idea. use tool like semrush or other to get ideas

I've done loads of ga4 integrations, used several different modules without issue and if we did we either worked with the addon's dev or fixed it ourselves. from addons the top three rows I have used over the years link below, all worked fine unless you have weird template and then some slight changes need to be done. For agency I highly recommend prestachamps.com that I've worked with for years on large and small projects and they know what the heck they are doing. They have certified google folks and affordable. https://addons.prestashop.com/en/search?search_query=ga4&id_category=453&ps_version[]=8.1

Totally agree with this. A big part of the problem isn’t just theme/module quality — it’s the business model of PrestaShop Addons itself. Right now everything is one-off payments. There are no real entry-level subscriptions, and “Business Care” was just a stop-gap — not a modern solution. Because of that, developers who actually maintain code, keep up with PS releases, and fix security issues have only one option: raise one-time prices. When merchants are asked to spend €100–€400 per module (one-time!) for basic, essential features — and most modules receive limited or no meaningful updates after purchase — they get priced out of the functionality they need to compete in their product vertical. They can’t grow, can’t stay current, and end up frustrated. This is one of the main reasons PrestaShop has lost huge market share to Shopify, WooCommerce, and others. Those ecosystems have: Low entry pricing Monthly billing Continuous updates Quality-based competition PrestaShop has real potential, but until the Addons marketplace modernizes to support subscriptions and ongoing revenue, we’ll keep seeing: Declining trust Low-quality releases Devs abandoning products Merchants switching platforms The technology isn’t the main issue — the business model is outdated.

this module supports external virtual downloads and webkul is a developer I trust https://webkul.com/blog/prestashop-virtual-file-manager/

Tip for anyone new to PrestaShop checkout configuration: Auto-displaying “Terms & Conditions” at checkout is a default from another era. What is this — 1995? In my own builds, the very first thing I do is remove that box (unless a client has a real legal requirement for it). Same with the default “newsletter” checkbox — at the very least, rename it to something customer-centric like “Receive Special Offers.” PrestaShop’s mistake is enabling T&C automatically. This should be opt-in, not forced on every shop out of the box. There is nothing that screams “old-school ecommerce” more than interrupting the purchase flow and confusing customers with a legal wall of text when they’re already trying to checkout. Sure — some businesses might genuinely need formal T&C acknowledgment. But 99% don’t. Don’t distract buyers at the most critical moment with boilerplate because PrestaShop decided to include it by default. Clean checkout equals higher conversions.

Totally agree. Cloudflare Turnstile is currently the best public-facing solution — it’s lightweight, privacy-friendly, and avoids all the customer friction that comes with traditional CAPTCHA modules. Most CAPTCHA modules in PrestaShop are poorly written, and they inevitably create random checkout or login issues that you can’t even reproduce during testing. The bigger point: all websites are vulnerable, and you can’t rely on a couple of PrestaShop modules to protect you. Serious protection happens outside of PrestaShop: Host-level firewalls and WAF (Web Application Firewall) Use a hosting provider that supports real firewall rules (not just “security plugins”). A properly configured WAF will block malicious payloads long before they ever reach PrestaShop. mod_security with a maintained ruleset mod_security with OWASP CRS (and custom rules for known PrestaShop attacks) is a BEST PRACTICE. This blocks SQL injection attempts, fake form submissions, bot probing, known exploit patterns, and a ton of automated scanners that run 24/7. Cloudflare or equivalent DNS proxy protection Even on the free tier, Cloudflare provides rate limiting, bot filtering, and network-level DDoS mitigation. Combine this with Turnstile and you eliminate most automated attack vectors before they touch your server. Server-level rate limits Limit POST requests per IP, throttle login attempts, and block failed cart / checkout spam. These are easy NGINX / Apache rules that most hosting companies simply don’t bother enabling by default. Bottom line: PrestaShop is not inherently “insecure,” but it is soft if you treat it like a WordPress blog and never harden the environment around it. Protect the perimeter first, then add smart in-app protections. That’s the formula.