Sortie de la version 1.6.1.28 - By @Eolia

[Eolia]

Ok, et avez-vous un message d'erreur un peu plus précis dans le fichier error.log de votre serveur ? (n° de la ligne ou détail de l'erreur)

[P i l o u]

Non, je ne trouve pas de error.log dans le dossier php alors que l'option "display_errors" est sur On et "error_log" est sur /php/

[P i l o u]

Il y a 4 heures, Eolia a dit :

Pour le menu, ce sera réglé dans la prochaine version. Si vous voulez le corriger en attendant il faut modifier cette ligne dans admin-theme.css

.page-sidebar-closed #nav-sidebar>ul>li.maintab:hover ul.submenu{position:absolute !important;display:block !important;top:34px !important;width:200px !important;left:50px}

en remplaçant 34 par 29

.page-sidebar-closed #nav-sidebar>ul>li.maintab:hover ul.submenu{position:absolute !important;display:block !important;top:29px !important;width:200px !important;left:50px}

 

Malgré la modif dans admin-theme.css, j'ai toujours la petite ligne blanche et il est impossible de cliquer sur une ligne du sous-menu (en mode menu etroit), le sous-menu disparait; en mode large, le soucis n'apparait pas.

[Eolia]

Videz votre cache navigateur.

[Eolia]

Celle-là devrait faire plaisir à certains

[Eolia]

La version 1.6.2.9 est sortie 

[Khundo2023]

On 5/12/2023 at 9:53 PM, Eolia said:

La version 1.6.2.9 est sortie 

Bonjour,

Grand merci Eolia, j'ai autoupgrade 1.6.2.8 à 1.6.2.9 ça fonctionne sans erreurs avec tous les modules que vous m'aviez corrigé (paypal, attributs wizar pro...)

[Sda33]

[Edit : résolu en désactivant le module incriminé Prestablog, en recherche pour régler le bug du module]

Bonjour à tous,

Je retrouve enfin un peu de temps pour poursuivre ma migration, ou plutôt pour la reprendre de zéro parce qu'il s'agit maintenant de migrer mon shop historique, donc le plus critique pour moi.

En premier lieu j'ai bien upgradé ma BDD de MySQL 5.7 vers MySQL 8. Pas de souci.

J'ai créé une preprod et je suis passée directement de 1.6.1.24 à 1.6.2.9.

J'ai vidé mon cache navigateur, et j'ai cherché à me connecter au BO de cette preprod, mais je ne passe pas : j'ai bien le formulaire login/mot de passe, mais quand je valide les champs du formulaire disparaissent (il ne reste plus que le nom de mon site dans le bloc). Et je n'accède pas au BO.

J'ai peut-être manqué une info, y a-t-il quelque chose à vérifier en particulier ? Le mode debug est activé mais je n'ai rien.

 

Merci !  

Edited May 20, 2023 by Sda33 (see edit history)

[Sda33]

OK j'ai "résolu" cela venait du module Prestablog.

J'ai renommé le dossier du module et j'ai pu entrer normalement.

J'aimerais bien corriger maintenant, si le bug dit quelque chose à quelqu'un ?

Notice: Indirect modification of overloaded property PrestaBlog::$Configurations has no effect  in /home/xxx/xxx_preprod/modules/prestablog/prestablog.php on line 263 (c'est la dernière du bloc ci-dessous)

// configurations liées aux langues de la boutique
		$languages = Language::getLanguages(true);
		foreach ($languages as $language)
			$this->Configurations[$this->name.'_titlepageblog_'.$language['id_lang']] = $this->l('Blog');

 

Merci !

[Sda33]

(re)

Je rencontre un autre problème : la table ps_paypal_capture n'existe pas, du coup je n'accède pas aux commandes passées en Paypal.

Trapped exception during execution hook displayAdminOrder in module paypal: Table 'ps_paypal_capture' doesn't exist

 

Pourtant sur le premier site sur lequel je travaillais ces dernières semaines et que j'ai pu migrer en 1.6.2.9 je trouve bien cette table. La différence entre les deux c'est que j'ai 0 commande en Paypal sur celui sur lequel ça fonctionne (le site n'est pas encore sorti).

Que puis-je faire pour récupérer cette table et possiblement l'alimenter avec les données de mes commandes existantes ?

Ou bien : puis-je passer outre cette table et contourner le bug en BO ?

Merci pour votre aide.

 

Edited May 20, 2023 by Sda33 (see edit history)

[Eolia]

il y a 52 minutes, Sda33 a dit :

OK j'ai "résolu" cela venait du module Prestablog.

J'ai renommé le dossier du module et j'ai pu entrer normalement.

J'aimerais bien corriger maintenant, si le bug dit quelque chose à quelqu'un ?

Notice: Indirect modification of overloaded property PrestaBlog::$Configurations has no effect  in /home/xxx/xxx_preprod/modules/prestablog/prestablog.php on line 263 (c'est la dernière du bloc ci-dessous)

// configurations liées aux langues de la boutique
		$languages = Language::getLanguages(true);
		foreach ($languages as $language)
			$this->Configurations[$this->name.'_titlepageblog_'.$language['id_lang']] = $this->l('Blog');

 

Merci !

C'est juste une info pour vous dire que le module n'est pas écrit pour PHP 8

Il faut rajouter au dé but de la classe:

public $Configurations;

[Eolia]

il y a 29 minutes, Sda33 a dit :

(re)

Je rencontre un autre problème : la table ps_paypal_capture n'existe pas, du coup je n'accède pas aux commandes passées en Paypal.

Trapped exception during execution hook displayAdminOrder in module paypal: Table 'ps_paypal_capture' doesn't exist

 

Pourtant sur le premier site sur lequel je travaillais ces dernières semaines et que j'ai pu migrer en 1.6.2.9 je trouve bien cette table. La différence entre les deux c'est que j'ai 0 commande en Paypal sur celui sur lequel ça fonctionne (le site n'est pas encore sorti).

Que puis-je faire pour récupérer cette table et possiblement l'alimenter avec les données de mes commandes existantes ?

Ou bien : puis-je passer outre cette table et contourner le bug en BO ?

Merci pour votre aide.

 

Réinitialisez le module, la table devrait se créer.

[Sda33]

5 minutes ago, Eolia said:

Réinitialisez le module, la table devrait se créer.

