El Patron

On PrestaShop Hosted there is no FTP by design. You cannot upload or edit files directly. All customizations must be done via modules or the limited theme editor. If you need full file access (FTP/SFTP, overrides, custom templates), you must use a self-hosted PrestaShop installation.

Hey @ROE no rest for the weary Capture the real 500 error (don’t guess) Do not rely on “debug mode” in BO if it makes the shop unstable. Instead, pull the error from logs. Find your error log location first (before testing anything) In your hosting panel (Plesk/cPanel or similar), locate: Domain → Logs (Apache/Nginx) PHP error log / PHP-FPM log If your host provides “Live log” or “Follow log,” open it now. With the log open, replicate the problem In a new tab, go into Back Office and click the exact menu that triggers the 500: Catalog → Products / Categories Modules → Module Manager Do not change settings yet. Just reproduce the error once. Immediately re-check the log (this is the important part) Look for the first relevant entry at the exact time you clicked: PHP Fatal error Uncaught PDOException SQLSTATE[...] memory/timeouts like Allowed memory size exhausted or Maximum execution time exceeded Post the first error line + the next few lines The first fatal line is usually enough to identify whether this is: SQL mode / MySQL compatibility ProxySQL (port 6033) limitations/rules PHP 7.0 compatibility/fatal error permissions / missing extension / memory If you paste that error snippet (redacting domain/usernames), people can tell you quickly whether you need the host to adjust sql_mode, ProxySQL rules on 6033, or whether the legacy PS/PHP stack is now failing on specific BO queries.

This is not a server issue, not permissions, and not PHP config. It is a core BO controller / routing mismatch introduced in PS 8.1.x. However, the Back Office UI triggers this route via a GET request when clicking: “Print invoices by status” “Print invoices by date” So Symfony blocks it correctly with HTTP 405 Method Not Allowed. This is why: Debug mode shows a Symfony exception Non-debug mode shows a generic BO error It affects all environments consistently Patch the controller to allow GET only for BO invoice generation. find file /src/PrestaShopBundle/Controller/Admin/Sell/Order/InvoiceController.php Locate the action handling byStatusAction() or byDateAction() and ensure it accepts both methods: update as follows: #[Route( '/sell/orders/invoices/by-status', name: 'sell_orders_invoices_by_status', methods: ['GET', 'POST'] )]

Hi @Caroline Harper This is the fastest way to identify the problem. Advanced Parameters → Performance → Debug Mode → Enable Profiler Then load: Orders list Product edit page Modules page Look specifically at: Slow SQL queries Repeated queries Hooks executed on BO pages (displayBackOfficeHeader, actionAdminControllerSetMedia, etc.) Modules that inject logic into every admin controller show up clearly here. Disable profiler after testing. 2. you can disable one new module and see if problem goes away, if not enable and to the other modules you installed. If the shop starts to behave as expected after a disable contact the developer for assistance. I hope this helps get you started with analyzing your PrestaShop environment. Once you begin profiling and isolating modules, other contributing factors usually become much easier to spot. Fred

Yes, you will need to change the prices to reflect EURO as the warning informed you.

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