JPresta Speed Pack

Ces faux utilisateurs sont créés par Page Cache Ultimate pour anonymiser le cache (nouvelle méthode). Vous ne devez pas les supprimer (ils seront re-créés).

Il n'y en aura pas beaucoup, probablement moins de 5, cela dépend du nombre de groupe et des différences d'affichages qui existent entre eux.

Ils sont inactifs donc ils ne perturberont pas vos statistiques.

Si vous avez un thème Anvato voici la correction à apporter pour ne plus que le panier s'ouvre à chaque fois qu'il est rafraichi.

Copiez le fichier /modules/an_theme/views/js/sidebarcart.js dans votre thème pour que vous puissiez continuer à mettre à jour le module sans perdre la modification, dans /themes/<votre_theme>/modules/an_theme/views/js (créez l'arborescence si nécessaire)

Dans ce fichier, remplacez la ligne:

if (prestashop.page.page_name != 'cart' && prestashop.page.page_name != 'checkout') {

Par

if (prestashop.page.page_name != 'cart' && prestashop.page.page_name != 'checkout' && requestData.action!='refresh') {

Videz le cache dans la page Performances et le cache de votre navigateur pour tester.

Si votre thème utilise la balise "widgetblock" comme le fait le thème Warehouse, il est nécessaire de vider le cache dans la page Performances après avoir activé Page Cache afin que le template soit re-compilé.

Si vous utilisez Nginx, assurez vous d'avoir cette configuration:

"Proxy mode" doit être activé, les autres options doivent être désactivées.

Si vous utilisez le module Apache PageSpeed développé par Google (x-mod-pagespeed), vous devez désactiver l'option suivante afin qu'elle ne remplace pas les directives de cache du navigateur ajoutées par Page Cache :

<IfModule pagespeed_module>
ModPagespeedModifyCachingHeaders off
</IfModule>

Non, il est fortement recommandé de garder le cache Smarty activé. Cela accélérera les pages qui ne sont pas mises en cache et aussi les pages où le cache n'est pas encore généré.

Pour récupérer vos styles, il vous suffit de vider le cache de "Page Cache Ultimate".

Pour éviter ce problème, vous pouvez aller dans le "Mode avancé", dans la configuration de "Page Cache Ultimate", puis dans "Clé de cache" activer "Insérer la version CSS et JS dans la clé de cache".

Pour éviter l'affichage de la notification des cookies pendant 1 seconde, vous devez remplacer le fichier javascript du module iqitcookielaw.

Pour ce faire, créez un fichier avec le contenu suivant:

$(document).ready(function () {
 if (getCookie('cookielaw_module') != 1) {
  $("#iqitcookielaw").addClass('iqitcookielaw-showed');
 }
 $("#iqitcookielaw-accept").click(function (event) {
  event.preventDefault();
  $("#iqitcookielaw").removeClass('iqitcookielaw-showed');
  setcook();
 });
});

function setcook() {
 var name = 'cookielaw_module';
 var value = '1';
 var today = new Date();
 var expire = new Date();
 expire.setTime(today.getTime() + 3600000 * 24 * 14);
 document.cookie = name + "=" + escape(value) + ";path=/;" + ((expire == null) ? "" : ("; expires=" + expire.toGMTString()))
}

function getCookie(cname) {
 var name = cname + "=";
 var ca = document.cookie.split(';');
 for (var i = 0; i != ca.length; i++) {
  var c = ca[i];
  while (c.charAt(0) == ' ') c = c.substring(1);
  if (c.indexOf(name) != -1) return c.substring(name.length, c.length);
 }
 return "";
}

Et placez le dans votre thème (ou thème enfant si vous en avez un): /themes/warehouse/modules/iqitcookielaw/views/js/front.js

Enfin, videz le cache dans la page Performances.

Lorsque le cache est créé, la page est anonymisée, c'est-à-dire qu'elle est affichée sans aucune information concernant le visiteur qui affiche la page.

Les modules qui affichent un contenu relatif au visiteur actuel peuvent être marqués comme dynamiques, ce qui signifie que le contenu sera rafraîchi (remplacé) dans le navigateur par une requête en arrière-plan (Ajax) qui contiendra le contexte du visiteur actuel.

Si vous cochez l'option "Ne rien afficher dans le cache", le module ne sera pas exécuté pour afficher son contenu dans ce hook lors de la création du cache. Par contre, le contenu sera affiché comme les autres modules dynamiques (avec une requête en arrière plan (Ajax)).

Si la liste des produits est rechargée chaque fois que vous affichez une page contenant une liste de produits, vous pouvez résoudre ce problème en modifiant le fichier /warehouse/modules/ps_shoppingcart/ps_shoppingcart.js comme ceci:

Remplacez ceci:

prestashop.emit('updateFacets', window.location.href);

Par ceci:

if (event.reason && event.reason.linkAction != 'refresh') {

    prestashop.emit('updateFacets', window.location.href);

}

Mettez à jour votre module "Cookies - GDPR Cookie law (bloc avant consentement)" en version 1.5.6 minimum.

Mettez à jour "Page Cache Ultimate" en version 7.9.39 minimum pour une compatibilité totale avec le module cookiesplus.

Pour Prestashop 1.7

1. Désactivez les 2 modules (cela fonctionne aussi s'ils ne sont pas encore installés)
2. Dans le fichier /modules/cookiesplus/override_17/classes/Hook.php renommez la fonction coreCallHook en coreCallHook_off et la fonction coreRenderWidget en coreRenderWidget_off (en effet, Page Cache Ultimate exécutera les traitements adéquats si le module cookiesplus est activé).

Vous pouvez réactiver (ou installer) les 2 modules.

Si après l'installation du module certaines images de votre boutique ne s'affichent plus comme le logo, les images des pages CMS, les images dans le backoffice, etc. c'est probablement à cause d'un fichier .htaccess dans le répertoire /img et /img/cms. Celui-ci bloque tout script PHP, même s'il s'agît d'une redirection (le script n'est pas réellement dans ce répertoire).

Pour corriger ce problème il faut ajouter une exception pour notre convertisseur webp.php comme ceci:

<IfModule mod_php5.c>
    php_flag engine off

    # Enable PHP only for webp.php (Speed Pack)
    <Files "webp.php">
        php_flag engine on
    </Files>
</IfModule>

# Apache 2.2
<IfModule !mod_authz_core.c>
    Order deny,allow
    Deny from all
    <Files ~ "webp.php|(?i)^.*\.(jpg|jpeg|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|ico|webp)$">
        Allow from all
    </Files>
</IfModule>

# Apache 2.4
<IfModule mod_authz_core.c>
    Require all denied
    <Files ~ "webp.php|(?i)^.*\.(jpg|jpeg|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|ico|webp)$">

        Require all granted
    </Files>
</IfModule>

Ou pour /img/cms/.htaccess

<IfModule mod_php5.c>
    php_flag engine off

    # Enable PHP only for webp.php (Speed Pack)
    <Files "webp.php">
        php_flag engine on
    </Files>
</IfModule>

# Enable webp.php (Speed Pack)
<Files "webp.php">
    Order allow,deny
    Allow from all
</Files>

deny from all
<Files ~ "(?i)^.*\.(jpg|jpeg|gif|png|bmp|tiff|svg|pdf|mov|mpeg|mp4|avi|mpg|wma|flv|webm|webp)$">
	order deny,allow
	allow from all
</Files>

Dans la configuration du panier, dans la section "Action d'ajout au panier", désactivez l'option "Ouvrir le panier".

Oui, toutes les images de votre boutique seront automatiquement converties au format WEBP. Même les images du CMS ou d'autres modules comme le blog.

C'est normal, lorsque le cache n'est pas disponible l'affichage est aussi lent que sans le cache.

Il ne faut vider le cache que lorsque cela est nécessaire (modification de CSS ou de Javascript, pour les templates choisissez l'option "Recompiler les fichiers de templates s'ils ont été mis à jour" dans la page "Performances").

OUI, vous avez toujours besoin d'un module WEBP pour Prestashop ! Parce que cette fonctionnalité présente un bug dans PS 8.0. Il devrait être corrigé dans PS 8.1 mais je vérifierai cela dès sa sortie car je ne sais pas si les images JPG seront affichées sur les navigateurs qui ne peuvent pas lire le format WEBP comme Safari (iPhone).

Il a été très difficile de trouver une configuration qui fonctionne bien. Je ne suis pas expert dans la configuration de nginx donc je suppose qu'il y a une autre façon de faire. Si vous souhaitez améliorer cette configuration, contactez-moi, je serai heureux de mettre à jour cet article pour aider d'autres personnes !

Voici ma solution (soyez gentil).

Avant la section "server", placez ce code :

map $http_accept $webp_enable {
	default 0;
	"~*webp" 1;
}

Il nous dira si le navigateur du visiteur peut lire les images WEBP.

Vous avez probablement plusieurs lignes de "rewrite" pour toutes les images, placez le code suivant juste avant :

# Jpresta Speedpack
if ($webp_enable = 1) {
	# Rewrite images URL using a specific extension ".webp_compressor" so we can have specific rules to compress the image/svg
	# if the webp file is not already created.
	rewrite "^/c/([0-9]+)(\-[_a-zA-Z0-9-]*)/(.*)\.(jpg|jpeg|png)$" /img/c/$1$2.webp_compressor last;
	rewrite "^/c/([_a-zA-Z-]+)/(.*)\.(jpg|jpeg|png)$" /img/c/$1.webp_compressor last;
	rewrite "^/([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$1$2.webp_compressor last;
	rewrite "^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$1$2$3.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$1$2$3$4.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$1$2$3$4$5.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.webp_compressor last;
	rewrite "^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/(\P{M}\p{M}*)*\.(jpg|jpeg|png)$" /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.webp_compressor last;
	# all other images
	rewrite "^(.+)\.(jpg|jpeg|png)$" $1.webp_compressor last;
}

location ~* ^(.+)\.webp_compressor$ {
	# Indicates to proxies that the file content/format depends (Vary) on the "Accept" header
	add_header Vary Accept;

	# Indicates to proxies that the file can be cached for the max duration
	add_header Pragma public;
	add_header Cache-Control "public, must-revalidate, proxy-revalidate";
	expires max;

	# Indicates to nginx not to log access
	access_log off;
	log_not_found off;

	# Try to serve the WEBP file directly or compress the image
	set $url_webp_compressor "/modules/jprestaspeedpack/controllers/front/webp.php?src=$1.jpg";
	try_files $1.webp $url_webp_compressor;
}

ATTENTION : si vous utilisez le module de compression WEBP autonome alors vous devez remplacer 'jprestaspeedpack' par 'jprestawebp'.

Contactez-moi si vous avez besoin d'aide ou si vous pouvez améliorer le script !

Si la liste de sélection de la monnaie/devise ne fonctionne plus, vérifiez ces 2 options:

L'option "Ignore URLs matching this regex" doit inclure ".*SubmitCurrency=1.*", par exemple : ".*[\?&]q=.*|.*SubmitCurrency=1.*"

L'option "Ignored URL parameters " ne doit pas inclure "submitcurrency,id_currency"

Vous souhaiterez peut-être également désactiver le cache du navigateur, car si le visiteur change de devise après avoir affiché plusieurs pages, s'il revient sur ces pages, la devise initiale s'affichera.

N'oubliez pas de vider le cache du module et du navigateur après ces modifications.

oui, les navigateurs qui ne peuvent pas lire le format WEBP obtiendront le format original (JPG/PNG).

Lorsque vous modifiez un produit, une catégorie, une page CMS, un prix, le stock, etc. le cache est automatiquement rafraîchi.

Lorsque vous ajoutez, supprimez ou modifiez un module, vous devez vider le cache manuellement car cela ne peut pas être détecté automatiquement. Par exemple, lorsque vous modifiez le slider de la page d'accueil.

Lorsque vous modifiez le CSS ou un template de votre thème, alors vous devez vider le cache manuellement car cela ne peut pas être détecté automatiquement.

Lorsque vous synchronisez ou modifiez votre catalogue, vos prix et/ou vos stocks à l'aide d'une application externe, vous devrez probablement vider le cache manuellement ou avec un script car les hooks de Prestashop ne sont pas exécutés.

Pour vider le cache de pages spécifiques, vous pouvez utiliser les URL CRON/API que vous trouverez dans le menu "API" de la configuration de Page Cache Ultimate. Vous pouvez également utiliser le tableau des statistiques pour filtrer les pages que vous souhaitez actualiser, puis cliquer sur le bouton "Vider le cache (fichiers uniquement)".

Sachez également que le cache du navigateur ne peut pas être vidé, c'est pourquoi il est limité dans le temps.

Cela se produit parce que le lien de connexion est chargé dynamiquement et que le paramètre "back" qui renvoie à l'URL actuelle est défini avec l'URL des modules dynamiques.

Pour éviter ce problème, allez dans la configuration de Page Cache Ultimate, dans le menu "Dynamic modules and widgets", en bas ajoutez le code javascript suivant dans le champ "Javascript à exécuter" :

if (!prestashop_pc.customer.is_logged) {
 $('header a').each(function() {
 $(this).attr('href').replace('ajax%3Dtrue', '').replace('page_cache_dynamics_mods%3D=1', '')
 }) ;
}

Videz le cache et le problème devrait être résolu.

ces répertoires sont créés lorsque le cache ne peut pas être entièrement supprimé en PHP parce qu'il est trop long et qu'il échouera avec une erreur de temporisation. Ainsi, au lieu de supprimer le répertoire de cache, il est simplement renommé avec ce suffixe.

Vous pouvez supprimer tous ces répertoires avec le suffixe please_delete_me mais je recommande de le faire directement dans une console de serveur car il sera trop long de le faire par FTP.

Ces hooks sont destinés aux développeurs de modules, contactez le support si vous avez besoin d'aide.

Voici un exemple de la façon d'implémenter les fonctions des hooks :

    /**
     * Called each time a page is displayed so this must remain very fast!
     * @param $params Empty array
     * @return mixed The datas you will need in hookActionJPrestaRestoreSpecificCacheKeyInfos()
     */
    public function hookActionJPrestaGetSpecificCacheKeyInfos($params) {
        // Let's say that the cookie 'test' modify the content of the page, we indicates to the cache manager
        // to generate a cache key that depends on the value of this cookie
        return $_COOKIE['test'];
    }

    /**
     * This function is called by Page Cache Ultimate when the cache-warmer service want to generate the cache of a
     * specific context. In this case we must restore the context so the content is the good one.
     * @param $params $params['specifics'] contains the datas returned by the hook 'ActionJPrestaGetSpecificCacheKeyInfos'
     */
    public function hookActionJPrestaRestoreSpecificCacheKeyInfos($params)
    {
        // Here we will just modify the $_COOKIE value, we don't need to send the cookie to the browser with function
        // setcookie, we just want the remaining PHP code to execute to get the correct value of the cookie.
        $_COOKIE['test'] = $params['specifics'];
    }

Le module Creative Elements permet d'éditer des parties de votre boutique avec des liens/boutons directement affichés sur celle-ci lorsque vous êtes connecté à l'admin de votre Prestashop. Pour conserver cette fonctionnalité le cache est désactivé avec la raison "editing-with-creative-element". Rassurez vous, vos visiteurs bénéficient bien du cache, ce sont uniquement les utilisateurs connectés à l'admin qui n'ont pas de cache. Pour avoir le cache il vous suffit d'afficher la boutique dans un onglet privé du votre navigateur.

La première chose à faire est de s'assurer d'avoir la dernière version du module car je l'améliore constamment pour réduire sa consommation mémoire, que ce soit du côté de la base de données ou du disque dur.

La deuxième chose est d'exécuter une purge périodiquement (tous les 2 ou 3 jours). Une purge supprime le cache de pages qui n'existent plus ou dont le contexte n'existe plus. Cela n'affecte pas les performances du cache. Vous pouvez effectuer une purge manuellement via un bouton sous le tableau de statistiques du cache, ou en programmant une tâche CRON avec l'URL affichée dans le menu "API (CRON URLs)" de la configuration du module.

Enfin s'il existe des répertoires dans /var/cache/pagecache qui se terminent par "please_delete_me" alors vous pouvez les supprimer. Il s'agit d'ancien cache que PHP n'a pas réussi à supprimer entièrement (trop long).

Le module n'appelle pas le Hook qui permet la mise à jour.

Il faut modifier la fonction imageResize() du fichier /modules/prestablog/prestablog.php : 

Remplacer ceci

        return ImageManager::write('jpg', $dest_image, $fichier_apres);

Par ceci

        $ret = ImageManager::write('jpg', $dest_image, $fichier_apres);

        Hook::exec('actionOnImageResizeAfter', ['dst_file' => $fichier_apres, 'file_type' => 'jpg']);

        return $ret;

​​Après vos images seront bien mises à jour.

​

Le cache statique ne peut être utilisé que si l'on connait le contexte dans lequel se trouve le visiteur. Le contexte contient plusieurs informations qui ne peuvent pas être déduites uniquement de l'URL: la devise, les groupes utilisateurs, le choix des cookies, les taxes à appliquer, etc.

Ce contexte est enregistré dans un cookie nommé "jpresta_cache_context" qui est ajouté lorsque l'utilisateur affiche une 1ère page. Une fois le cookie présent le cache statique peut-être utilisé.

Allez dans la configuration du module, dans le menu "Système de cache" assurez-vous que "Prestashop Static!" est sélectionné. Si il est déjà coché, sélectionnez "Système de fichiers standard" et enregistrez, puis sélectionnez "Prestashop Static!" et enregistrez à nouveau. Cela réactivera le cache statique.

Le message "customer-specific-prices" signifie que vous êtes connecté avec un utilisateur qui a des règles de prix spécifiques, il est donc inutile de créer un cache puisque seul lui pourra en bénéficier. Il est préférable de créer des groupes d'utilisateurs et de créer des règles de prix pour ces groupes.

Peut-être que vous simulez un écran de téléphone en utilisant la console de votre navigateur, ce qui explique pourquoi vous voyez cette vue mobile malgré un écran de bureau.

Cela se produit parce qu'un cookie appelé 'jpresta_cache_context' stocke le contexte du visiteur dans le navigateur. Ce contexte inclut des informations sur si la vue est 'mobile' ou 'desktop'. Par conséquent, si vous consultez d'abord des pages en mode bureau puis passez en mode mobile, le cache continuera à fournir la vue bureau.

Si vous souhaitez tester la vue mobile en utilisant la console de votre navigateur, assurez-vous de supprimer le cookie 'jpresta_cache_context' au préalable.

Non, le module ne convertit que les images JPG/PNG en format WEBP. Il est recommandé d'importer les images en JPG car certains navigateurs ne peuvent toujours pas charger les fichiers WEBP. De plus, je pense que les JPG sont meilleurs en tant qu'images d'origine car Prestashop crée plusieurs formats/tailles d'images, c'est pourquoi l'image d'origine doit être de bonne qualité.

Si vous utilisez le module "Google Tag Manager Enhanced Ecommerce" créé par "Comptoir du code", assurez-vous d'obtenir la dernière version du module et d'activer l'option spécifique pour l'utilisation avec les modules de cache pleine page.

Dans tous les cas, il n'est pas nécessaire de marquer les modules Google Tag Manager comme dynamiques.

Les scores calculés par Pagespeed et GTMetrix incluent un très grand nombre de paramètres dont l'importance varie selon que vous êtes sur téléphone mobile ou sur ordinateur.

Le module Prestashop Speed Pack permet de corriger les points suivants remontés par Pagespeed Insight ou GT Metrix:

• Réduire les temps de réponse du serveur (TTFB)
• Servir des images dans des formats de nouvelle génération
• Différer les images hors écran

D'autres paramètres comme le LCP ne peuvent pas être corrigés par un module. Par exemple, ce LCP indique le délais d'affichage de l'élément le plus large affiché en premier; il est souvent dégradé par l'utilisation d'un carousel qui affiche les images en chargement différé ou bien parce que le code javascript qui l'initialise est trop lent. Ce genre de problème ne peut être corrigé que manuellement.

Aussi, pour être sûr que le calcul du score a été fait avec un cache disponible, lancez le 2 fois.

Je vous invite à lire mon article pour bien comprendre ce score Pagespeed pour Prestashop .

Lorsque vous validez les étapes de configuration, assurez-vous d'exécuter la configuration automatique à l'étape 4. Cela configure le module Page Cache Ultimate pour tous les modules connus comme le panier. Vous devez vous fier à cette configuration automatique et effectuer des modifications manuelles uniquement lorsque quelque chose ne fonctionne pas comme d'habitude lorsque le cache est activé.

Le score calculé par Pagespeed et GTMetrix intègre un très grand nombre de paramètres dont l'importance varie selon que vous êtes sur un téléphone mobile ou sur un ordinateur.

Le module Prestashop Speed ​​Pack permet de corriger les points suivants signalés par Pagespeed Insight ou GT Metrix :

• Réduire les temps de réponse du serveur/TTFB  (Page Cache Ultimate)
• Diffusion d'images dans des formats de nouvelle génération (compression WEBP des images)
• Différer les images hors écran (chargement paresseux des images)

Les autres paramètres comme le LCP ne peuvent pas être corrigés par un module. Par exemple, ce LCP indique le retard d'affichage du plus gros élément affiché en premier ; il est souvent dégradé par l'utilisation d'un carrousel qui affiche des images grâce à un système de chargement paresseux ou parce que le code javascript qui l'initialise est trop lent. Ce type de problème ne peut être résolu que manuellement.

De plus, pour être sûr que le calcul du score a été effectué avec un cache disponible, exécutez-le deux fois.

Je vous invite à lire mon article Comprendre et améliorer le score Pagespeed de votre boutique Prestashop  

Une page peut avoir plusieurs versions en cache en fonction du contexte du visiteur. Ce contexte inclut des informations telles que la devise sélectionnée, le groupe de l'utilisateur, les préférences du visiteur concernant les cookies, les règles fiscales appliquées pour ce visiteur, le pays du visiteur si pertinent, etc. Par conséquent, vous pourriez ne pas recevoir la page en cache lorsque vous affichez une page parce que votre contexte est différent.

Des modules comme "Creative Slider" utilisent des codes courts (shortcodes) pour faciliter l'affichage du contenu. Cela se fait généralement dans le point d'accroche "actionOutputHTMLBefore", il faut donc s'assurer que le module de cache est placé après tous les modules de ce point d'accroche. Allez dans "Apparence" > "Positions", cochez l'option "Afficher les points d'accroche invisibles", recherchez le point d'accroche "actionOutputHTMLBefore" et déplacez Page Cache Ultimate ou le module Speed Pack à la fin.

Une fois que c'est fait vous devez vider le cache.

Cette erreur est due à une nouvelle restriction de sécurité mise en place par mon hébergeur (OVH) sur tous leurs serveurs.

Pour la résoudre, vous devez mettre à jour mes modules vers la dernière version.

Vous ne pourrez pas le faire en utilisant le module JPresta Easy Upgrade, car celui-ci nécessite également une mise à jour.

Pour effectuer la mise à jour, passez par les Addons ou téléchargez le fichier zip depuis votre compte JPresta. Pour Page Cache Ultimate et Speed Pack, vous devrez extraire le zip pour trouver celui qui correspond à votre version de PrestaShop. Une fois que vous avez le bon fichier zip, installez-le comme un nouveau module pour mettre à jour votre version actuelle tout en préservant la configuration.

Ne vous inquiétez pas, après cela, vous pourrez continuer à faire les mises à jour avec JPresta Easy Upgrade comme d’habitude.