Merci, mais d'une manière plus générale j'ai l'impression que l'upgrade vers 1.6.2.9 ne s'est pas bien passé, il me manque des tas de nouveaux éléments en BDD, et j'ai des comportements bizarres en BO (du type : juste le bandeau haut s'affiche, je ne suis plus connectée, mais impossible de revenir au formulaire de login).

Je suis retournée sur le module autoupgrade et j'ai réalisé qu'il me demandait une mise à jour (il ne le faisait pas quand je l'ai lancé tout à l'heure) et pour cause j'avais la version 17. J'espère que le problème vient juste de là.

Je vais tout reprendre depuis le début, réinstaller ma preprod, et recommencer. 

[Sda33]

Désolée Eolia, pouvez-vous me confirmer qu'il faut bien la version 19 de l'upgrade pour faire la mise à jour ?

Il ne me la propose pas (cf capture d'écran), du coup je ne sais pas si mon problème initial (tables pas créées, champs manquants dans d'autres tables, ...) vient de là, ou pas. 

[Eolia]

si votre boutique n'est pas déjà en Phenix il ne vous sera pas proposé de mise à jour du module (vos fichiers coeurs ne proposent pas ce code)

La 19 est valable ici: https://devcustom.net/public/scripts/dl.php?f=autoupgrade

Une fois la mise à jour du cœur effectuée, regardez si vous avez des warning dans le log ajax (il faut scroller et remonter dans la fenêtre qui a affiché toutes les étapes)

[Sda33]

1 hour ago, Eolia said:

si votre boutique n'est pas déjà en Phenix il ne vous sera pas proposé de mise à jour du module (vos fichiers coeurs ne proposent pas ce code)

La 19 est valable ici: https://devcustom.net/public/scripts/dl.php?f=autoupgrade

Une fois la mise à jour du cœur effectuée, regardez si vous avez des warning dans le log ajax (il faut scroller et remonter dans la fenêtre qui a affiché toutes les étapes)

Merci beaucoup Eolia, j'ai bien réinstallé ma preprod, téléchargé votre fichier, et malheureusement ça bloque à l'installation. Voilà plus de 10 minutes qu'il tourne en boucle sur la phrase : 

Sauvegarde de la base de données : 262 table(s) restantes...
la table ps_connections a été sauvegardée.
1 tables ont été sauvegardées.
Sauvegarde de la base de données : 262 table(s) restantes...
la table ps_connections a été sauvegardée.
1 tables ont été sauvegardées.
(etc)

C'est frustrant et je ne sais pas si je dois le laisser tourner comme cela.

Y a-t-il la possibilité de migrer en 1.6.2.7 PUIS en 1.6.2.9 ?

 

(pour info depuis l'accueil MODULES j'avais bien l'info que le module d'upgrade était en v19, mais depuis l'upgrade lui-même j'avais toujours en haut du tableau la phrase "Le module de mise à jour en 1 clic est à jour (votre version est v17). )

[Eolia]

Faites une sauvegarde FTP et SQL manuelle (et évitez la table connections sinon vous y serez encore demain sur votre mutu...) et lancez l'upgrade sans sauvegarde

[Sda33]

3 minutes ago, Eolia said:

Faites une sauvegarde FTP et SQL manuelle (et évitez la table connections sinon vous y serez encore demain sur votre mutu...) et lancez l'upgrade sans sauvegarde

Toutes mes excuses, j'étais certaine ne pas avoir coché la sauvegarde (je la fais toujours de mon côté avant). C'est beaucoup mieux sans !!!

Tout va bien donc j'ai pu relancer la mise à jour et cette fois les problèmes BDD ne sont plus. Merci pour votre patience, je vais explorer avant de basculer sur ma prod.

J'en profite juste pour une question : dans les Paramètres avancés/Performances

 SÉCURITÉ DES FICHIERS  Activer la protection contre les attaques + Activer le contrôle d'intégrité

Faut-il dire oui aux deux ? Je suis tentée de le faire sur le premier, mais je ne comprends pas les implications du deuxième.

 

Merci

[Eolia]

il y a 50 minutes, Sda33 a dit :

 

 SÉCURITÉ DES FICHIERS  Activer la protection contre les attaques + Activer le contrôle d'intégrité

Le premier bloque les IP utilisant des requêtes bizarres ou interdites pour 24h.

Le second installe cleaner sur votre shop, rien de plus  

[Mediacom87]

Salut à tous,

Je viens de faire la migration puisqu'il n'est plus possible de faire la moindre mise à jour vers une version officielle PrestaShop sur la branche 1.6 et c'est une bonne chose pour nous.

J'ai basculé en PHP 7.4 et donc corriger pas mal de modules tiers pour les rendre compatibles, la bascule vers PHP8 sera plus complexe, mais la différence de performance est énorme.

On parle d'un shop PS avec plusieurs dizaines de boutiques.

Et bien entendu, le template fonctionne sans problème, pas la peine de programme un changement à ce niveau ce qui est un gros gain pour les utilisateurs.

Merci @Eoliapour ce travail.

Maintenant, il va falloir que je regarde toutes les petites options rajoutées pour savoir ce qu'elles font et comment fonctionne tout cela.

[bobby4722]

Bonjour @Eolia,

Comme je suis en pleine traduction depuis plusieurs semaines et que cela prends un temps fou et des ressources solides (donc puni de mise à jour et toujours en 1.6.1.26), j'avais un plantage qui à toujours été présent avec Google Site Map que j'avais en version peut être 3.2... 

J'ai mis à jours avec votre version du module (la 11) et je me suis aperçu de quelque chose au niveau de l'url de la tache cron. Cela m'indique chez moi https://www.monsite.com//modules.... Je voulais savoir si c'était un coquille le double "//" ?.

En revanche même en ayant passé mon serveur SQL à 4Go de Ram, impossible de générer un sitemap avec les images ni via l'ancienne version, ni via la votre, erreur 500.

Je verrais cela plus tard car je veux avancer sur mes traductions.
 

[Eolia]

Il y a 16 heures, bobby4722 a dit :

J'ai mis à jours avec votre version du module (la 11) et je me suis aperçu de quelque chose au niveau de l'url de la tache cron. Cela m'indique chez moi https://www.monsite.com//modules.... Je voulais savoir si c'était un coquille le double "//" ?.

Le souci est corrigé dans la 12.

Vous pouvez remplacer la ligne 184 par celle-ci:

'gsitemap_cron' => 'http'.(Configuration::get('PS_SSL_ENABLED') ? 's' : '').'://'.str_replace('//', '/', Tools::getShopDomain(false, true).__PS_BASE_URI__._MODULE_DIR_).'gsitemap/gsitemap-cron.php?token='.substr(Tools::encrypt('gsitemap/cron'), 0, 10).'&id_shop='.$this->context->shop->id,

 

Il y a 16 heures, bobby4722 a dit :

En revanche même en ayant passé mon serveur SQL à 4Go de Ram, impossible de générer un sitemap avec les images ni via l'ancienne version, ni via la votre, erreur 500.

Que dit le error.log de votre serveur ? (ou avec le mode debug activé ?)

[bobby4722]

38 minutes ago, Eolia said:

Le souci est corrigé dans la 12.

Vous pouvez remplacer la ligne 184 par celle-ci:

'gsitemap_cron' => 'http'.(Configuration::get('PS_SSL_ENABLED') ? 's' : '').'://'.str_replace('//', '/', Tools::getShopDomain(false, true).__PS_BASE_URI__._MODULE_DIR_).'gsitemap/gsitemap-cron.php?token='.substr(Tools::encrypt('gsitemap/cron'), 0, 10).'&id_shop='.$this->context->shop->id,

 

Que dit le error.log de votre serveur ? (ou avec le mode debug activé ?)

J'ai corrigé la ligne 184 merci.

- J'ai perdu mes sitemap en RO et en SV, ils ne sont pas listés par le module en v11.

- Le mode debug je ne l'ai jamais utilisé mais je suis actuellement entrain de traduire et comme c'est long et le module pro de traduction plante tout le temps (le dev est entrain de faire une grosse mise à jour pour les rebelles de la 1.6 comme nous   ) je n'ai pas envi de risquer de tout planter. Je vais attendre que cela finisse. avec la 1.6.1.26 j'ai 2 cases pas comme dans votre version avec une case générale et en dessous les deux mêmes que sur ma version.

- Par contre j'ai rien de rien au sujet d'un fichier log dans OVH -> Web Cloud Databases ou sinon je ne sais pas où cela se trouve. En revanche je sais que j'ai des saturations de cpu régulierement.

[Eolia]

il y a 5 minutes, bobby4722 a dit :

Par contre j'ai rien de rien au sujet d'un fichier log dans OVH -> Web Cloud Databases ou sinon je ne sais pas où cela se trouve. En revanche je sais que j'ai des saturations de cpu régulierement.

Rien à voir avec les databases mais dans Statistiques & Logs

[bobby4722]

5 minutes ago, Eolia said:

Rien à voir avec les databases mais dans Statistiques & Logs

- Ok bon j'y suis arrivé à voir le fichier. J'ai énormément de lignes avec noté plusieurs fois timeout 160 sec et des choses comme ceci :"AH10149: FastCGI: incomplete headers (0 bytes) received from server" mais je ne sais pas interpreter ce fichier, je peux copier le fichier quelque part ici ?
- Mes sitemap en SV et RO ne sont pas listé par le module et n'existe plus dans le FTP et Google Search Console râle car il ne les trouvent pas 😅

[Eolia]

Alors juste pour info, le timeout de 160s est la dernière saleté inventée par OVH sur les mutus.

C'est un timeout non-modifiable et le problème c'est que ça bloque le vidage des caches Smarty (ils ne sont jamais effacés entièrement).

Pour faire simple, avoir un Prestashop sur un mutu OVH ce n'est plus possible si on veut travailler correctement.

Les idle ou les incomplètes headers ce sont des connexions mobile qui ont perdu le réseau.

Ce qu'il faut regarder ce sont les lignes avec FATAL ERROR.

il y a 33 minutes, bobby4722 a dit :

- Mes sitemap en SV et RO ne sont pas listé par le module et n'existe plus dans le FTP et Google Search Console râle car il ne les trouvent pas 😅

Sur le dev, je ne vois pas ces langues dans le BO ?

[bobby4722]

17 minutes ago, Eolia said:

Alors juste pour info, le timeout de 160s est la dernière saleté inventée par OVH sur les mutus.

C'est un timeout non-modifiable et le problème c'est que ça bloque le vidage des caches Smarty (ils ne sont jamais effacés entièrement).

Pour faire simple, avoir un Prestashop sur un mutu OVH ce n'est plus possible si on veut travailler correctement.

Les idle ou les incomplètes headers ce sont des connexions mobile qui ont perdu le réseau.

Ce qu'il faut regarder ce sont les lignes avec FATAL ERROR.

Sur le dev, je ne vois pas ces langues dans le BO ?

C'est pas ma version de test sur votre serveur cette capture ?

J'ai fait une recherche sur le fichier avec mon navigateur et je n'ai rien avec FATAL ERROR 🙄.
 

Edited May 22, 2023 by bobby4722 (see edit history)

[bobby4722]

J'ai activé le mode débug, et également ré-initialisé le module en desinstallant, rien à faire, erreur 500 sans aucune autre indication sur la page.
Sur le module je me retrouve avec une liste de xml habituels mais ils ne sont pas dans le ftp...
 

[Sda33]

Bonsoir,

Voici une série de petits problèmes que je rencontre depuis mon passage direct de 1.6.1.24 à 1.6.2.9 sur ma boutique principale. Je suis toujours en preprod, ces problèmes m'ennuient dans mes tests.

Voici les deux plus gênants pour le moment, pour les autres je vérifie si cela ne vient pas de mon thème :

En FO page d'accueil, la liste des produits mis en avant (module homefeature) :

Je n'ai plus qu'un seul produit qui s'affiche. Pourtant le module est bien configuré avec 12 produits, j'ai bien 12 produits associés à la catégorie "home". J'ai réenregistré les produits, changé le nombre et réenregistré au niveau du module, toujours pareil, seulement le premier de la liste s'affiche (si je change l'ordre le produit change, c'est toujours celui en position 1 qui s'affiche). 

Savez-vous où regarder pour comprendre ce mystère ? Je n'ai rien trouvé dans product_list... ?

 

Mails : changer les objets

Je cherche à changer l'objet du mail "reply_msg". En effet depuis la migration quand je réponds à un message du SAV l'objet est "XXX replied to you". Avant c'était bien en français.

Je vais en BO > Traductions > emails du coeur > reply_msg. Je vois deux fois la ligne "Objet de l'e-mail", une renseignée en français, l'autre vide. Je joins la capture d'écran.

J'essaie de renseigner la ligne vide pour ne pas qu'elle prenne le texte par défaut, mais à la sauvegarde j'ai l'erreur :

Fatal error: Uncaught Error: Call to undefined function tidy_repair_string() in 
(...)
xxx/controllers/admin/AdminTranslationsController.php on line 1765

Et la ligne 1765 est : 

$formated = tidy_repair_string($content, array('indent' => true, 'show-body-only' => false, 'indent-spaces' => 4, 'wrap' => 154));

 

Avez-vous déjà eu le problème et savez-vous comment le résoudre ?

Merci

[Eolia]

il y a 46 minutes, Sda33 a dit :

Je n'ai plus qu'un seul produit qui s'affiche

Videz votre cache dans "Paramètres avancés" => "Performances"

Ce bug des modules de l'accueil est corrigé dans la prochaine version.

il y a 47 minutes, Sda33 a dit :

Fatal error: Uncaught Error: Call to undefined function tidy_repair_string() in 
(...)
xxx/controllers/admin/AdminTranslationsController.php on line 1765

L'extension Tidy n'est pas installée sur votre hébergement (normalement c'est de base).

En attendant la prochaine version remplacez:

if ($type_content == 'html') {
	$formated = tidy_repair_string($content, array('indent' => true, 'show-body-only' => false, 'indent-spaces' => 4, 'wrap' => 154));
	file_put_contents($path.$mail_name.'.'.$type_content, $formated);
}
else
	file_put_contents($path.$mail_name.'.'.$type_content, strip_tags($content));

Par

if ($type_content == 'html') {
	if(extension_loaded('tidy')) {
		$formated = tidy_repair_string($content, array('indent' => true, 'show-body-only' => false, 'indent-spaces' => 4, 'wrap' => 154));
	}
	else {
		$formated = $content;
	}
	file_put_contents($path.$mail_name.'.'.$type_content, $formated);
}
else
	file_put_contents($path.$mail_name.'.'.$type_content, strip_tags($content));

 

[docmusicstation]

On 5/22/2023 at 11:31 AM, Eolia said:

Alors juste pour info, le timeout de 160s est la dernière saleté inventée par OVH sur les mutus.

Bonjour Eolia 

Possible de vider le cache via ftp? 

Comme lors d'une installation en local

cache/smarty/cache

cache/smarty/compile

les xml ... et le cache-classeindex   ?

 

[Eolia]

Oui mais ça prend des heures chez OVH

[Sda33]

20 hours ago, Eolia said:

Videz votre cache dans "Paramètres avancés" => "Performances"

Ce bug des modules de l'accueil est corrigé dans la prochaine version.

Merci pour votre réponse, mais cela n'a fonctionné que la première fois. J'ai beau vider le cache, ça reste maintenant bloqué à un seul.

C'est curieux je n'ai pourtant rien fait de spécial depuis la migration, j'étais en train de naviguer pour vérifier page par page. D'où vient le problème, et puis-je le corriger moi-même ?

Merci

[Sda33]

Egalement une question :

J'ai un module, nommé MQC (Quantité maximale de produit par client), qui me sert pour limiter la quantité d'un produit en particulier dans le panier de tous mes clients.

Le module génère maintenant une erreur j'imagine de compatibilité au moment de l'ajout au panier :

Notice: Undefined index: id_attribute in xxx/modules/mqc/mqc.php on line 340, voici la ligne 340 :

 if (Tools::getValue('id_product') == $product['id_product'] && $restriction_attributes['id_attribute'] == $product['id_product_attribute'])

 

1. Je ne saisis pas comment je dois déclarer la variable id_attribute pour corriger... si c'est bien ce qu'il faut faire ?

2. Je me demandais si une évolution future pourrait prendre en compte ce besoin :

La fiche produit gère déjà une "quantité minimale". Peut-on de la même manière prévoir une "quantité maximale" ?

 

Merci !!!

[Eolia]

Il faudrait voir l'intégralité du code pour savoir.

Pour info Phenix intègre la limitation maximale en global

[Sda33]

11 minutes ago, Eolia said:

Pour info Phenix intègre la limitation maximale en global

Oui oui j'ai vu ça mais ça ne correspond pas à mon besoin  L'idée est vraiment de limiter un produit bien particulier, de temps en temps (un produit ponctuel, rare, très demandé : un client ne doit pouvoir en commander que trois exemplaires par commande, pas vider le stock d'un coup).

13 minutes ago, Eolia said:

Il faudrait voir l'intégralité du code pour savoir.

Voici tout le bloc...

 if ($restriction_attributes['quantity'] != null)
                {
                    if ($restriction_attributes != false or $restriction_attributes['quantity'] != '')
                    {
                        if (method_exists($params['cart'], 'getProducts'))
                        {
                            foreach ($params['cart']->getProducts() as $product)
                            {
                                if (Tools::getValue('id_product') == $product['id_product'] && $restriction_attributes['id_attribute'] == $product['id_product_attribute'])
                                {
                                    if ($product['quantity'] > $restriction_attributes['quantity'])
                                    {
                                        $blocked_attribute = 1;
                                        $this->errors['atr'] = $this->l('You exceeded maximum allowed quantity for variant of this product:') . ' <strong>' . $product['name'] . '</strong>' . ' <strong>' . $this->l('Quantity limit is ') . $restriction_attributes['quantity'] . '</strong>';
                                    }
                                }
                            }
                        }
                    }

Mais si ce n'est pas évident comme ça, je le désinstalle, ce n'est pas un module indispensable à ma migration...

[Eolia]

Ben je ne sais pas d'où sort le tableau $restriction_attributes^^

[Sda33]

25 minutes ago, Eolia said:

Ben je ne sais pas d'où sort le tableau $restriction_attributes^^

Je désactive le module pour le moment, je verrai si j'en ai besoin plus tard, je ne vais pas vous ennuyer avec

Edited May 24, 2023 by Sda33 (see edit history)

[Sda33]

17 hours ago, Sda33 said:

On 5/23/2023 at 7:14 PM, Eolia said:

Videz votre cache dans "Paramètres avancés" => "Performances"

Ce bug des modules de l'accueil est corrigé dans la prochaine version.

Merci pour votre réponse, mais cela n'a fonctionné que la première fois. J'ai beau vider le cache, ça reste maintenant bloqué à un seul.

C'est curieux je n'ai pourtant rien fait de spécial depuis la migration, j'étais en train de naviguer pour vérifier page par page. D'où vient le problème, et puis-je le corriger moi-même ?

Bonjour Eolia, désolée de revenir dessus mais c'est vraiment bloquant pour une mise en prod, je ne sais pas quand la prochaine version sera disponible c'est pourquoi j'aimerais bien essayer de résoudre de mon côté.

Le problème est lié à la session, puisque quand je n'ai qu'un produit qui remonte sur un navigateur, j'ai tous les produits attendus sur un autre navigateur.

Par ailleurs mon problème avec le module MQC semble lié, puisque quand je n'ai qu'un produit qui remonte, j'ai toujours l'erreur qui se produit (elle est très visible, elle empêche l'ajout au panier). Alors que tout fonctionne correctement quand tous les produits remontent bien en page d'accueil.

Du coup je me demande si cela n'a pas d'autre impact en ligne. Que dois-je modifier pour résoudre ce problème de cache/session ?

Merci.

[Sda33]

3 minutes ago, Sda33 said:

Du coup je me demande si cela n'a pas d'autre impact en ligne. Que dois-je modifier pour résoudre ce problème de cache/session ?

Oui en fait en même temps sur la liste des produits, je n'ai plus que 2 produits qui s'affichent à la place d'une page entière. Donc le problème est bien au-delà du module homefeature...

[Eolia]

Il y a 5 heures, Sda33 a dit :

Oui en fait en même temps sur la liste des produits, je n'ai plus que 2 produits qui s'affichent à la place d'une page entière. Donc le problème est bien au-delà du module homefeature...

Vous n'auriez pas eu un souci lors de votre dernière mise à jour ?

Il y a une nouveauté dans la 1.6.2.9:

Si votre groupe n'est pas dans la liste vous ne verrez pas ces produits.

[Sda33]

3 minutes ago, Eolia said:

Si votre groupe n'est pas dans la liste vous ne verrez pas ces produits.

Non, j'ai bien accès à tous les produits normalement.

D'ailleurs ça fonctionne avec le même hasard que les produits sélectionnés en page d'accueil. Il doit y avoir un problème sur product_list ?

J'ai une session sur Chrome qui marchait hier (sur ce point là en tout cas) et pour laquelle :

- Je n'ai plus qu'un produit (celui en position 1, si je le change par un autre il change bien) qui s'affiche en page d'accueil au lieu de 12

- Je n'ai plus que 2 produits, les deux premiers, pour chaque catégorie. Et un compteur bizarre sur le nombre de produits disponibles.

J'ai ouvert une nouvelle session Edge en parallèle, j'ai bien tous mes produits en page d'accueil, et tous mes produits dans les catégories.

 

Je joins la capture d'écran de chaque session.

Je suis sur une catégorie qui ne comprend que 14 produits.

• La première session qui n'affiche que 2 produits mais en annonce 252

 

• La seconde qui est ok avec 14 annoncés et 14 affichés.

[Eolia]

Une url où on peut voir le souci ?

[Khundo2023]

Bonjour Eolia,

Juste pour vous confirmez de mon côté, l'autoupdate de ps1.6.1.24 à PhenixSuite 1.6.2.5 à 1.2.6.9 avec 100% de réussite en quelques minutes seulement avec +4700 articles et , c'est vraiment génial plus de stress pour ça^^

Mille merci pour rendre compatible les modules comme attributewizapro avec 187 groupes attributs tout fonctionne bien now avec phenixsuite 1.6.2.9 (modules opart tout ok)

Et votre module NewsletterAdmin 6.4 mérite d'être connu fonctionne bien, très simple utiliser, rapide et pratique pour envoyer grouper au clients

Test réussite sur tous les modes d'achat (par chèque, virement bc, via module paypllug, paypal avec option 4xfois sans frais..)

Je touche du bois pour le reste...

Mille merci encore et vous souhaite une bonne journée

Cordiallement

Khundo

[Sda33]

Bonsoir,

Une précision par rapport à mon problème. Je pense que cela doit venir de la nouvelle fonctionnalité d'association de groupes sur les fiches produits, mais j'ai besoin de votre aide pour le débuguer.

Les symptômes :

- Non connectée, je vois tous les produits auxquels j'ai droit normalement, donc c'est OK.

- Connectée à un compte client, j'ai ces problèmes :

• Page d'accueil, affichage des produits remontés dans homefeatured : 1 seul produit remonte, celui en position 1, quel qu'il soit
• Liste produits, pages catégories : seuls 2 produits remontent (les deux premiers de la liste, quels qu'ils soient) + le comptage/pagination est totalement erroné

Pour info j'ai une trentaine de groupes clients : les trois de base (invité, client, visiteur) + des groupes qui me permettent de leur donner des droits en + (un code promo par exemple, ou l'accès à une catégorie dédiée). 

Je ne souhaite pas utiliser cette fonctionnalité qui n'a pas d'utilité dans mon fonctionnement, qui me gène sur la page produits\associations en BO (ça prend beaucoup de place), et qui en + je pense est à l'origine du problème.

Peut-on la désactiver ?

Merci beaucoup !

Edited May 27, 2023 by Sda33 (see edit history)

[Sda33]

1 hour ago, Sda33 said:

Connectée à un compte client, j'ai ces problèmes :

• Page d'accueil, affichage des produits remontés dans homefeatured : 1 seul produit remonte, celui en position 1, quel qu'il soit
• Liste produits, pages catégories : seuls 2 produits remontent (les deux premiers de la liste, quels qu'ils soient) + le comptage/pagination est totalement erroné

Je précise : un compte qui n'est associé qu'au groupe "Client" fonctionne normalement.

Un compte qui est associé au groupe "Client" + 1 ou plusieurs groupes rencontre ce problème.

Associé à 3 ou 4 groupes supplémentaires il m'affiche plus de produits dans les listes, mais toujours avec un compteur erroné (beaucoup trop important pour le nombre réel de produits dans la catégorie). En gros le résultat : nombre de produits affichés + compteur du total produits est toujours faux quand je suis dans deux groupes ou plus, et varie en fonction du nombre de groupes.

Vous avez une idée d'où vient le problème ? J'ai cherché dans la classe product partout où la nouvelle table product_group était appelée, mais avant de tout bidouiller de mon côté je tente ma chance ici en espérant que vous puissiez comprendre tout de suite le problème.

Et je renouvelle la demande, s'il y a possibilité de totalement désactiver la fonctionnalité ça m'intéresse.

Merci.

[P i l o u]

Il y a 11 heures, Sda33 a dit :

Associé à 3 ou 4 groupes supplémentaires il m'affiche plus de produits dans les listes, mais toujours avec un compteur erroné (beaucoup trop important pour le nombre réel de produits dans la catégorie). En gros le résultat : nombre de produits affichés + compteur du total produits est toujours faux quand je suis dans deux groupes ou plus, et varie en fonction du nombre de groupes.

Bonjour,
Je viens de voir que j'ai le même soucis.
Si pas connecté à un compte client, je vois tous les produits.
Si je me connecte avec un compte client qui est associé au Groupe "Client", je vois tous les produits.
Si je me connecte avec un compte client qui est associé à un autre Groupe que les 3 originaux, je ne vois plus tous les produits (Page d'accueil et page catégorie) et le compteur est faux (le nombre de produit est doublé).
J'ai vérifié que les articles manquants soient bien associé au Groupe de client qui pose soucis.

[Sda33]

20 hours ago, Sda33 said:

Vous avez une idée d'où vient le problème ? J'ai cherché dans la classe product partout où la nouvelle table product_group était appelée, mais avant de tout bidouiller de mon côté je tente ma chance ici en espérant que vous puissiez comprendre tout de suite le problème.

Une nouvelle journée passée sans solution de mon côté, je ne comprends pas c'est comme si aucune modification sur la classe Product n'était prise en compte, malgré de nombreux vidages de caches. J'avais prévu la migration de ma boutique principale en prod demain et je suis complètement bloquée.

Je voulais déboguer le nouveau code, vérifier les requêtes, mais aucune de mes traces ne s'affiche.
Du coup j'essaie de désactiver tout ce que peut faire référence à product_group en FO : dans le compteur, dans les listes produits, mais si je modifie Product.php impossible de voir le moindre effet. Faut-il chercher ailleurs ?

Je ne sais pas où ça cloche, et si d'autres personnes travaillent sur le même problème je veux bien en discuter avec elles.

Merci...

 

[Eolia]

il y a 28 minutes, Sda33 a dit :

Une nouvelle journée passée sans solution de mon côté, je ne comprends pas c'est comme si aucune modification sur la classe Product n'était prise en compte, malgré de nombreux vidages de caches. J'avais prévu la migration de ma boutique principale en prod demain et je suis complètement bloquée.

Je voulais déboguer le nouveau code, vérifier les requêtes, mais aucune de mes traces ne s'affiche.
Du coup j'essaie de désactiver tout ce que peut faire référence à product_group en FO : dans le compteur, dans les listes produits, mais si je modifie Product.php impossible de voir le moindre effet. Faut-il chercher ailleurs ?

Je ne sais pas où ça cloche, et si d'autres personnes travaillent sur le même problème je veux bien en discuter avec elles.

Merci...

 

Vous n'auriez pas un override de la fonction getProducts() de la classe Category ?

Si oui, il faut rajouter cette ligne dans la requête

'.(Group::isFeatureActive() ? 'INNER JOIN '._DB_PREFIX_.'product_group pg ON (pg.id_product = p.id_product AND pg.id_group IN ('.implode(',', $customer_groups).'))' : '').'

 

[Sda33]

15 minutes ago, Eolia said:

Vous n'auriez pas un override de la fonction getProducts() de la classe Category ?

Si oui, il faut rajouter cette ligne dans la requête

'.(Group::isFeatureActive() ? 'INNER JOIN '._DB_PREFIX_.'product_group pg ON (pg.id_product = p.id_product AND pg.id_group IN ('.implode(',', $customer_groups).'))' : '').'

 

Bonjour, non je n'ai pas d'override.

Par contre grâce à votre message j'ai compris que je ne cherchais pas au bon endroit, et donc dans la classe Category j'ai au contraire supprimé cette ligne des deux requêtes qui comptent et qui listent.

Et j'ai enfin retrouvé tous mes produits, avec un compteur correct.

Ce n'est pas une solution définitive, idéalement j'aimerais supprimer (ou désactiver définitivement en BO comme en FO) cette fonctionnalité qui m'a généré une table de plus de 100 000 lignes pour rien (je veux dire : product_group n'est pas utile dans mon cas, je ne dis pas que c'est inutile pour tout le monde).

Mais je vais pouvoir avancer comme ça pour le moment.

[Eolia]

Ce qui voudrait dire que tous vos groupes ne sont pas associés, il n'y aurait pas eu un souci lors de l'upgrade ?

[Khundo2023]

On 5/27/2023 at 7:13 PM, Sda33 said:

Je précise : un compte qui n'est associé qu'au groupe "Client" fonctionne normalement.

Un compte qui est associé au groupe "Client" + 1 ou plusieurs groupes rencontre ce problème.

Associé à 3 ou 4 groupes supplémentaires il m'affiche plus de produits dans les listes, mais toujours avec un compteur erroné (beaucoup trop important pour le nombre réel de produits dans la catégorie). En gros le résultat : nombre de produits affichés + compteur du total produits est toujours faux quand je suis dans deux groupes ou plus, et varie en fonction du nombre de groupes.

Vous avez une idée d'où vient le problème ? J'ai cherché dans la classe product partout où la nouvelle table product_group était appelée, mais avant de tout bidouiller de mon côté je tente ma chance ici en espérant que vous puissiez comprendre tout de suite le problème.

Et je renouvelle la demande, s'il y a possibilité de totalement désactiver la fonctionnalité ça m'intéresse.

Merci.

Bonjour, 

J'ai eu à peu près même soucis dans le passé avec les version 1.6.1.x,  j'ai résolu mon problème simplement avec ces configues

Réessayez si vous n'avez pas déjà fait  ci-joint capture

1. Catégories Pensez à désactiver/ré activer dans tous les catégories et ses groupes comme ce ci  sans oublier sauver: 
2. Dans Produit, Pensez à désactiver et réactiver tous les groupes sans oublier de sauver :
3. Dans groupes clients vérifier si tous les prix doivent être afficher pour certaines groupes de clients : 
4. Et dans le block module navigation à facette penser à tous réindexer : 

Voilà chez moi ça fonctionne très bien sur phenixSuite 1.6.2.9

Ne fier pas se qui sont cochées si soucis d'affichages, il est meilleur de désactiver et réactiver puis sauver...

En espérant cela fonctionnera chez vous.. Si tout affiche à l'accueil, il suffit par la suite de peaufiner l'affichage de vos produits et catégories pour les groupes de clients de votre choix..

 

Edited May 28, 2023 by Khundo2023 (see edit history)

[Sda33]

Bonsoir Khundo2023, merci pour votre message mais je ne le comprends pas, vous faites référence à des versions Presta antérieures à la modification dont nous parlons et qui date de la 1.6.2.9.

De mon côté et je ne pense pas être la seule : 

les produits qui remontent ou pas n’ont pas de lien direct avec les droits associés.

Exemple si je suis connectée avec un compte associé à x groupes : par catégorie j’ai juste les deux premiers avec un total affiché à plus de 1200. En page d’accueil dans ma sélection (associée à la catégorie Home) je n’en ai qu’un. Si je change l’ordre d’affichage dans la catégorie j’en ai deux nouveaux (ou un pour le homefeatured) donc s’ils ne se sont pas affichés avant ce n’est pas par manque de droit. Pourtant déconnectée j’ai bien mes 62 produits sur 62 (et non pas plus de 1200). Et c’est l’affichage attendu a minima pour quelqu’un de connecté !

Je n’ai eu aucun problème de mise à jour vers la 1.6.2.9 (pas d’alerte et les tables semblent bien complètes) et en base de données dans cette nouvelle table product_group le produit « p »est bien associé à tous les groupes attendus. Mais je ne l’ai en front, si je suis connectée, que si je le place dans les deux ou trois ou cinq premiers de ma catégorie (le nombre varie avec le nombre de groupes auxquels je suis associée).

Ce n’est pas un problème d’enregistrement ou de param BO (et je ne me vois pas d’ailleurs revenir sur mes 4000 produits pour les ré enregistrer). Et si je crée un nouveau groupe je devrai à nouveau modifier mes 4000 produits ou lancer une requête de mise à jour de la table ? Ou bien je suis passée à côté du mode d’emploi ? Non, le produit est bien associé à tous les groupes possibles. Et moi client front office je suis associée à 3 ou 5 ou 7 groupes (oui c’est possible).

Bref. Ça fonctionnait très bien avant : je gérais mes droits par catégories et par groupes, les clients pouvaient cumuler des droits (ex : accès au paiement par virement + accès à un code promo spécial avec deux groupes différents) et ça ne fonctionne plus depuis cette mise à jour. Ça re fonctionne depuis que j’ai supprimé la ligne sql qui inner join la table product_group de la classe Category même si j’ai conscience que c’est juste un patch.
Je ne veux embêter personne et je ne creuserai pas plus loin, c’est super si c’est compatible avec votre shop, je veux juste pour moi un site en Prod qui fonctionne, et je pense simplement que ce n’est pas une évolution anodine, qu’elle crée des lignes et des requêtes inutiles pour la plupart d’entre nous, qu’il faudrait la rendre parametrable, ou « installable » comme un nouveau module… c’est vraiment un point bloquant.

Voilà…

 

[Eolia]

L'idée du débrayable est à l'étude

Pour le compte erroné, il manque un Distinct à la ligne 729

$sql = 'SELECT COUNT(DISTINCT cp.`id_product`) AS total

 

[Eolia]

Disponible dans la prochaine version

[Sda33]

6 hours ago, Eolia said:

Disponible dans la prochaine version

Merci pour cette bonne nouvelle Eolia.

 

Je poursuis mes tests et j'ai une question rapide pour corriger un problème d'affichage.

Je suis sur le formulaire de connexion en front, le problème est que j'ai une alerte en rouge "Veuillez remplir correctement tous les champs requis" sous le bouton submit à peine je clique dans le champ "email".

C'est gênant, je connais des clients que ça va faire douter. Ok pour une telle alerte si on a cliqué sur "se connecter" sans avoir rempli les champs, mais pas avant...

Je ne sais pas si c'est la fatigue ou pas, mais impossible de mettre la main sur le code qui provoque cela. 

Pouvez-vous m'aider ?

Un grand merci.

 

[Eolia]

il y a une heure, Sda33 a dit :

Merci pour cette bonne nouvelle Eolia.

 

Je poursuis mes tests et j'ai une question rapide pour corriger un problème d'affichage.

Je suis sur le formulaire de connexion en front, le problème est que j'ai une alerte en rouge "Veuillez remplir correctement tous les champs requis" sous le bouton submit à peine je clique dans le champ "email".

C'est gênant, je connais des clients que ça va faire douter. Ok pour une telle alerte si on a cliqué sur "se connecter" sans avoir rempli les champs, mais pas avant...

Je ne sais pas si c'est la fatigue ou pas, mais impossible de mettre la main sur le code qui provoque cela. 

Pouvez-vous m'aider ?

Un grand merci.

 

C'est l'antispam, ce bug est corrigé dans la version à venir.

[Sda33]

51 minutes ago, Eolia said:

C'est l'antispam, ce bug est corrigé dans la version à venir.

D'accord merci, mais pour cette fois je ne vais pas pouvoir attendre la prochaine mise à jour pour organiser notre mise en production, elle était déjà prévue aujourd'hui, pourriez-vous juste me dire quel(s) fichier(s) regarder pour ça ? Et éventuellement si je suis passée à côté d'autres corrections javascript à venir et donc à faire de mon côté ?

(par exemple j'ai vu un problème sur la fiche produit, le bouton d'ajout au panier est désactivé quand on vient d'ajouter au panier déjà, ce n'est pas le cas sur la 1.6.1.24, ce n'est pas le cas non plus depuis une liste de produits, cela peut venir de mon thème et ce n'est pas vraiment bloquant, je chercherai plus tard, mais au cas où ce serait lié je pose la question ici)

Merci beaucoup.

[Eolia]

il y a 33 minutes, Sda33 a dit :

D'accord merci, mais pour cette fois je ne vais pas pouvoir attendre la prochaine mise à jour pour organiser notre mise en production, elle était déjà prévue aujourd'hui, pourriez-vous juste me dire quel(s) fichier(s) regarder pour ça ? Et éventuellement si je suis passée à côté d'autres corrections javascript à venir et donc à faire de mon côté ?

(par exemple j'ai vu un problème sur la fiche produit, le bouton d'ajout au panier est désactivé quand on vient d'ajouter au panier déjà, ce n'est pas le cas sur la 1.6.1.24, ce n'est pas le cas non plus depuis une liste de produits, cela peut venir de mon thème et ce n'est pas vraiment bloquant, je chercherai plus tard, mais au cas où ce serait lié je pose la question ici)

Merci beaucoup.

Remplacez le fichier js/tools.js par celui fourni en pièce-jointe.

tools.zip

[Sda33]

29 minutes ago, Eolia said:

Remplacez le fichier js/tools.js par celui fourni en pièce-jointe.

Un million de mercis Eolia 😀

Le formulaire d'authentification fonctionne à nouveau correctement. 

[Eolia]

il y a 5 minutes, Sda33 a dit :

Un million de mercis Eolia 😀

Le formulaire d'authentification fonctionne à nouveau correctement. 

De rien, mais vous avez bien conscience que je fais ça sur mon temps libre et qu'il s'agit d'environ 350 000 lignes de code ?

[Sda33]

10 minutes ago, Eolia said:

De rien, mais vous avez bien conscience que je fais ça sur mon temps libre et qu'il s'agit d'environ 350 000 lignes de code ?

C'est bien pour cela que je fais le maximum pour deboguer de mon côté ce qui ne fonctionne pas, pour adapter mon thème sans vous ennuyer la plupart du temps... et je partage si je trouve quelque chose, comme sur les numéros de téléphone, ou les champs de personnalisation. Parfois je suis bloquée et le contexte pro ajoute un stress de dernière minute.

Ce que vous faites sur cette 1.6, pour nous permettre de rester en 1.6 (j'ai bien testé la 1.7 pourtant...), est bien trop précieux et j'espère au moins en ce qui me concerne ne jamais vous en décourager.

J'ai hâte de terminer cette migration et de pouvoir enfin upgrader vers php 8. N'hésitez pas à vous appuyer sur moi si je peux vous aider ?

[Sda33]

Bonjour, toujours dans mes tests avant mise en prod, plusieurs problèmes javascript dans le panier. J'y ai passé la journée, je n'ai pas de solution à mon niveau alors je suis désolée, je les partage en "brut". J'ai rapatrié tous les fichiers du thème default-bootstrap sans succès non plus.

Je les signale ici pour contribuer, au cas où ils n'auraient pas été identifiés parce qu'ils sont assez spécifiques :

 

1. Si je baisse la quantité d'un produit et qu'il s'agit d'un produit personnalisé, le total produit est OK mais le total panier reste à celui d'avant la modification. C'est réglé quand on actualise la page (F5), mais ça pose problème en direct. En fait c'est le total panier + le total shipping qui ne se mettent pas à jour.

En ajoutant des "alert" dans le javascript je vois que c'est le json.total_price notamment qui ne se met pas à jour (mais où est-il calculé et pourquoi que sur le down quantité ?).

Je n'ai pas le problème quand :

• J'ajoute de la quantité sur un produit personnalisé...
• J'ajoute et je diminue un produit sans personnalisation

C'est uniquement le "down" sur produit avec personnalisation qui pose problème.

 

2. Sur les remises panier en % + produits personnalisés au panier

Chaque modification de quantité fait ramer tout le site de manière vraiment anormale.

Si j'enlève mes produits personnalisés, tout revient en ordre.

Dans les deux cas je ne sais pas où chercher, et j'ai vraiment cherché pourtant dans tous les js du thème et surtout dans cart-summary, mais j'ai l'impression qu'il va chercher et donc qu'il calcule les totaux ailleurs.

D'une manière générale, le calcul des promos panier est très lent, je ne sais pas pourquoi.

 

3. Cas particulier d'un code promo panier :

Il offre une remise sur un produit d'une catégorie.

J'ai le produit au panier, je saisis le code promo, la remise s'applique bien.

Ensuite je supprime le produit du panier, et j'ai une alerte "ce bon de réduction n’est pas applicable car votre panier ne contient que des produits en promotion ou en cadeau ". Le message ne correspond pas à l'événement, et elle est bloquante (après elle rien ne se passe). Il faut actualiser le panier (F5) pour que : et produit, et promo disparaissent.

Le comportement normal doit être la suppression ajax à la fois de la ligne du produit, et de la promo, sans message d'alerte.

 

[Mediacom87]

Il y a 2 heures, Sda33 a dit :

Bonjour, toujours dans mes tests avant mise en prod, plusieurs problèmes javascript dans le panier. J'y ai passé la journée, je n'ai pas de solution à mon niveau alors je suis désolée, je les partage en "brut". J'ai rapatrié tous les fichiers du thème default-bootstrap sans succès non plus.

Je les signale ici pour contribuer, au cas où ils n'auraient pas été identifiés parce qu'ils sont assez spécifiques :

 

1. Si je baisse la quantité d'un produit et qu'il s'agit d'un produit personnalisé, le total produit est OK mais le total panier reste à celui d'avant la modification. C'est réglé quand on actualise la page (F5), mais ça pose problème en direct. En fait c'est le total panier + le total shipping qui ne se mettent pas à jour.

En ajoutant des "alert" dans le javascript je vois que c'est le json.total_price notamment qui ne se met pas à jour (mais où est-il calculé et pourquoi que sur le down quantité ?).

Je n'ai pas le problème quand :

• J'ajoute de la quantité sur un produit personnalisé...
• J'ajoute et je diminue un produit sans personnalisation

C'est uniquement le "down" sur produit avec personnalisation qui pose problème.

 

2. Sur les remises panier en % + produits personnalisés au panier

Chaque modification de quantité fait ramer tout le site de manière vraiment anormale.

Si j'enlève mes produits personnalisés, tout revient en ordre.

Dans les deux cas je ne sais pas où chercher, et j'ai vraiment cherché pourtant dans tous les js du thème et surtout dans cart-summary, mais j'ai l'impression qu'il va chercher et donc qu'il calcule les totaux ailleurs.

D'une manière générale, le calcul des promos panier est très lent, je ne sais pas pourquoi.

 

3. Cas particulier d'un code promo panier :

Il offre une remise sur un produit d'une catégorie.

J'ai le produit au panier, je saisis le code promo, la remise s'applique bien.

Ensuite je supprime le produit du panier, et j'ai une alerte "ce bon de réduction n’est pas applicable car votre panier ne contient que des produits en promotion ou en cadeau ". Le message ne correspond pas à l'événement, et elle est bloquante (après elle rien ne se passe). Il faut actualiser le panier (F5) pour que : et produit, et promo disparaissent.

Le comportement normal doit être la suppression ajax à la fois de la ligne du produit, et de la promo, sans message d'alerte.

 

Bonjour,

Si vous pouviez arrêter d'utiliser le souligné, cela serait un plus histoire de ne pas faire croire que vous avez mis des liens sur votre texte.
Merci.
https://www.mediacom87.fr/souligne-vous-n-y-songez-pas/

[Sda33]

12 hours ago, Mediacom87 said:

Si vous pouviez arrêter d'utiliser le souligné, cela serait un plus histoire de ne pas faire croire que vous avez mis des liens sur votre texte.

Ok c'est noté. Entre nous je ne cherche pas "à faire croire que", hein... j'utilise juste des mises en forme assez classiques pour être proposés dans cet éditeur... Texte ou titres en valeur, histoire de permettre une lecture en diagonale.
Parce que sur Internet si les liens ne sont plus toujours soulignés, le "tldnr" n'est pas compatible avec le besoin d'entrer dans les détails  (j'ose le smiley parce que c'est jaune, c'est rigolo et ça dédramatise la situation)

Bon j'ai comme la sensation d'agacer...

Mais je trouve ça assez injuste, même si je comprends que c'est désagréable de lire un rapport de bug il faut reconnaître quand ils y sont et ceux que j'ai signalés ont été rencontrés par d'autres (champs de personnalisation "fantômes", format des numéros de téléphone, lien groupes clients/produits, ...). Je suis la première gênée de devoir le faire !
Je ne viens pas quémander la correction d'un module externe. Je viens signaler, pour en discuter, pour aussi que d'autres testent et voient s'ils ont le même problème qui peut nécessiter une intervention de leur part sur leur site en production.

Bref j'essaie juste de contribuer, et en échange à avancer sur ma compréhension du code pour gagner en autonomie. Parce que c'est ça l'esprit Prestashop 1.6 ! Alors si je ne fais pas comme il faut, ou bien si je me suis trompée, j'en suis désolée.

Je trouve que le travail réalisé au quotidien sur cette version est phénoménal, je suis reconnaissante, je l'ai déjà dit. Mais ce fil-ci sur ce forum-ci n'est-il pas fait pour que chacun participe, en donnant des idées d'évolution ou en partageant ses problèmes techniques ?

Y a-t-il un autre endroit peut-être pour discuter des évolutions, partager des résultats de tests, se répartir possiblement des tâches ? En bref comment peut-on aider Eolia ? Ou un endroit où accéder aux fichiers modifiés d'une version à l'autre, pour résoudre un problème sans venir le poster ici ?

Parce que mine de rien je suis aussi bloquée de mon côté par ces problèmes javascript cités dans mon précédent message. Et je ne sais plus où chercher.

Bref au-delà du soulignage dites-moi comment vous voulez que je communique, et comment je/on peux/t avancer ? 🙃

Merki. Et désolée encore...

[Eolia]

Je vais regarder votre souci de prix avec perso

Pour le lien du forum ou on peut échanger c'est en bas de vos pages BO

Parce qu'à mon avis, un de ces 4 on va se faire virer d'ici^^

[Sda33]

15 minutes ago, Eolia said:

Je vais regarder votre souci de prix avec perso

Pour le lien du forum ou on peut échanger c'est en bas de vos pages BO

Génial x2 merci !

Je viens de créer mon compte là-bas  

[Mediacom87]

il y a une heure, Eolia a dit :

Parce qu'à mon avis, un de ces 4 on va se faire virer d'ici^^

Le forum disparaitra avant de se faire virer à mon avis.

[Khundo2023]

Bonjour Eolia, et à tous

Excusez-moi de vous déranger encore une fois, Je viens vers vous car j'ai un problème au niveau de transporteurs qui m'empêche de mettre en prod mon site  avec PhenixSuite 1.6.2.9

Avant de mettre en prod, J'avais mis à jour mes produits, catégories, commandes transports etc et tout avait l'air de bien fonctionné..

Depuis front office je simule un achat test,  le produit sélectionner dans le panier affiche bien le frais de ports tarif france 

Mais lorsque je passe à l'étape de commande en me connectant compte client avec l'adresse en France, jusqu'à l'étape 4 mode Livraison,

et là ça m'affiche et me propose qu'un seul mode de livraison zone Europe, et malgré tous les transports en France sont activés

Rien à faire même en recréant nouveau transport en france, ça ne fonctionne pas,

même en mettant l'adresse outre mer, ça m'envoie toujours sur tarif zones europe..

En résumé : - hors connexion les produits affiche correctement le frais de port mais lorsqu'on est connecté les produits sont avec frais de ports zone Europe 

A noter tous mes configues de transports France, Europe,  Outre-mer fonctionnaient correctement sur PhenixSuite 1.6.2.7 et 1.6.2.8

Pouvez-vous m'aider s'il vous plaît à résoudre ce problème ? 

Merci par avance

 

 

 

 

 

[Eolia]

Il y a 4 heures, Khundo2023 a dit :

Bonjour Eolia, et à tous

Excusez-moi de vous déranger encore une fois, Je viens vers vous car j'ai un problème au niveau de transporteurs qui m'empêche de mettre en prod mon site  avec PhenixSuite 1.6.2.9

Avant de mettre en prod, J'avais mis à jour mes produits, catégories, commandes transports etc et tout avait l'air de bien fonctionné..

Depuis front office je simule un achat test,  le produit sélectionner dans le panier affiche bien le frais de ports tarif france 

Mais lorsque je passe à l'étape de commande en me connectant compte client avec l'adresse en France, jusqu'à l'étape 4 mode Livraison,

et là ça m'affiche et me propose qu'un seul mode de livraison zone Europe, et malgré tous les transports en France sont activés

Rien à faire même en recréant nouveau transport en france, ça ne fonctionne pas,

même en mettant l'adresse outre mer, ça m'envoie toujours sur tarif zones europe..

En résumé : - hors connexion les produits affiche correctement le frais de port mais lorsqu'on est connecté les produits sont avec frais de ports zone Europe 

A noter tous mes configues de transports France, Europe,  Outre-mer fonctionnaient correctement sur PhenixSuite 1.6.2.7 et 1.6.2.8

Pouvez-vous m'aider s'il vous plaît à résoudre ce problème ? 

Merci par avance

 

 

 

 

 

Pouvez-vous re-tester et me dire si vous avez toujours le pb ?

Il y avait un souci entre NULL et vide dans le cp_restriction.

[Khundo2023]

5 hours ago, Eolia said:

Pouvez-vous re-tester et me dire si vous avez toujours le pb ?

Il y avait un souci entre NULL et vide dans le cp_restriction.

Bonjour Eolia et à tous, 

Mille fois merci 🤩ça refonctionne tous les frais de ports en France et Dom Tom sont bien affichés et pointés sur la bonne adresse 

Je vais faire quelques test encore avant de mettre en mode prod

Encore merci Eolia et vous souhaite une bonne journée bien ensoleillé

Edited June 1, 2023 by Khundo2023 (see edit history)

[Eolia]

Le 30/05/2023 à 8:32 PM, Sda33 a dit :

Bonjour, toujours dans mes tests avant mise en prod, plusieurs problèmes javascript dans le panier. J'y ai passé la journée, je n'ai pas de solution à mon niveau alors je suis désolée, je les partage en "brut". J'ai rapatrié tous les fichiers du thème default-bootstrap sans succès non plus.

Je les signale ici pour contribuer, au cas où ils n'auraient pas été identifiés parce qu'ils sont assez spécifiques :

 

1. Si je baisse la quantité d'un produit et qu'il s'agit d'un produit personnalisé, le total produit est OK mais le total panier reste à celui d'avant la modification. C'est réglé quand on actualise la page (F5), mais ça pose problème en direct. En fait c'est le total panier + le total shipping qui ne se mettent pas à jour.

En ajoutant des "alert" dans le javascript je vois que c'est le json.total_price notamment qui ne se met pas à jour (mais où est-il calculé et pourquoi que sur le down quantité ?).

Je n'ai pas le problème quand :

• J'ajoute de la quantité sur un produit personnalisé...
• J'ajoute et je diminue un produit sans personnalisation

C'est uniquement le "down" sur produit avec personnalisation qui pose problème.

 

2. Sur les remises panier en % + produits personnalisés au panier

Chaque modification de quantité fait ramer tout le site de manière vraiment anormale.

Si j'enlève mes produits personnalisés, tout revient en ordre.

Dans les deux cas je ne sais pas où chercher, et j'ai vraiment cherché pourtant dans tous les js du thème et surtout dans cart-summary, mais j'ai l'impression qu'il va chercher et donc qu'il calcule les totaux ailleurs.

D'une manière générale, le calcul des promos panier est très lent, je ne sais pas pourquoi.

 

3. Cas particulier d'un code promo panier :

Il offre une remise sur un produit d'une catégorie.

J'ai le produit au panier, je saisis le code promo, la remise s'applique bien.

Ensuite je supprime le produit du panier, et j'ai une alerte "ce bon de réduction n’est pas applicable car votre panier ne contient que des produits en promotion ou en cadeau ". Le message ne correspond pas à l'événement, et elle est bloquante (après elle rien ne se passe). Il faut actualiser le panier (F5) pour que : et produit, et promo disparaissent.

Le comportement normal doit être la suppression ajax à la fois de la ligne du produit, et de la promo, sans message d'alerte.

 

Bonjour,

Je ne reproduis pas le souci lié à la décrémentation du produit (perso ou pas) ni par rapport aux règles en % liées à la quantité.

Vous pouvez tester ici: https://presta.devcustom.net/fr/

Il y a 2 remises par quantités sur le produit T-shirt délavé à manches courtes qui est personnalisable avec indice de prix.

Pour le message lors de la suppression d'un produit lié à une cartrule c'est corrigé.

[Sda33]

15 hours ago, Eolia said:

Je ne reproduis pas le souci lié à la décrémentation du produit (perso ou pas) ni par rapport aux règles en % liées à la quantité.

Merci d'avoir testé, je ne comprends vraiment pas, je les ai aussi avec le thème default ces bugs...

Je vais tester sur le lien que vous m'avez donné.

Savez-vous quels fichiers javascript sont concernés pour que je comprenne où se pose le problème ? J'avais pourtant aussi vérifié les modules greffés...

 

Par ailleurs je rencontre un autre problème, je l'avais déjà eu il y a quelques semaines sur la 1.6.2.7, mais tout était revenu en ordre aussi spontanément que c'était apparu.

Je n'entre plus sur mon backoffice. Quand je tape l'URL, au lieu de me proposer de me connecter il m'affiche le bandeau haut du backoffice et une page blanche. En front j'ai la page "site en maintenance" classique, je ne peux donc pas naviguer non plus.

J'ai vidé mon cache navigateur, vidé le cache de ma preprod par FTP, changé de navigateur, et même tenté d'accédé en 4G donc avec une autre IP, rien n'y fait. Le problème est-il connu et d'où peut-il venir ? Comment tout réinitialiser pour à nouveau me connecter ?

Merci.

[Sda33]

(question additionnelle : cela peut-il venir de la version PHP ? je ne pourrai passer en 8.2 que quand je serai en prod...)

[Sda33]

55 minutes ago, Sda33 said:

Je vais tester sur le lien que vous m'avez donné.

Avez-vous la possibilité de modifier le code promo DRK7SVWC pour qu'il s'applique à tout le site (et donc aux produits personnalisés) et pas qu'aux robes de soirée ? Merci beaucoup

[Eolia]

il y a une heure, Sda33 a dit :

Avez-vous la possibilité de modifier le code promo DRK7SVWC pour qu'il s'applique à tout le site (et donc aux produits personnalisés) et pas qu'aux robes de soirée ? Merci beaucoup

C'est fait.

[Eolia]

Il y a 1 heure, Sda33 a dit :

(question additionnelle : cela peut-il venir de la version PHP ? je ne pourrai passer en 8.2 que quand je serai en prod...)

Non.

Vous devez avoir un code/script qui est accroché soit:

- au calcul des prix

- au calcul des frais de port

- au remises/promotions cumulables ou pas.

[Eolia]

Il y a 2 heures, Sda33 a dit :

Savez-vous quels fichiers javascript sont concernés pour que je comprenne où se pose le problème ? J'avais pourtant aussi vérifié les modules greffés...

- cart-summary.js

- blockcart.js

Mais la modification des quantités appelle en ajax: CartController.php, Cart.php et CartRule.php

Il y a 2 heures, Sda33 a dit :

Je n'entre plus sur mon backoffice. Quand je tape l'URL, au lieu de me proposer de me connecter il m'affiche le bandeau haut du backoffice et une page blanche. En front j'ai la page "site en maintenance" classique, je ne peux donc pas naviguer non plus.

Ca, ça sent le problème de droits sur un module.

[Sda33]

2 minutes ago, Eolia said:

Ca, ça sent le problème de droits sur un module.

Je n'ai pourtant rien modifié, ça a sauté en plein après-midi hier après une coupure réseau, je suis en admin tout le temps, et c'est la page de connexion qui devrait s'afficher... Je vais finir chauve avant de mettre en production 😑

5 minutes ago, Eolia said:

Mais la modification des quantités appelle en ajax: CartController.php, Cart.php et CartRule.php

Merci, je me retrousse les manches et je vous tiens au courant dès que j'ai compris comment retrouver mon BO.

[Eolia]

Pour votre BO, commencez par vider vos cookies, supprimer le fichier /cache/classes/index.php et le fichier .htaccess (vous devrez le regénérer ensuite, en bas de la page SEO & URLs)

[Eolia]

La version 1.6.2.10 est sortie  

[P i l o u]

Bonjour Eolia,

Merci pour cette nouvelle version.

Serait-il envisageable svp :

- d'ajouter les miniatures dans la recherche ajax

- d'ajouter "A partir de" devant le prix pour les articles avec déclinaisons (sur la home et dans les pages catégories)

Merci d'avance

[Khundo2023]

13 hours ago, Eolia said:

La version 1.6.2.10 est sortie  

Bonjour Eolia & à tous,

Grand merci pour la version 1.6.2.10 Eolia

Je suis dégouté, j'apprêtais à mettre en prod la version 1.6.2.9 ou la version 1.6.2.10,

mais j'ai eu une erreur 500, à l'étape 4 de la commande mode livraison offerte avec  1 produit à 0 euros

lorsque je valide la commande ça m'affiche erreur 500

malgré cette erreur, chez le client et marchand reçoivent bien par mail la confirmation de l'achat  du produit et ainsi que dans le back office.

A note sur la version Phenixsuite 1.6.2.7 j'ai testé la même méthode cela fonctionne très bien et sans erreur.

Pour plus d'infos sur les produits à 0 euros, ce sont des produits remboursés à 100% par la sécu, lorsque le client achète et joindre l'ordonnance à la commande certains de ces produits sont donc à 0 euros, et transport offert pour les habitants de la Rochelle etc 

A la page d'accueil : le 1e article "attelle rotulienne..." avec ordonnance est à 0 euros

@eolia : Pouvez-vous nous aider à résoudre ce problème s'il vous plait? 

J'ai laissé en version 1.6.2.10 sur mon site .com si vous pouvez jeter un oeil dessus s'il vous plait ?

en vous remerciant par avance 

khundo

 

 

 

Edited June 6, 2023 by Khundo2023 (see edit history)

[Eolia]

Il y a 6 heures, Khundo2023 a dit :

Bonjour Eolia & à tous,

Grand merci pour la version 1.6.2.10 Eolia

Je suis dégouté, j'apprêtais à mettre en prod la version 1.6.2.9 ou la version 1.6.2.10,

mais j'ai eu une erreur 500, à l'étape 4 de la commande mode livraison offerte avec  1 produit à 0 euros

lorsque je valide la commande ça m'affiche erreur 500

malgré cette erreur, chez le client et marchand reçoivent bien par mail la confirmation de l'achat  du produit et ainsi que dans le back office.

A note sur la version Phenixsuite 1.6.2.7 j'ai testé la même méthode cela fonctionne très bien et sans erreur.

Pour plus d'infos sur les produits à 0 euros, ce sont des produits remboursés à 100% par la sécu, lorsque le client achète et joindre l'ordonnance à la commande certains de ces produits sont donc à 0 euros, et transport offert pour les habitants de la Rochelle etc 

A la page d'accueil : le 1e article "attelle rotulienne..." avec ordonnance est à 0 euros

@eolia : Pouvez-vous nous aider à résoudre ce problème s'il vous plait? 

J'ai laissé en version 1.6.2.10 sur mon site .com si vous pouvez jeter un oeil dessus s'il vous plait ?

en vous remerciant par avance 

khundo

 

 

 

C'est résolu  

[Khundo2023]

2 hours ago, Eolia said:

C'est résolu  

Bonjour Eolia,

Mille fois merci d'avoir résolu aussi rapidement,

Je viens de tester sur Phenixsuite 1.6.2.10, cela fonctionne bien sans erreur, la commande avec l'ordonnance et ses pieces joints + transport gratuits sont bien valider, avec mail de confirmation chez le marchand et client, compte historique du client et bo

Vraiment super!!! 

Merci, merci encore et vous souhaite une agréable journée

Cordialement

Khundo

[bobby4722]

Bonjour @Eolia,
Comme expliqué précédemment je traduit notre site internet déjà depuis plusieurs semaines avant que nous puissions passer sur la 1.6.2.10.
Je suis confronté avec un petit soucis qu'il parait n'est que présent sur la 1.6 (la réponse du développeur du module de traduction) et donc je voulais savoir savoir si cela avait été corrigé ou non.
Mon site est traduit déjà en Russe et plus récemment en Bulgare, là, pas de soucis les urls se transforment d'elles mêmes en caractères Latins, en revanche pour le Grec cela ne fonctionne pas.
Je n'ai pas envie de cocher la case des caractères accentués sur les urls pour éviter des soucis futurs par exemple sur le Français.
Je voudrais donc savoir si il y avait, il été prévu etc... de "transposer" les url du Grec vers des caractères Latins comme mon Presta le fait actuellement pour le Cyrillique ?

[Eolia]

Je ne comprends pas la question ?

http://test.phenixsuite.com/el/3-γυναίκες ne vous convient pas ?

[bobby4722]

- Ah bah si si super si vous avez réglé ce soucis !
Mais je n'ai pas testé sur une autre version que la 1.6.1.26.
Alors parfait, j'ai donc hâte que nous puissions se trouver un créneau pour installer la 1.6.2.10

[Eolia]

ce sera la 1.6.2.11^^ (il y a plusieurs correctifs)

[Sda33]

1 hour ago, Eolia said:

ce sera la 1.6.2.11^^ (il y a plusieurs correctifs)

Bonjour Eolia, cela signifie-t-il que vous recommandez d'attendre la 1.6.2.11 avant de mettre à jour ?

(pour info je recommence une preprod et je migrerai depuis 1.6.1.24...)

Merci !  

[Eolia]

Oui, ce soir ou demain  

[Khundo2023]

3 hours ago, Eolia said:

ce sera la 1.6.2.11^^ (il y a plusieurs correctifs)

Bonsoir Eolia, 

🥰Excellent vous allez super vite!

Pour mon cas si je mets à jours de version 1.6.2.10 version 1.6.2.11, 

est ce que les commandes gratuits passeront sans erreurs ? où vous avez dejà override sur la version 1.6.2.10 ?

 

Edited June 7, 2023 by Khundo2023 (see edit history)

[Eolia]

il y a une heure, Khundo2023 a dit :

Bonsoir Eolia, 

🥰Excellent vous allez super vite!

Pour mon cas si je mets à jours de version 1.6.2.10 version 1.6.2.11, 

est ce que les commandes gratuits passeront sans erreurs ? où vous avez dejà override sur la version 1.6.2.10 ?

 

Oui c'est ok pour les gratuites.

[Eolia]

#PhenixSuite: la version 1.6.2.11 est sortie !

Pour ceux qui veulent l'installer pour la première fois, un seul fichier suffit:
https://devcustom.net/public/scripts/dl.php?f=autoloader

[Khundo2023]

19 hours ago, Eolia said:

#PhenixSuite: la version 1.6.2.11 est sortie !

Pour ceux qui veulent l'installer pour la première fois, un seul fichier suffit:
https://devcustom.net/public/scripts/dl.php?f=autoloader

Bonjour Eolia,

Merci pour la version 1.6.2.11 

J'ai tenté de mettre à jour sur mon site.com version 1.6.2.10 à la nouvelle version 1.6.2.11 avec autoupgrade v21 mais ça tourne en boucle,

pas possible de le mettre à jour... 

Pouvez-vous jeter un oeil dessus, ou  m'aider, me guilder ce que je dois faire svp? 

Merci par avance 

Cordialement

 

 

Edited June 8, 2023 by Khundo2023 (see edit history)

[Eolia]

Souci de js, votre version est à jour à présent

 

[Khundo2023]

4 minutes ago, Eolia said:

Souci de js, votre version est à jour à présent

 

Un grand merci Eolia en vous souhaitant une agréable soirée

Cordialement

[Eolia]

Le 05/06/2023 à 5:46 PM, P i l o u a dit :

Bonjour Eolia,

Merci pour cette nouvelle version.

Serait-il envisageable svp :

- d'ajouter les miniatures dans la recherche ajax

- d'ajouter "A partir de" devant le prix pour les articles avec déclinaisons (sur la home et dans les pages catégories)

Merci d'avance

[docmusicstation]

Bonsoir

Lors de la mise a jour 1.6.1.25 vers 1.6.2.11 en local voila ce que j'obtiens :

Aucune erreur lors de la mise a jour !

Edited June 14, 2023 by docmusicstation (see edit history)

[Eolia]

Hum... en local ça va être difficile de vous aider.

Avez-vous le fichier debug.php dans le répertoire /config ?

Si non, créez-le et mettez ceci dedans:

<?php

define('_PS_MODE_DEV_', 1);

et raffraichissez votre page de login.