PrestaHeroes.com

This happens to me sometimes to, after installing a new payment method sometimes also. admin-->payments-->preferences and then associate paypal countries, groups etc. then it will appear.

note: I don't know your exact payment methods but I never use nor recommend PrestaShop Checkout. if paypal and cc what I usually 'almost' always implement is native checkout and two free modules on addons paypal and stripe (stipe module supports wallet (apple/google/gapy) native checkout is rock solid..

That stack trace is the classic moduleRoutes hook getting executed too early (Front Office legacy dispatcher is loading routes, but the Symfony kernel/container isn’t bootstrapped yet). On upgrades 1.7 → 8.x this can happen when a module ends up registered on moduleRoutes in the DB, and FO then dies with: ContainerNotFoundException: Kernel Container is not available A proven fix (used for ps_checkout, same idea for PayPal) is: remove that module’s moduleRoutes hook registration (and remove the hook alias row if present). Fix (DB) — safest/fastest Backup your database first. Open phpMyAdmin (or CLI) and run these queries, replacing PREFIX_ with your table prefix (often ps_): DELETE FROM PREFIX_hook_module WHERE id_module = (SELECT id_module FROM PREFIX_module WHERE name = 'ps_checkout') AND id_hook = (SELECT id_hook FROM PREFIX_hook WHERE name = 'moduleRoutes'); DELETE FROM PREFIX_hook_alias WHERE alias = 'moduleRoutes'; This exact approach is what solved the same crash after activating ps_checkout. For PayPal (usually ps_paypal) DELETE FROM PREFIX_hook_module WHERE id_module = (SELECT id_module FROM PREFIX_module WHERE name = 'ps_paypal') AND id_hook = (SELECT id_hook FROM PREFIX_hook WHERE name = 'moduleRoutes'); DELETE FROM PREFIX_hook_alias WHERE alias = 'moduleRoutes'; Then clear cache

PrestaShop generally does _attachment not play well with full Cloudflare proxying. In most cases, the most stable setup is to use Cloudflare primarily for DNS management, not for aggressive caching or optimization features. For CloudFlare and to avoid issues with sessions, cart behavior, geolocation, and dynamic content, only specific records should be proxied (orange cloud) — typically the main domain and www record. Use CF for DNS only. https://app.screencast.com/hGyYBn9IusbHh

You've only found the obvious issues so far — with PrestaShop caching there are usually many more problems hiding underneath. https://docs.litespeedtech.com/lscache/lscps/troubleshoot/ the mention that 1.7 in particular is a problem child and you should hire someone loool. PrestaShop pages are dynamic by design. The native “cache” options are not real full-page caching — they only store template fragments or database results. Because of this, external cache modules often create inconsistent behavior like stale prices, wrong stock, or sessions not updating. Historically the only somewhat reliable layer has been basic object caching (like Memcache), and even that is known to cause stale data problems because cache invalidation in PrestaShop is weak. Many older developers will remember when Varnish first became popular — a huge number of shops broke due to cached carts, wrong pricing, and session conflicts. The same risks still exist today with aggressive cache modules. In practice, the safest approach is: Use Smarty cache + CCC only Rely on PHP OPcache and proper server tuning Avoid full-page cache modules unless you deeply understand the risks Based on the troubleshooting described for this module, I would personally recommend not using it. It’s likely to create more instability than performance gain.

if it's experimental, then don't have it on by default, this is exactly the crap ps pulls since inception...experiment with users and the user does not even know. countless people that built their business on ps, were destroyed by bull crap upgrades that added no feature, just to get new cycle of theme/modules sales compatible with that version...I could go on but I have gone on since 1.4...the french way ready fire aim

the www is barbaric, few hosting packages have any firewall at all. a lot of ps admins get cloudflare but do not know how to setup for prestashop so they end up destroying their shops, 502, 403's.... recaptcha's on ps have always been piece of crap, work on one section not on another... agencies end up spending more time fighting fires rather than improving their clients business with new features...exhausting and is exactly why I run my ps gency on shopify looool.

One of the big problems to solve is render block .css and .js. Our CSS and JS pro modules remove this render blocking by inserting preloads into the header. You can review the modules here on our shop at prestaheroes.com

this worked for other did you do same? remember to read previous posts before saying you have similar problem or open a new post if you issue is different for best resutls.

If you're running an international PrestaShop store and seeing Google Merchant price, currency, or country mismatches, the issue is usually structural — not just a feed export problem. In many cases, Google is indexing products under the wrong country context, which causes Merchant Center to flag discrepancies between feed pricing and landing page pricing. I recently documented the proper architectural fix here: Click here to read how we did this: Solving Google Merchant Country Feed Errors in International PrestaShop The short version: The URL must define the market (language + country), and PrestaShop must enforce that country context for Googlebot and other crawlers. Without that alignment, feeds will continue to mismatch no matter how many times you regenerate them. This approach resolves long-standing international indexing issues and allows you to build reliable country-specific Google Merchant feeds. Your Welcome! Fred

Le module Stripe gratuit disponible sur Addons prend également en charge Apple Pay et Google Pay, et accepte un nombre correct de paiements par carte bancaire. https://addons.prestashop.com/en/payment-card-wallet/24922-stripe-official-sca-ready.html

Je comprends parfaitement votre point de vue. Heureusement, dans le monde d’aujourd’hui, les traductions sont beaucoup plus faciles — bon, sauf WhatsApp, qui parvient encore à nécessiter trois clics même après avoir ajouté la traduction 😄 En même temps, je comprends aussi le besoin de protéger une langue par crainte de la voir disparaître. C’est quelque chose que je respecte pleinement également.

it's right click translate, well if one has a 3 button mouse loool, only we can create language barriers...

Oui — dans PrestaShop, il faut s’appuyer sur les dimensions d’images générées via Paramètres des images, et non sur du CSS personnalisé. PrestaShop génère déjà les attributs width et height sur les balises <img> en fonction du type d’image (home_default, large_default, etc.), ce qui correspond exactement à ce que PageSpeed attend. Si PageSpeed continue de signaler un problème, cela signifie généralement que : Un thème ou un module de performance supprime ces attributs L’image est utilisée comme image de fond CSS (hero / bannière / slider) Une surcharge de template est obsolète et ne sort plus {$image.bySize.*.width} et height Ajouter uniquement des dimensions via le CSS ne corrigera pas l’audit : les attributs doivent être présents dans le HTML ou bien l’espace de mise en page doit être réservé à l’aide de aspect-ratio.

chatgtp is pretty good at detailing change, see attached .pdf that explains the change you should make, it may not be perfect but will help you understand how to make the change. Prestashop_Email_Feature_Injection_Guide.pdf