david.

Bonjour, Peut-être lié à composer: https://securityaffairs.co/wordpress/117366/security/php-composer-flaw.html?utm_source=rss&utm_medium=rss&utm_campaign=php-composer-flaw David.

Bonjour @cedib La lenteur n'est pas liée à la modification, car il désactive des choses, il n'en ajoute pas. Je pense que c'est dû à l'hébergement lui même, j'ai constaté des grosses lenteurs sur le cluster 28, qui au départ tournait bien avec le sql privé. Très franchement, si vous souhaitez héberger du prestashop chez ovh, il faudrait un VPS ou dédié avec plesk dessus, tout en acceptant que vous devrez attendre 10-15 jours en cas de soucis, à moins de prendre le support VIP. Pour mes nouveaux prestashop je vais chez o.......h (pas ovh), étant donné que j'ai signalé le problème il y a plusieurs mois et qu'il n'est pas toujours pas résolu. David.

Bonjour, Même problème avec Prestashop 1.7.6.5, sur ovh performance 1, cluster 028. La solution, dans le fichier : /vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Csrf/Type/FormTypeCsrfExtension.php Ajouter le return; dans : public function buildForm(FormBuilderInterface $builder, array $options) { return; if (!$options['csrf_protection']) { return; } ——— Puis, mettre $defaultEnabled = false au lieu de true : public function __construct(CsrfTokenManagerInterface $defaultTokenManager, $defaultEnabled = false, $defaultFieldName = '_token', T ——— Puis dans le fichier : /src/PrestaShopBundle/EventListener/TokenizedUrlsListener.php Ajouter return; comme ceci : public function onKernelRequest(GetResponseEvent $event) { $request = $event->getRequest(); return; if (TokenInUrls::isDisabled()) { return; } ——— Edité : ajout de ceci : Pour éviter une erreur « This form should not contain extra fields » lors de la création / modification de catégories, modifier dans le fichier : /vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Validator/Constraints/FormValidator.php Vers la ligne 130, juste après //Mark the form with an error if it contains extra fields, ajouter /* et après } ajouter */ pour obtenir quelque chose comme ceci : // Mark the form with an error if it contains extra fields /* if (!$config->getOption('allow_extra_fields') && \count($form->getExtraData()) > 0) { $this->context->setConstraint($formConstraint); $this->context->buildViolation($config->getOption('extra_fields_message')) ->setParameter('{{ extra_fields }}', '"'.implode('", "', array_keys($form->getExtraData())).'"') ->setInvalidValue($form->getExtraData()) ->setCode(Form::NO_SUCH_FIELD_ERROR) ->addViolation(); } */ Pour moi ça a fonctionné. Gardez bien une copie des fichiers originaux avant modification. David.

Bonjour, Merci pour ce signalement. Hors répertoire /modules/ j'ai trouvé ce répertoire en rapport avec PhpUnit sur un prestahsop 1.7, est-ce aussi impacté ? RACINE_PRESTASHOP/vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit A bientôt.

Bonjour, Peux-Être que tu es en PHP 7.3 auquel cas il faut passer en PHP 7.2 et réessayer. David.

Bonjour, J'ai remarqué qu'en utilisant PHP 7.3, il y a un problème avec les frais de port, sur le récapitulatif de droite, et dans le paiement PayPal par exemple : les frais de port sont ignorés. J'ai contourné le problème en utilisant PHP 7.2, pour information à ceux qui n'arrivent pas à trouver l'origine du problème. David.

Le problème n'apparait plus après mise à jour vers 1.6.1.2. David.

Pour info mon problème ne survient que sur une vm debian 8 proxmox 4 (format LXC). Le problème ne survient pas sur une debian 8 sur vmware. David.

Hi, I have found a solution. 1/ You have to see in mysql the table smarty and add a date in the past (see attachement picture). Choose to never recompile template, and never empty the cache. You will have to do this 1/ each time. See here : https://www.prestashop.com/forums/topic/479112-comportement-bizarre-de-smarty-cache/ David.

Bonjour, J'ai trouvé une solution temporaire, solution bizarre à problème bizarre. Il faut utiliser la table ps_smarty_last_flush Mais la petite astuce pour que ca fonctionne : 1/ Cocher ne jamais recopier les fichiers de template Cache : Oui, sur système de fichier, Vider le cache : Ne jamais vider les fichiers du cache. 2/ Vider le cache via le menu paramètres avancés, performance, 3/ le plus important : sur la table ps_smarty_last_flush modifier les dates et mettre des dates du passé, par exemple 1 mois avant. Et là ça fonctionne. C'est à mon avis un problème de zone GMT php qui est comparé à la date du fichier du serveur physique. Merci pour la piste ! Un bug à corriger pour les dev prestashop. 300 ms au lieu de 2 secondes c'est appréciable. David.

Bonjour, J'ai trouvé une solution car j'avais le même problème. Il faut effectivement utiliser la table ps_smarty_last_flush Elle était bien présente. Mais la petite astuce pour que ca fonctionne : 1/ Cocher ne jamais recopier les fichiers de template Cache : Oui, sur système de fichier, Vider le cache : Ne jamais vider les fichiers du cache. 2/ Vider le cache via le menu paramètres avancés, performance, 3/ le plus important : sur la table ps_smarty_last_flush modifier les dates et mettre des dates du passé, par exemple 1 mois avant. Et là ça fonctionne. C'est à mon avis un problème de zone GMT php qui est comparé à la date du fichier du serveur physique. Merci pour la piste ! Un bug à corriger pour les dev prestashop. 300 ms au lieu de 2 secondes c'est appréciable. David.

Bonjour, Je suis sous prestashop 1.6.1.1 et j'ai un soucis avec smarty cache : il ne s'active pas correctement. Le dossier /cache/smarty/compile ne contient que 1 à 2 dossiers du genre 94, b5 et qui disparaissent et réapparaissent toutes les secondes (j'ai l'interface d'admin ouverte). Le dossier /cache/smarty/cache c'est pareil, il n'y a qu'un dossier : homeslider au lieu de plein de dossiers. Le cache est bien activé et le soucis c'est que tel quel le site fonctionne comme si il n'avait pas de cache activé : 2 secondes de chargement, au lieu de 300 à 400 ms. Auriez-vous une piste, c'est plus que bizarre. Je précise que j'ai fait une mise à jour automatique depuis 1.6.0.5 et que je n'ai rien remarqué d'anormal, sauf que quelques jours plus tard, le site est devenu lent sans rien faire. Un autre utilisateur, anglophone semble avoir le même soucis : https://www.prestashop.com/forums/topic/472207-smarty-cache-issue-after-upgrade-to-1611-help-pls/?do=findComment&comment=2176155 Merci pour votre aide si vous avez un début de piste. David. --------- Version de PrestaShop 1.6.1.1 URL de votre boutique http://192.168.0.51/ Nom du thème utilisé theme1112 Version de MySQL 5.5.46-0+deb8u1 Serveur MySQL localhost Nom MySQL prestashop Utilisateur MySQL pshop Préfixe des tables ps_ Moteur MySQL InnoDB Informations sur votre serveur Linux #1 SMP Mon Oct 5 18:23:31 CEST 2015 x86_64 Version du logiciel serveur Apache Version de PHP 5.6.13-0+deb8u1 Limite de mémoire 128M Temps d'exécution maximal (max_execution_time) 600

Hi, Same issue for me. Have you find a solution ? There is only one or two directory on /cache/smarty/cache So, this is a big problem : the website front office is very slow, as it don't use the smarty cache Thanks, David.

Bonjour, Quittez paypal, qui est plus du côté de l'acheteur que du commerçant, d'autant plus que les messages sont envoyés quasi par des robots (il ne faut pas sortir de St Cyr pour comprendre que le suivi n'est plus valide à partir de 30 jours, et donc au pire PayPal devrait demander au commerçant un papier de suivi interne qui sort du bureau de Poste par exemple, qui n'est pas limité dans le temps, ou mieux encore le demander eux même en bureau de Poste, je pense qu'ils ont les moyens humains) et essayez ComNpay c'est la meilleure chose que vous puissiez faire. Je ne propose plus paypal sur mon site et il ne manque pas à grand monde. David.

Je ne connaissais pas le module cronjob : après vérification, il n'est pas activé. Ce n'est donc pas lui le fautif. Une autre idée ?