JPresta.com

😁J'en profite pour rappeler ma recommandation de faire la purge (pas le vidage) du cache tous les 2 ou 3 jours (URL dispo dans le menu "API (URLs pour vider le cache)")

Le cache est souvent très long à se vider, quand j'ai un un timeout je relance plusieurs fois. Le répertoire "pro~" peut être généré par Prestashop, c'est une vieille copie du répertoire "prod" que vous pouvez supprimer.

Le cache "vie" pendant que vous essayez de le supprimer, il est possible qu'un fichier ou répertoire soit modifié/supprimé/créé entre le moment où il vérifie et le moment où il tente de faire un traitement qui provoque une erreur 500. Au début j'étais comme vous, cela m'inquiétait, maintenant je recharge simplement jusqu'à ce que ça fonctionne 🙂

You're absolutely right that many PrestaShop shops run on default MySQL configs never meant for ecommerce. Tuning the database itself can unlock huge gains. For anyone who wants to go a bit deeper, I've built a module called SQL Profiler that profiles SQL queries directly on production stores - safely. It helps pinpoint exactly where slow queries come from in the code, so you can fix the real cause instead of guessing. Tuning MySQL + knowing which part of your code triggers bad queries = real, measurable performance.

Si cela fonctionne la 2ème fois cela peut être causé par un timeout car supprimer le cache est souvent long. Ca arrive souvent en fait; personnellement je fais F5 pour relancer le nettoyage jusqu'à ce que l'erreur disparait.

I just discover this post, sorry. In order to reduce the disk space consumption of the cache I recommend running a purge periodically (every 2 or 3 days). A purge deletes the cache of pages that no longer exist or whose context no longer exists. This does not affect cache performance. You can perform a purge manually via a button below the cache statistics table, or by scheduling a CRON job with the URL displayed in the "API (CRON URLs)" menu of the module configuration. When you have no choice you can reset the cache like this: TRUNCATE TABLE jm_pagecache; TRUNCATE TABLE jm_pagecache_contexts; TRUNCATE TABLE jm_pagecache_details; TRUNCATE TABLE jm_pagecache_bl; TRUNCATE TABLE jm_pagecache_mods; You can also safely delete files in /var/cache/pagecache Be aware that this is not to do periodically, only if you are blocked.

You could try this: if (defined('_PS_ADMIN_DIR_')) { define('_PS_DEBUG_PROFILING_', true); } But you will get all profiling informations on each page in the admin. It's not a good solution. 😞

Bonjour à tous, désolé je n'avais pas vu les derniers messages sinon je vous aurai répondu et apporté plus de précisions. Le module continue d'évoluer et est toujours activement maintenu. Il a connu plusieurs versions majeures depuis 2019 dont la version 8 qui propose un cache static (plus de chargement de Prestashop) encore plus rapide qu'en version 7! Beaucoup d'améliorations ont été apportées notamment sur la taille en base de données. Concernant le score Page Speed Insight ou GTMetrix sachez que le TTFB (amélioré par le module) n'est qu'une partie infime du score calculé. Pour plus d'info sur comment améliorer votre score Page Speed Insight sur Prestashop je vous recommande de lire mon article : https://jpresta.com/fr/blog/post/4-pagespeed-gtmetrix-prestashop En cas de problème je suis toujours prompt a répondre (Temps de réponse moyen : 10 heures d'après Addons mais c'est beaucoup plus rapide si on ne compte que les jours ouvrés). Si j'ai toujours autant d'utilisateurs c'est parce qu'ils sont toujours impressionnés par le gain de vitesse! Alors oui, parfois cela ne fonctionne pas bien sur certaines boutiques mais cela reste très rare et dans ces cas là je rembourse bien sûr. Dernière chose, pour éviter que les visiteurs affichent une page dont le cache n'est pas disponible j'ai mis au point un service de cache-warmer qui permet de générer le cache des pages automatiquement : https://jpresta.com/fr/cache-warmer-prestashop A bientôt!

I recommend enabling CCC for JS and CSS to reduce the number of HTTP requests done by the browser, it also reduces the size of the content to download. You don't need it only if your server uses HTTP 2 protocol.

Ca dépend de ce que tu veux vraiement faire: 1) Réduire la taille en terme de largeur x longueur Dans "Apparence" > "Images" tu peux modifier les formats d'affichage des images sans modifier les images originales, tu peux ensuite regénérer les miniatures 2) Réduire la taille en Mo (poids) Tu peux installer un module de compression WEBP qui va réduire le poids des images en conservant leur qualité (tu peux régler le degré de compression)

Bonjour! Quelle est l'URL du site pour qu'on puisse tester?

Sur Prestashop c'est compliqué voire impossible de réduire le CSS ou le Javascript au strict minimum sachant qu'il y a des modules et des thèmes indépendants qui doivent fonctionner ensemble. Tu peux cependant corriger le problème de polica de caractère qui est important facilement: https://web.dev/font-display/ Réduit au mximum les widgets de réseaux sociaux. Si tu veux simplement afficher un lien vers ton facebook/insta/twitter/etc. alors ajoute juste un lien avec une icone, pas tout le javascript qui va avec. Bon courage.

En 1.6.x tu ne dois pas dépasser PHP 7.1: https://devdocs.prestashop.com/1.7/basics/installation/system-requirements/ Cependant cela ne garanti pas la compatibilité des modules, uniquement du coeur de Prestashop. Si tu as des vieux modules mieux vaut demander aux développeurs s'ils sont compatibles avec PHP 7.1. Je ne suis pas d'accord avec @doekia en passant de PHP 5 à PHP 7 tu auras déjà un gain de performance. Pour MySQL je ne pense pas que tu gagneras beaucoup par contre.

I have Prestashop 1.7.4.4 and I'm using Paypal module 4.4.6 from Prestashop. I refunded a customer that need an invoice to register this refund in his accounting. When I display the invoice it shows the initial invoice without any refund notification which is logical, but I don't find any button or link to generate an invoice for this refund, any idea?

I remember having this problem with a customer. It looks like the colors are not always set and so the cache is empty. The solution was to disable the use of the cache in FrontController in method addColorsToProductList.