Jump to content

Sortie de la version 1.6.1.28 - By @Eolia

Eolia

By Eolia
in Discussion générale

 Share

Recommended Posts

  • Replies 992
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

Eolia
Eolia

Bonne nouvelle pour ceux qui l'attendaient, elle est à présent dispo     AVERTISSEMENT: Cette version est livrée "telle quelle". Toutes les modifications et améliorations apportées ont

Eolia
Eolia

PhenixSuite 1.6.2.15 : Enfin un vrai tracking par client

Eolia
Eolia

La version 1.6.2.15 est sortie Bonne rentrée à tous !

Posted Images

docmusicstation Contributor

docmusicstation

Posted
Posted
10 hours ago, Eolia said:

#PhenixSuite: la version 1.6.2.15 est sortie ! ;) 

Première installation ? Un seul fichier suffit: https://devcustom.net/public/scripts/dl.php?f=autoloader…

Changelog complet ici: https://devcustom.net/public/scripts/dl.php?f=changelog

Bonjour Eolia

Merci pour cette nouvelle version 

Mais c'est plutot 1.6.2.16 ! 

Bonne journée 

Link to comment
Share on other sites
bobby4722 Enthusiast

bobby4722

Posted
Posted

Les "Accessoires" ont disparus suite à la MAJ ce matin 🥲
Et j'avais remarqué que c'était devenu restreint en quantité suite à mon passage de la 1.6.1.26 à la 1.6.2.15, j'ai cherché pour le définir la quantité sur "la totalité des produits" ajoutés comme accessoires et pas moyen de savoir où cela se règle ni comment le réactiver.
Quelqu'un sait svp ?
Merci

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 3 heures, bobby4722 a dit :

Les "Accessoires" ont disparus suite à la MAJ ce matin 🥲
Et j'avais remarqué que c'était devenu restreint en quantité suite à mon passage de la 1.6.1.26 à la 1.6.2.15, j'ai cherché pour le définir la quantité sur "la totalité des produits" ajoutés comme accessoires et pas moyen de savoir où cela se règle ni comment le réactiver.
Quelqu'un sait svp ?
Merci

Normalement c'est ok à présent (il y avait une restriction pour n'afficher que les produits en stock)

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 5 heures, Olivier33000 a dit :

Ayant un problème de redirection sur un lien (friendly url) du menu top pour prices-drop (-> erreur 404), je me demande si "- Ajout de l'option d'affichage (Oui/Non) de la page Promotions en FO" de la v.1.6.1.25 est lié à ce problème. Où se situe ce paramètre dans le BO ?

Merci !

Préférences -> Générales

image.png.33782208afc5564e968bc4263066056b.png

Link to comment
Share on other sites
bobby4722 Enthusiast

bobby4722

Posted
Posted
5 minutes ago, Eolia said:

Normalement c'est ok à présent (il y avait une restriction pour n'afficher que les produits en stock)

Genial Pierre ! merci oui je les vois à présent mais la restriction au sujet du nombre c’est bon aussi ?

Je ne sais pas pourquoi il m’ajoute un « 0 » aux caractéristiques id 2,3 et 25 quand j’ajoute un nouveau produit 😅 Bon, c’est pas un drame non plus 😉

 

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 9 heures, bobby4722 a dit :

oui je les vois à présent mais la restriction au sujet du nombre c’est bon aussi ?

Il n'y a pas de restriction au niveau du nombre.

 

Il y a 9 heures, bobby4722 a dit :

Je ne sais pas pourquoi il m’ajoute un « 0 » aux caractéristiques id 2,3 et 25 quand j’ajoute un nouveau produit 😅 Bon, c’est pas un drame non plus 😉

Sans doute parce que ces caractéristiques existent sans aucune valeur associée.

Link to comment
Share on other sites
Olivier33000 Contributor

Olivier33000

Posted
Posted

en modifiant la ligne 256 de crossselling  

if (!$this->isCached('crossselling.tpl', $this->getCacheId($cache_id))) {
            $final_products_list = $this->getOrderProducts(array($params['product']->id));

par  

if (!$this->isCached('crossselling.tpl', $this->getCacheId($cache_id))) {
            $final_products_list = $this->getOrderProducts(array((int)$params['product']->id));

je n'ai plus l'erreur sql.

Link to comment
Share on other sites
Khundo2023 Collaborator

Khundo2023

Posted
Posted (edited)

Bonsoir Eolia,

Merci pour la v16 j'ai réussi à mettre à jour v14 à v16 sans soucis sur mon sitetest.com, par contre j'ai remarqué les mots de pass Employés je ne peux plus les créer avec des caractères + ou - exemple pass : eolia +v16 ?

Peut-être ça vient juste que de chez moi.

Je compte mettre à jour prochainement mon site product v12 vers v16 mais vous allez bientot sortir v17? je vais attendre..

Est-ce que si la version est trop différente v12 à v16 ou v17 il y aurait-il des risques d'erreurs pendant la mise à jour ?

Merci par avance,

 

Edited by Khundo2023 (see edit history)
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
il y a 21 minutes, Khundo2023 a dit :

Bonsoir Eolia,

Merci pour la v16 j'ai réussi à mettre à jour v14 à v16 sans soucis sur mon sitetest.com, par contre j'ai remarqué les mots de pass Employés je ne peux plus les créer avec des caractères + ou - exemple pass : eolia +v16 ?

Peut-être ça vient juste que de chez moi.

Je compte mettre à jour prochainement mon site product v12 vers v16 mais vous allez bientot sortir v17? je vais attendre..

Est-ce que si la version est trop différente v12 à v16 ou v17 il y aurait-il des risques d'erreurs pendant la mise à jour ?

Merci par avance,

 

Il n'y a aucune restriction sur les caractères des mots de passe, juste sur leur longueur qui doit faire 8 caractères mini.

Il n'y a pas de risque d'erreurs lors des mises à jour, chacune apporte son lot de correctifs et d'ajouts de fonctionnalités.

  • Thanks 1
Link to comment
Share on other sites
NSN Enthusiast

NSN

Posted
Posted (edited)

Cher Pierre,

J'ai mis à jour la version 1.6.2.15 vers la version 1.6.2.16 et maintenant je reçois des messages de clients potentiels qui ne peuvent pas créer de compte. Ils obtiennent toujours le message "birthday is invalid" (la date d'anniversaire n'est pas valide)

J'ai résolu le problème avec une petite astuce. (/classes/Customer.php) J'ai mis le

Zitat

    'birthday' => array('type' => self::TYPE_DATE, 'validate' => 'isBirthDate'),

dans un commentaire avec /* ... */

Cela rend l'enregistrement possible, mais avant la mise à jour, ce hack n'était pas nécessaire. Avez-vous une idée de la raison de ce problème et peut-il être corrigé pour les prochaines mises à jour ou dois-je éditer le fichier après chaque mise à jour ?

Cordialement,
Stefan

 

French translation with DeepL
Original text below.

 

Dear Pierre,

I updated from 1.6.2.15 to 1.6.2.16 and now I get messages from potential customers that they cannot create an account. The always get the message "birthday is invalid"

I fixed it with a dirty hack. (/classes/Customer.php) I put the

Zitat

'birthday'                      => array('type' => self::TYPE_DATE, 'validate' => 'isBirthDate'),

into comment with /* ... */

This makes registration possible, but before the update this hack was not needed. Do you have any idea why and can it be fixed for further updates or do I need the file to edit after every update?

Best regards
Stefan

Edited by NSN (see edit history)
Link to comment
Share on other sites
Khundo2023 Collaborator

Khundo2023

Posted
Posted (edited)
5 hours ago, Eolia said:

Il n'y a aucune restriction sur les caractères des mots de passe, juste sur leur longueur qui doit faire 8 caractères mini.

Il n'y a pas de risque d'erreurs lors des mises à jour, chacun apporte son lot de correctifs et d'ajouts de fonctionnalités.

Merci Eolia,

Mais ça ne fonctionne pas sur monsitest.com sous Phenix v16, les mots de passes avec caractères spéciaux, 

ça enregistre bien le nouveau mot de pass avec caractères spéciaux mais quand je me déconnecte puis me reconnecte, ça m'affiche compte inexistant ou mauvais mot de pass.

Par contre ça reconnaît et fonctionne bien le mot de passe normal style exemple : Eolia2023

 

Edited by Khundo2023 (see edit history)
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted (edited)
Il y a 11 heures, NSN a dit :

Cher Pierre,

J'ai mis à jour la version 1.6.2.15 vers la version 1.6.2.16 et maintenant je reçois des messages de clients potentiels qui ne peuvent pas créer de compte. Ils obtiennent toujours le message "birthday is invalid" (la date d'anniversaire n'est pas valide)

J'ai résolu le problème avec une petite astuce. (/classes/Customer.php) J'ai mis le

dans un commentaire avec /* ... */

Cela rend l'enregistrement possible, mais avant la mise à jour, ce hack n'était pas nécessaire. Avez-vous une idée de la raison de ce problème et peut-il être corrigé pour les prochaines mises à jour ou dois-je éditer le fichier après chaque mise à jour ?

Cordialement,
Stefan

 

French translation with DeepL
Original text below.

 

Dear Pierre,

I updated from 1.6.2.15 to 1.6.2.16 and now I get messages from potential customers that they cannot create an account. The always get the message "birthday is invalid"

I fixed it with a dirty hack. (/classes/Customer.php) I put the

into comment with /* ... */

This makes registration possible, but before the update this hack was not needed. Do you have any idea why and can it be fixed for further updates or do I need the file to edit after every update?

Best regards
Stefan

This field is mandatory or not in your shop ?

image.png.f71d7d22d4267dd77b76453f31157aa5.png

In validate.php: 

    public static function isBirthDate($date)
    {
        if(empty($date) || $date == '0000-00-00') {
            return true;
        }
        if(preg_match('/^([0-9]{4})-((?:0?[1-9])|(?:1[0-2]))-((?:0?[1-9])|(?:[1-2][0-9])|(?:3[01]))([0-9]{2}:[0-9]{2}:[0-9]{2})?$/', $date, $birth_date)) {
            if($birth_date[1] > date('Y') && $birth_date[2] > date('m') && $birth_date[3] > date('d')
                || $birth_date[1] == date('Y') && $birth_date[2] == date('m') && $birth_date[3] > date('d')
                || $birth_date[1] == date('Y') && $birth_date[2] > date('m')) {
                return false;
            }
            return true;
        }
        return false;
    }

 

Edited by Eolia (see edit history)
Link to comment
Share on other sites
NSN Enthusiast

NSN

Posted
Posted

J'ai mis à jour 2 boutiques et les deux montrent le même problème depuis la mise à jour. Le champ "anniversaire" n'est pas obligatoire dans les deux boutiques.
Le code affiché de validate.php est identique au code du fichier de ma boutique.

Je vérifierai plus tard ce qui se passe lorsque j'active le champ "birthday" comme obligatoire et que je le désactive à nouveau.

 

French translation with DeepL
Original text below.

 

I have updated 2 shops and both show the same issue since the update. The field "birthday" is not set to mandatory at both shops.
The posted code from validate.php is identical with the code from my shop's file.

I will check later what happens when I activate "birthday" as mandatory and disable it again.

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 11 heures, Khundo2023 a dit :

Merci Eolia,

Mais ça ne fonctionne pas sur monsitest.com sous Phenix v16, les mots de passes avec caractères spéciaux, 

ça enregistre bien le nouveau mot de pass avec caractères spéciaux mais quand je me déconnecte puis me reconnecte, ça m'affiche compte inexistant ou mauvais mot de pass.

Par contre ça reconnaît et fonctionne bien le mot de passe normal style exemple : Eolia2023

 

Problème identifié et corrigé dans la v17

 

  • Thanks 1
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 4 heures, NSN a dit :

J'ai mis à jour 2 boutiques et les deux montrent le même problème depuis la mise à jour. Le champ "anniversaire" n'est pas obligatoire dans les deux boutiques.
Le code affiché de validate.php est identique au code du fichier de ma boutique.

Je vérifierai plus tard ce qui se passe lorsque j'active le champ "birthday" comme obligatoire et que je le désactive à nouveau.

 

French translation with DeepL
Original text below.

 

I have updated 2 shops and both show the same issue since the update. The field "birthday" is not set to mandatory at both shops.
The posted code from validate.php is identical with the code from my shop's file.

I will check later what happens when I activate "birthday" as mandatory and disable it again.

Ok, je vois que vous avez complètement supprimé les champs dans le formulaire.

Le correctif (qui sera appliqué dans la 17), bloc validateController() de la classe ObjectModel: 

    public function validateController($htmlentities = true)
    {
        $this->cacheFieldsRequiredDatabase();
        $errors = array();
        $required_fields_database = (isset(self::$fieldsRequiredDatabase[get_class($this)])) ? 
            self::$fieldsRequiredDatabase[get_class($this)] : 
            array();
        foreach($this->def['fields'] as $field => $data) {
            // Customer->birthday is a particular composed value so Tools::getValue('birthday') never exists.
            if($field == 'birthday') {
                $value = (!Tools::getValue('years') ? 
                    '' : 
                    (int)Tools::getValue('years').'-'.(int)Tools::getValue('months').'-'.(int)Tools::getValue('days'));
                if(empty($value)) {
                    $value = $this->{$field};
                }
            }
            else {
                $value = Tools::getValue($field, $this->{$field});
            }
            if(!empty($value)) {
                $value = trim($value);
            }
            // Check if field is required by user
            if(in_array($field, $required_fields_database)) {
                $data['required'] = true;
            }

            // Checking for required fields
            if(isset($data['required']) 
                && $data['required'] 
                && empty($value) && $value !== '0'
            ) {
                if(!$this->id || $field != 'passwd') {
                    $errors[$field] = '<b>'.self::displayFieldName($field, get_class($this), $htmlentities)
                        .'</b> '.Tools::displayError('is required.');
                }
            }

            // Checking for maximum fields sizes
            if(isset($data['size']) 
                && !empty($value) 
                && Tools::strlen($value) > $data['size']
            ) {
                $errors[$field] = sprintf(
                    Tools::displayError('%1$s is too long. Maximum length: %2$d'),
                    self::displayFieldName($field, get_class($this), $htmlentities),
                    $data['size']
                );
            }

            // Checking for fields validity
            // Hack for postcode required for country which does not have postcodes
            if(!empty($value) 
                || $value === '0' 
                || ($field == 'postcode' && $value == '0')
            ) {
                $validation_error = false;
                if(isset($data['validate'])) {
                    $data_validate = $data['validate'];
                    if(!Validate::$data_validate($value) && (!empty($value) || $data['required'])) {
                        $errors[$field] = '<b>'.self::displayFieldName($field, get_class($this), $htmlentities)
                            .'</b> '.Tools::displayError('is invalid.');
                        $validation_error = true;
                    }
                }

                if(!$validation_error) {
                    if(isset($data['copy_post']) && !$data['copy_post']) {
                        continue;
                    }
                    if($field == 'passwd') {
                        if($value = Tools::getValue($field)) {
                            $this->{$field} = Tools::passwdHash($value);
                        }
                    } 
                    else {
                        $this->{$field} = $value;
                    }
                }
            }
        }

        return $errors;
    }

 

  • Thanks 1
Link to comment
Share on other sites
Khundo2023 Collaborator

Khundo2023

Posted
Posted

Bonjour Eolia, 

J'ai un soucis erreur fatale avec le module klsmartmail sous phenix v12 sur monsite.fr en mode production 

Je ne sais pas à quoi il sert mais lorsque je clique sur Modules et Services ça m'affiche Erreur Fatale

De l'aide svp 

je vous ai envoyé en mp l'accès

Merci par avance,  ça me tarde aussi pour version 17 pour une mise à jour

Cordialement

Link to comment
Share on other sites
NSN Enthusiast

NSN

Posted
Posted

Désolé de vous déranger à nouveau, mais j'ai découvert un nouveau comportement étrange.
Le problème est expliqué en quelques étapes :
+ Le client commande et paie dans une devise autre que la devise standard du magasin. La commande comprend des articles spécifiques bénéficiant d'une remise (catégorie de remise en %).
+ Le montant payé est correct et les détails de la facture tels que le total des produits, le total des remises (dans ce cas 5,88 euros), les frais d'expédition et le total.
+ Le montant indiqué dans la section de la facture consacrée à la remise est erroné. (dans ce cas, il est indiqué 840,00 euros). Il en va de même dans la page d'administration des commandes.

Il semble que le montant, qui est dans la table `ps_order_cart_rule` de la base de données, est sauvegardé dans la devise par défaut de la boutique et n'est pas converti dans la devise du client. (Et il apparaît sur la facture non converti, mais avec le symbole de la devise du client).

 

French translation with DeepL
Original text below.

 

Sorry to bother you again, but I discovered a new strange behaviour.
Problem in short steps explained:
+ Customer orders and pays in other currency than shop standard. The order includes specific items that have a discount (category discount in %).
+ The paid amount is correct and the invoice details such as Total Products, Total Discounts (in this case 5,88 Euro), Shipping costs and Total.
+ The amount stated in the discount section of the invoice is wrong. (in this case it says 840,00 Euro). The same in admin orders page.

It looks like the amount, which is in table `ps_order_cart_rule` of the database, is saved in the shop's default currency and not converted into customers currency. (And than shows on invoice unconverted, but with customers currency symbol.)

Screenshot 2023-10-13 at 00-04-15 Orders Order S0930 from Elpidio LOPEZ • NipponShop.png

Screenshot 2023-10-12 at 23-51-52 BBT291579.pdf.png

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 1 heure, NSN a dit :

Désolé de vous déranger à nouveau, mais j'ai découvert un nouveau comportement étrange.
Le problème est expliqué en quelques étapes :
+ Le client commande et paie dans une devise autre que la devise standard du magasin. La commande comprend des articles spécifiques bénéficiant d'une remise (catégorie de remise en %).
+ Le montant payé est correct et les détails de la facture tels que le total des produits, le total des remises (dans ce cas 5,88 euros), les frais d'expédition et le total.
+ Le montant indiqué dans la section de la facture consacrée à la remise est erroné. (dans ce cas, il est indiqué 840,00 euros). Il en va de même dans la page d'administration des commandes.

Il semble que le montant, qui est dans la table `ps_order_cart_rule` de la base de données, est sauvegardé dans la devise par défaut de la boutique et n'est pas converti dans la devise du client. (Et il apparaît sur la facture non converti, mais avec le symbole de la devise du client).

 

French translation with DeepL
Original text below.

 

Sorry to bother you again, but I discovered a new strange behaviour.
Problem in short steps explained:
+ Customer orders and pays in other currency than shop standard. The order includes specific items that have a discount (category discount in %).
+ The paid amount is correct and the invoice details such as Total Products, Total Discounts (in this case 5,88 Euro), Shipping costs and Total.
+ The amount stated in the discount section of the invoice is wrong. (in this case it says 840,00 Euro). The same in admin orders page.

It looks like the amount, which is in table `ps_order_cart_rule` of the database, is saved in the shop's default currency and not converted into customers currency. (And than shows on invoice unconverted, but with customers currency symbol.)

Screenshot 2023-10-13 at 00-04-15 Orders Order S0930 from Elpidio LOPEZ • NipponShop.png

Screenshot 2023-10-12 at 23-51-52 BBT291579.pdf.png

Concernant la facture, vous utilisez le modèle pdf par défaut ou vous en avez un spécifique à votre thème ?

Le code doit être 

	{assign var="shipping_discount_tax_incl" value="0"}
	{foreach from=$cart_rules item=cart_rule name="cart_rules_loop"}
		{if $smarty.foreach.cart_rules_loop.first}
		<tr class="discount">
			<th class="header" colspan="{$layout._colCount}">
				{l s='Discounts' pdf='true'}
			</th>
		</tr>
		{/if}
		<tr class="discount">
			<td class="white right" colspan="{$layout._colCount - 1}">
				{$cart_rule.name}
			</td>
			<td class="right white">
				- {displayPrice currency=$order->id_currency price=$cart_rule.value_tax_excl}
			</td>
		</tr>
	{/foreach}

dans /pdf/invoice.product-tab.tpl (ou /themes/votre_theme/pdf)invoice.product-tab.tpl

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted

Rectificatif, les commandes passées dans une monnaie autre que celle par défaut sont toujours affichées dans la monnaie du client.

Je ne sais pas comment vous faites pour afficher la commande en euros de votre côté ?

Link to comment
Share on other sites
NSN Enthusiast

NSN

Posted
Posted

Cher Pierre,

La devise par défaut de la boutique est le JPY. Le client a commandé en EUR.

Aujourd'hui, j'ai reçu une autre commande pour laquelle deux remises différentes s'appliquent. L'une est la même remise par catégorie (en %) et l'autre est une remise générale de 5% sur l'ensemble de la commande.
La remise sur la catégorie est à nouveau dans la devise par défaut du magasin, mais la remise générale est correcte dans la devise du client.

Customer PDF invoiceScreenshot2023-10-13at08-53-19BBT291583_pdf.thumb.png.058fa3a79c02bcfbedd09a2ca813df00.png

Admin order pageScreenshot2023-10-13at08-52-59OrdersOrderS0934fromDavidJENKINSNipponShop.png.25b063612c7dd3c58b71586b20169dd4.png

J'ai vérifié la base de données (`ps_order_cart_rule`) et la valeur de la remise (la remise par catégorie) est sauvegardée en JPY même si le client a payé dans une autre devise. La remise générale est enregistrée correctement dans la devise du client.

Database table `ps_order_cart_rule`

Screenshot2023-10-13at09-02-33nl1-ts6.a2hosting.com_localhost_nipponsh_shop_ps_order_cart_rulephpMyAdmin5.2.1.png.8e6e0e6ac0af59f84bf369eed26a9479.png
En vérifiant la base de données, j'ai aussi remarqué que la ligne pour id_order_invoice est vide, mais dans mon ancienne boutique (PS1.6.1.4), il y a l'identifiant order_invoice_id noté.

 

French translation with DeepL
Original text below.

 

Dear Pierre,

The shop's default currency is JPY. The customer ordered in EUR.

Today, I had another order where 2 different discounts apply. One is the same category discount (in %) and the other is a general 5% discount about the whole order.
The category discount is again in shop default currency, but the general discount is correct in customers currency.

I checked the database (`ps_order_cart_rule`) and there is the discount value (the category discount) saved in JPY even though the customer paid in different currency. The general discount is saved correct in customers currency.
When checking the database, I also noticed that the row for id_order_invoice is empty, but in my old shop (PS1.6.1.4), there is the order_invoice_id noted.

 

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Le 13/10/2023 à 2:17 AM, NSN a dit :

Cher Pierre,

La devise par défaut de la boutique est le JPY. Le client a commandé en EUR.

Aujourd'hui, j'ai reçu une autre commande pour laquelle deux remises différentes s'appliquent. L'une est la même remise par catégorie (en %) et l'autre est une remise générale de 5% sur l'ensemble de la commande.
La remise sur la catégorie est à nouveau dans la devise par défaut du magasin, mais la remise générale est correcte dans la devise du client.

Customer PDF invoiceScreenshot2023-10-13at08-53-19BBT291583_pdf.thumb.png.058fa3a79c02bcfbedd09a2ca813df00.png

Admin order pageScreenshot2023-10-13at08-52-59OrdersOrderS0934fromDavidJENKINSNipponShop.png.25b063612c7dd3c58b71586b20169dd4.png

J'ai vérifié la base de données (`ps_order_cart_rule`) et la valeur de la remise (la remise par catégorie) est sauvegardée en JPY même si le client a payé dans une autre devise. La remise générale est enregistrée correctement dans la devise du client.

Database table `ps_order_cart_rule`

Screenshot2023-10-13at09-02-33nl1-ts6.a2hosting.com_localhost_nipponsh_shop_ps_order_cart_rulephpMyAdmin5.2.1.png.8e6e0e6ac0af59f84bf369eed26a9479.png
En vérifiant la base de données, j'ai aussi remarqué que la ligne pour id_order_invoice est vide, mais dans mon ancienne boutique (PS1.6.1.4), il y a l'identifiant order_invoice_id noté.

 

French translation with DeepL
Original text below.

 

Dear Pierre,

The shop's default currency is JPY. The customer ordered in EUR.

Today, I had another order where 2 different discounts apply. One is the same category discount (in %) and the other is a general 5% discount about the whole order.
The category discount is again in shop default currency, but the general discount is correct in customers currency.

I checked the database (`ps_order_cart_rule`) and there is the discount value (the category discount) saved in JPY even though the customer paid in different currency. The general discount is saved correct in customers currency.
When checking the database, I also noticed that the row for id_order_invoice is empty, but in my old shop (PS1.6.1.4), there is the order_invoice_id noted.

 

Le problème est résolu dans la v17 à venir.

image.thumb.png.fe52af068a5910db82f87ee6438b78d6.png

image.thumb.png.bfcfee40ee388ae5018affb3816eb87f.png

image.png.53797092ba211ebd7059bd8e2d8447ff.png

image.png

  • Thanks 1
Link to comment
Share on other sites
NSN Enthusiast

NSN

Posted
Posted

Cher Pierre,

Merci beaucoup pour la correction.
Il y a une autre chose que j'ai remarquée avec les remises (en fait, ce problème existait aussi dans PrestaShop 1.6).
Il s'agit de l'arrondissement des prix.
Dans ce cas, il y avait une remise de 5% sur une commande de 14,590 Yen.
La remise est de 729,5 qui s'arrondit à 730. Le calcul est donc le suivant
14,590 + 5,000 (frais de port) - 730 = 18,860
Le client a payé avec PayPal et le montant facturé était exactement le montant qu'il devrait être (18,860 Yen), mais PrestaShop a défini la commande sur l'erreur de paiement parce que la facture et le back-office montrent un total de 18,861.

Backoffice:

Screenshot2023-10-15at21-51-17OrdersOrderS0941fromAngelaDENSLOWNipponShop.png.e1ff992930772dd57b8bac67fe85efb3.png

Invoice: (the invoice shows PayPal 18,861, but the real amount paid via PayPal is 18,860 which is, in my eyes, the correct amount.)Screenshot2023-10-15at21-51-57BBT291590_pdf.thumb.png.5c30229f971a453fcaad2251a68bc411.png

Les paramètres sont les suivants : "Arrondir à partir de zéro quand il est à moitié là (recommandé)" et "arrondir sur chaque ligne"

French translation with DeepL
Original text below.

 

Dear Pierre,

Thank you very much for the fix.
There is another thing I noticed with discounts (in fact, this problem existed also in original PrestaShop 1.6).
It's about price rounding.
In this case there was a 5% discount of an 14,590 Yen order.
The discount is 729,5 which rounds up to 730. The calculation then is
14,590 + 5,000 (shipping) - 730 = 18,860
The customer has paid with PayPal and the amount charged was exactly the amount it should be (18,860 Yen), but PrestaShop set the order on payment error because the invoice and back office shows a total of 18,861.

Settings are: "Round up away from zero when it's half there (recommended)" and "round on each line"

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted

Arrondir sur chaque ligne est une erreur car Prestashop n'a jamais compris que la somme des arrondis n'est pas égal à l'arrondi de la somme.

Dans PhenixSuite les commandes ayant un différentiel inférieur à 0.05 entre le total calculé et le total payé ne doivent pas passer en Erreur de paiement.

La commande est réellement dans le statut "Erreur de paiement" ou vous avez uniquement une alerte au niveau du bloc de paiement (Attention xxxx payé au lieu de yyyy) ?

Link to comment
Share on other sites
NSN Enthusiast

NSN

Posted
Posted

En effet, dans PrestaShop, j'ai généralement obtenu ce message d'erreur dans le panneau de contrôle de l'administrateur. Cela ne s'est pas produit avec PhenixSuite.

Quoi qu'il en soit, le client a reçu un email indiquant qu'il y avait un problème de paiement (statut de la commande 8 "payment_error"), ce qui est assez déroutant pour les clients. Il y a aussi le fait que la facture indique un montant payé qui est différent du montant qui a été réellement payé (je m'en fiche car je n'ai pas vraiment besoin de cette facture, mais d'autres marchands pourraient avoir besoin de factures correctes).

Quand vous dites que PrestaShop n'a jamais vraiment compris la façon d'arrondir par ligne, laquelle recommanderiez-vous ? "Arrondir sur chaque article" ou "Arrondir sur le total" ? Pour moi, peu importe la méthode d'arrondi que j'utilise, le seul objectif est que tout soit logique lorsque les clients vérifient leurs commandes, leurs factures et leurs paiements.

 

French translation with DeepL
Original text below.

 

Indeed, in PrestaShop I usually got that error message in admin control panel. This did not happen in PhenixSuite.

Anyway, the customer got an email that there was a payment problem (order status 8 "payment_error") which is quite confusing for customers. Also there is the point that the invoice shows a paid amount which is different from the amount that was really paid (I don't care as I don't really need that invoice, but other merchants might need correct invoices).

When you say that PrestaShop has never really understood the way of rounding per line, which one would you recommend? "Round on each item" or "Round on the total"? For me, it does not matter which way of rounding I use, the only target is that everything makes sense if customers check their orders, invoice and payments.

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted

La v17 devrait résoudre (enfin^^) ce problème des arrondis en ne se basant que sur le nombre de décimales utilisées par la boutique (ce que fait le module Paypal).

Pour l'instant mes tests sont concluants mais je vous assure que ce n'est pas une mince affaire.

  • Like 3
Link to comment
Share on other sites
NSN Enthusiast

NSN

Posted
Posted

Cher Pierre,

Merci beaucoup d'avoir résolu ce problème difficile et de longue date.
Je signalerai tous les problèmes que je remarquerai afin de contribuer au développement du système de boutique le plus fiable à ce jour.

Cordialement,
Stefan

  • Like 1
Link to comment
Share on other sites
Khundo2023 Collaborator

Khundo2023

Posted
Posted
18 hours ago, Eolia said:

La version PhenixSuite 1.6.2.17 est sortie;)

Cerise sur le gâteau :  https://tweet.phenixsuite.com/

Bonjour Eolia,

Grand Merci pour la version 17 je viens de mettre à jour sur mon sitetest.com v16 vers v17 tout semble correct

  • test achat en mode réel via paypal fonctionne bien
  • les mots de passes des employés avec caractères spéciaux tout ok...

Bon weekend à vous et à tous

  • Like 1
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 5 heures, Olivier33000 a dit :

Bonjour @Eolia

J'ai activé "à partir de" pour les déclinaisons mais je ne le vois afficher nulle part. Est-ce que c'est un ajout dans un template hooké ou le product-list.tpl ?

Cette option est disponible si votre thème est compatible mais pour l'instant il n'y a que default-bootstrap qui l'a.

Comparez le product-list.tpl de votre thème avec default-boostrap ( à la ligne 147 et suivantes)

image.thumb.png.7d981c6915159ae015db12da52447404.png

Link to comment
Share on other sites
Khundo2023 Collaborator

Khundo2023

Posted
Posted

Bonsoir Eolia,

Excusez moi de vous déranger

Pour la version 17 sur mon sitetest.com je viens d'avoir des Erreurs SQL lorsque je veux sauvegarder mon article ça m'afficher "Une erreur s'est produite pendant la mise à jour de l'objet. product ()"

Donc impossible d'enregistrer quelques soient

En mode débug ça m'affiche ça : 

[ ERREUR SQL ]
Colonne inconnue « never_discounted » dans la « liste de champs »
MISE À JOUR `ps_product` SET `id_product` = '6573',`id_shop_default` = '1',`id_manufacturer` = '43',`id_supplier` = '21',`reference` = '',`supplier_reference` = '' ,`emplacement` = '',`largeur` = '0',`hauteur` = '0',`profondeur` = '0',`poids` = '0,25',`quantity_discount` = '0',`ean13 ` = '',`upc` = '',`tariff_number` = '',`cache_is_pack` = '0',`cache_has_attachments` = '0',`is_virtual` = '0',`id_category_default` = '1848' ,`id_tax_rules_group` = '10',`on_sale` = '0',`online_only` = '0',`display_condition` = '1',`ecotax` = '0',`minimal_quantity` = '1',` price` = '4.78673',`wholesale_price` = '0',`unity` = 'masque',`unit_price_ratio` = '0',`additional_shipping_cost` = '0',`personnalisable` = '0',`text_fields` = '0',`uploadable_files` = '0',`active` = '1',`redirect_type` = '404',`id_product_redirected` = '0',`available_for_order` = '1',`available_date` = ' 0000-00-00',`condition` = 'nouveau',`never_discounted` = '0',`show_price` = '1',`indexed` = '0',`visibilité` = 'les deux',`cache_default_attribute` = '0',`advanced_stock_management` = '0',`date_add` = '2023-10-17',`date_upd` = '2023-10-21 21:01:42',`pack_stock_type` = '3', `increase_quantity_pack` = '1' OÙ `id_product` = 6573
DbCore->displayError dans /classes/db/Db.php:450
DbCore->requête dans /classes/db/Db.php:601
DbCore->mise à jour dans /classes/ObjectModel.php:683
ObjectModelCore -> mise à jour dans /classes/Product.php:641
ProductCore-> mise à jour dans /controllers/admin/AdminProductsController.php:2909
AdminProductsControllerCore->processUpdate dans /classes/controller/AdminController.php:1257
AdminControllerCore->processSave dans /classes/controller/AdminController.php:1056
AdminControllerCore->postProcess dans /controllers/admin/AdminProductsController.php:2104
AdminProductsControllerCore->postProcess dans /classes/controller/Controller.php:201
ControllerCore->exécuter dans /classes/Dispatcher.php:405
DispatcherCore -> expédition dans /adminphenixxxx/index.php:79

Pouvez vous jeter un oeil dessus et me dire la cause de ces erreurs, svp 

Merci par avance,

Cordialement

Khundo

Link to comment
Share on other sites
bobby4722 Enthusiast

bobby4722

Posted
Posted (edited)

Bonsoir Pierre,

Suite MAJ vers 16218 pour faire en urgence face à mes clients et nos conversations....
Impossible mettre un mail de rappel à 2 jours, j'ai un message d'erreur. De plus vu que mon site est en 23 langues il m'indique que il manque des traductions...alors que j'ai traduit ! 😕
Si besoin tu peux t'en servir pour élargir notre communautée ;)

Très bon weekend à toi. 😀

Edited by bobby4722 (see edit history)
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 2 heures, Olivier33000 a dit :

Je viens aussi de tester un avoir avec "utilisation partielle" qui est sensé générer un nouveau code (probablement une nouvelle règle panier) avec le solde mais il n'y a rien en BO, et forcément rien sur le panier.

Bonsoir,

Pouvez-vous être un peu plus explicite ?

Comment et quoi avez-vous testé ? Vous avez effectué un remboursement partiel avec génération d'avoir, c'est cela ?

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
il y a 45 minutes, bobby4722 a dit :

Bonsoir Pierre,

Suite MAJ vers 16218 pour faire en urgence face à mes clients et nos conversations....
Impossible mettre un mail de rappel à 2 jours, j'ai un message d'erreur. De plus vu que mon site est en 23 langues il m'indique que il manque des traductions...alors que j'ai traduit ! 😕
Si besoin tu peux t'en servir pour élargir notre communautée ;)

Très bon weekend à toi. 😀

Je vois que tu as configuré les rappels à 2 jours et les annulations à 2 jours aussi doncil y a un truc qui ne va pas...

Quel modèle de mail choisi ? s'il n'existe pas dans ton thème il faut commencer par l'ajouter (payment_reminder.html dispo dans le répertoire /mails du core)

C'est quoi le message d'erreur ?

Link to comment
Share on other sites
bobby4722 Enthusiast

bobby4722

Posted
Posted (edited)
29 minutes ago, Eolia said:

Je vois que tu as configuré les rappels à 2 jours et les annulations à 2 jours aussi doncil y a un truc qui ne va pas...

Quel modèle de mail choisi ? s'il n'existe pas dans ton thème il faut commencer par l'ajouter (payment_reminder.html dispo dans le répertoire /mails du core)

C'est quoi le message d'erreur ?

Alors en fait oui tu as raison j'avais mal sélectionné l'effacement de commande.MAIS le truc c'est d'envoyer un reminder toute les 48H aux clients qui n'ont pas fait le virement donc tache cron mais j'ai ca même si c'est un vieux module bien pourris sans doute :D:D.
Bah, j'ai traduit la version EN qui n'existant pas en FR, mais comme impossible d'avoir une aperçu, j'ai relu mon mail de rappel et donc j'ai utilisé le template que j'avais... On est samedi soir il fallait pas que je me mette non plus des challenges lol :D .
Le message d'erreur concernait mes langues et m'indiquait qu'elles sont non traduite alors que c'est bien le cas.

PS: Le forum de presta pour mobile entre la pub et le cookie qui ne veut pas se valider, c'est de la m....
Bon weekend à tous ! :)
Donc obligé d’allumer

un ordinateur

 

Edited by bobby4722 (see edit history)
Link to comment
Share on other sites
Olivier33000 Contributor

Olivier33000

Posted
Posted
47 minutes ago, Eolia said:

Bonsoir,

Pouvez-vous être un peu plus explicite ?

Comment et quoi avez-vous testé ? Vous avez effectué un remboursement partiel avec génération d'avoir, c'est cela ?

Pas de remboursement partiel mais un retour produits avec génération d'un avoir et de code (règle panier pourtant définie avec une utilisation partielle -donc tant qu'il reste du crédit, une nouvelle règle est créée pour obtenir une partie ou la totalité de l'avoir).

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 11 heures, Olivier33000 a dit :

Pas de remboursement partiel mais un retour produits avec génération d'un avoir et de code (règle panier pourtant définie avec une utilisation partielle -donc tant qu'il reste du crédit, une nouvelle règle est créée pour obtenir une partie ou la totalité de l'avoir).

Je suis désolé mais je ne comprends toujours pas.

Les retours et les avoirs sont 2 choses différentes.

Un client effectue une demande de retour, vous l'acceptez, vous attendez le colis, vous le recevez et le traitement physique du retour est alors terminé.

Suite à ce retour, vous décidez ou pas d'effectuer un avoir (pièce comptable correspondant à une facture négative).

- Vous allez donc dans la commande, sélectionnez "remboursement partiel", sélectionnez le produit concerné dans la commande, entrez sa quantité, le prix du remboursement et choisissez de créer un bon d'achat ou pas (si pas de bon il faut rembourser le client via le module de paiement concerné)

- Si vous avez choisi la création d'un bon d'achat celui-ci sera généré en utilisation partielle.

image.png.e0f4bbc4b7593985ff476119bdd552cb.pngimage.png.6ccae7a925277eb1097f9bca70ec3c47.png

image.png.abfd3b681a30d3765921def9b56f0085.png

image.png.902158614d451e0f31b88d4d2448a66a.png

Link to comment
Share on other sites
Olivier33000 Contributor

Olivier33000

Posted
Posted

C'est tout à fait ça, sauf que je n'ai pas fait de remboursement partiel, il y avait déjà les options pour créer un avoir avec création de bon d'achat (sans avoir à cliquer sur remboursement partie, mais uniquement sur retour produits, puis sélection des produits et cases à cocher avoir + code ... et enfin "retourner les produits" (cette fois en bas de page après la sélection des cases à cocher). Ça m'a bien créé un avoir avec utilisation partielle, mais après avoir utilisé une partie de cet avoir, ça n'a pas créé une nouvelle règle panier avec le reste de l'avoir.

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
il y a 48 minutes, Olivier33000 a dit :

C'est tout à fait ça, sauf que je n'ai pas fait de remboursement partiel, il y avait déjà les options pour créer un avoir avec création de bon d'achat (sans avoir à cliquer sur remboursement partie, mais uniquement sur retour produits, puis sélection des produits et cases à cocher avoir + code ... et enfin "retourner les produits" (cette fois en bas de page après la sélection des cases à cocher). Ça m'a bien créé un avoir avec utilisation partielle, mais après avoir utilisé une partie de cet avoir, ça n'a pas créé une nouvelle règle panier avec le reste de l'avoir.

Ok, je comprends mieux quand on m'explique :) 

Effectivement il y a un bug que je viens d'identifier à ce niveau, le correctif est en cours.

Link to comment
Share on other sites
P i l o u Community Regular

P i l o u

Posted
Posted (edited)

Bonjour Eolia,

Petit soucis avec la 18 aujourd'hui.

Nouvel article avec déclinaisons, le système n'enregistre pas les déclinaisons que ce soit en manuel ou via le gestionnaire de déclinaison.

Pire, si on veut modifier une déclinaison d'un article déjà existant, il vire toutes les déclinaisons déjà encodées..
Un message apparaît lors de la sauvegarde : Une erreur s'est produite pendant la mise à jour de l'objet. product ()

 

Edited by P i l o u (see edit history)
Link to comment
Share on other sites
  • 2 weeks later...
Olivier33000 Contributor

Olivier33000

Posted
Posted

Bonjour,

depuis la dernière version (je suppose) j'ai une erreur lors de l'inscription (je ne peux plus me connecter non plus avec des identifiants de la bdd) : Unknown column 'secret_key' in 'field list' (insert into ps_customer ...). Ça a été introduit dans la classe customer (ainsi que tfa).

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted

Hum... vous avez dû rater un upgrade alors^^

1.6.2.6.sql: 

SET NAMES 'utf8';
SET sql_mode = '';

ALTER TABLE `PREFIX_employee`
	ADD `secret_key` varchar(48) COLLATE 'utf8_general_ci' DEFAULT NULL AFTER `passwd`,
	ADD `tfa` tinyint(1) unsigned NOT NULL DEFAULT '0' AFTER `secret_key`;
	
ALTER TABLE `PREFIX_customer`
	ADD `secret_key` varchar(48) COLLATE 'utf8_general_ci' DEFAULT NULL AFTER `passwd`,
	ADD `tfa` tinyint(1) unsigned NOT NULL DEFAULT '0' AFTER `secret_key`;

Remplacez PREFIX_ par votre préfixe de table

Link to comment
Share on other sites
  • 2 weeks later...
JLCH Explorer

JLCH

Posted
Posted (edited)

Bonjour, super travail... nous avons mis à jour plusieurs sites en TB et PS 1.6 vers PhenixSuite. juste nikel!!!

je cherche à régler ça : "Ce module cronjobs utilise à tort une variable qui n'a pas été déclarée dans sa classe ["display"]" (Éditeur de tâches cron v10 - par Eolia).

merci

Edited by JLCH (see edit history)
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 2 heures, JLCH a dit :

Bonjour, super travail... nous avons mis à jour plusieurs sites en TB et PS 1.6 vers PhenixSuite. juste nikel!!!

je cherche à régler ça : "Ce module cronjobs utilise à tort une variable qui n'a pas été déclarée dans sa classe ["display"]" (Éditeur de tâches cron v10 - par Eolia).

merci

Vous êtes en quelle version Phenix car dans les dernières (v11 du module) la variable est bien déclarée:

image.png.764e0295f19e211601a555a52bd9efca.png

Link to comment
Share on other sites
clawz Apprentice

clawz

Posted
Posted

Bonjour A tous.

J'ai mis a jour mon site en verion 1.20 depuis la 1.16 et depuis j'ai plus accès au back office. je ne sais vraiment pas quoi faire.

Quelqu'un a déjà eu le problème, sachant que je suis en mode debug et que je n'ai pas de message.

mon site.jpg

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
à l’instant, clawz a dit :

Bonjour A tous.

J'ai mis a jour mon site en verion 1.20 depuis la 1.16 et depuis j'ai plus accès au back office. je ne sais vraiment pas quoi faire.

Quelqu'un a déjà eu le problème, sachant que je suis en mode debug et que je n'ai pas de message.

mon site.jpg

Aucune erreur pendant l'upgrade ?

Envoyez-moi un accès FTP en Message Privé si vous voulez que j'intervienne.

Link to comment
Share on other sites
P i l o u Community Regular

P i l o u

Posted
Posted

Bonjour,

V1.6.2.20 Php 7.4

En cherchant pourquoi une règle panier ne fonctionne plus (qui consiste à offrir un article si le client en achète un autre), j'ai activé le mode Debug.

En FO, lors de l'ajout d'un article au panier, j'ai le message suivant:

Impossible to add the product to the cart.
textStatus: 'parsererror'
errorThrown: 'SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data'
responseText:

Erreur de syntaxe, JSON malformé. ({ "products": [ { "id": 1064, "link": "https:\/\/***\/1064-dji-mavic-3-pro.html", "quantity": 3, "image": "https:\/\/***\/4168-medium_default\/dji-mavic-3-pro.jpg", "image_cart": "https:\/\/***\/4168-small_default\/dji-mavic-3-pro.jpg", "priceByLine": "13 347,00 \u20ac", "name": "DJi Mavic 3 Pro", "name_truncated": "DJi Mavic 3 Pro", "price": "4 449,00 \u20ac", "price_float": 11030.58, "idCombination": 6404, "idAddressDelivery": 129, "is_gift": false, "hasAttributes": true, "attributes": "Mavic 3 Pro Cine Premium Combo", "hasCustomizedDatas": false, "customizedDatas": [ ] }], "discounts": [ ], "shippingCost": "0,00 \u20ac", "shippingCostFloat": 0, "wrappingCost": "0,00 \u20ac", "nbTotalProducts": 3, "total": "13 347,00 \u20ac", "productTotal": "13 347,00 \u20ac", "freeShipping": "0,00 \u20ac", "freeShippingFloat": 0, "free_ship":
Warning: Creating default object from empty value in /home/***/cache/smarty/compile/5c/75/ef/5c75efb851b82f0f45ece9ca0743f81a69047ea2_0.file.blockcart-json.tpl.php on line 219
true, "isVirtualCart": 0, "hasError" : false })

ToolsCore::jsonDecode in /modules/blockcart/blockcart.php:231

BlockCart->hookAjaxCall in /modules/blockcart/blockcart-ajax.php:29

require_once in /controllers/front/CartController.php:681

CartControllerCore->displayAjax in /classes/controller/Controller.php:234

ControllerCore->run in /classes/Dispatcher.php:405

DispatcherCore->dispatch in /index.php:28

 

 

Toujours en FO, si on supprime un article du panier:

TECHNICAL ERROR: unable to save update quantity Details: Error thrown: [object Object] Text status: parsererror

Link to comment
Share on other sites
P i l o u Community Regular

P i l o u

Posted
Posted

Voilà 

"free_ship": <?php echo call_user_func_array($_smarty_tpl->registered_plugins[ 'modifier' ][ 'json_encode' ][ 0 ], array( (!$_smarty_tpl->tpl_vars['shipping_cost_float']->value && !count($_smarty_tpl->tpl_vars['cart']->value->getDeliveryAddressesWithoutCarriers(true,$_smarty_tpl->tpl_vars['errors_back']->value))) ));?>

 

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted

Ok, donc le code est conforme.

Le pb doit venir de l'appel à la sous-fonction qui cherche les transporteurs disponible (soit un problème sur un transporteur incorrect, soit un module accroché au hook actionModifiyCarrierList.

Rappelez moi l'url de votre je dois avoir le ftp.

Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted

Ok, trouvé sur votre site de dev

ligne 87 de votre fichier /themes/modules/blockcart-json.tpl non-conforme: 

"free_ship": {(!$shipping_cost_float && !count($cart->getDeliveryAddressesWithoutCarriers(true, $errors_back)))|json_encode},

remplacée par : 

"free_ship": {(!$shipping_cost_float && !count($cart->getDeliveryAddressesWithoutCarriers(true)))|json_encode},

 

  • Like 1
Link to comment
Share on other sites
  • 3 weeks later...
Khundo2023 Collaborator

Khundo2023

Posted
Posted

Bonsoir Eolia et à tous

Merci pour  la version 21 mais lors, mise à jour sur mon site prod je n'ai plus de logo sur la facture invoice.pdf pouvez vous m'aider à fixer cela svp ?

Sur mon site test tout est ok 

Mais je ne sais pas par quel chemin comment récupérer les données du test vers site prod 

de l'aide svp

Merci par avance

Khundo

Link to comment
Share on other sites
bobby4722 Enthusiast

bobby4722

Posted
Posted
14 minutes ago, Khundo2023 said:

Bonsoir Eolia et à tous

Merci pour  la version 21 mais lors, mise à jour sur mon site prod je n'ai plus de logo sur la facture invoice.pdf pouvez vous m'aider à fixer cela svp ?

Sur mon site test tout est ok 

Mais je ne sais pas par quel chemin comment récupérer les données du test vers site prod 

de l'aide svp

Merci par avance

Khundo

J'ai eu le même soucis, tu attends un peu et le pdf est ok. Je ne connais pas la cause. J'ai le même soucis également mais j'ai pas relevé par peu de volume de commande mais ca fait quelques version effectivement que cela à l'air d'être le cas. Sur un site jamais rien n'est ok à 100% moi j'ai un soucis d’enregistrement des traductions qui disent ok puis non (pour faire simple)... Rien n'est parfait et c'est beaucoup beaucoup de taf pour @Eolia

Link to comment
Share on other sites
Khundo2023 Collaborator

Khundo2023

Posted
Posted (edited)
Il y a 5 heures, bobby4722 a dit :

J'ai eu le même soucis, tu attends un peu et le pdf est ok. Je ne connais pas la cause. J'ai le même soucis également mais j'ai pas relevé par peu de volume de commande mais ca fait quelques versions effectivement que cela à l'air d'être le cas. Sur un site jamais rien n'est ok à 100% moi j'ai un soucis d'enregistrement des traductions qui disent ok puis non (pour faire simple)... Rien n'est parfait et c' 39;est beaucoup beaucoup de taf pour@Eolia

Merci Bobby, 

Monsieur EOLIA m'avait déjà donné la solution en juin 2023

Bonnes fêtes à vous tous Mille Merci encore pour tout

 

 

Edited by Khundo2023 (see edit history)
Link to comment
Share on other sites
  • 3 weeks later...
Lionel_JDN Apprentice

Lionel_JDN

Posted
Posted (edited)

Bonjour Eolia,

Mes meilleurs vœux pour 2024 et un grand merci pour tout ce travail fantastique ainsi qu'aux contributeurs !

Je viens d'installer la version 1.6.2.22 de PhenixSuite après un upgrade depuis la version 1.6.1.24 et voici le rendu en front-office :

Screenshot 2024-01-03 at 16-20-06 Commande - PhenixSuite.png

 

J'ai l'impression que certains styles ne se chargent pas. Est-ce que vous avez déjà rencontré cela s'il vous plaît ?

Merci beaucoup pour vos conseils.

Lionel

Edited by Lionel_JDN (see edit history)
Link to comment
Share on other sites
Eolia Grand Master

Eolia

Posted
  • Author
Posted
Il y a 4 heures, Lionel_JDN a dit :

Bonjour Eolia,

Mes meilleurs vœux pour 2024 et un grand merci pour tout ce travail fantastique ainsi qu'aux contributeurs !

Je viens d'installer la version 1.6.2.22 de PhenixSuite après un upgrade depuis la version 1.6.1.24 et voici le rendu en front-office :

Screenshot 2024-01-03 at 16-20-06 Commande - PhenixSuite.png

 

J'ai l'impression que certains styles ne se chargent pas. Est-ce que vous avez déjà rencontré cela s'il vous plaît ?

Merci beaucoup pour vos conseils.

Lionel

Vous avez bien coché "mettre à jour le thème par défaut" lors de la mise à jour ?

Link to comment
Share on other sites
Lionel_JDN Apprentice

Lionel_JDN

Posted
Posted
14 hours ago, Eolia said:

Vous avez bien coché "mettre à jour le thème par défaut" lors de la mise à jour ?

Bonjour Eolia,

Merci pour votre retour, je vous joins un screenshot des options sélectionnées par défaut sur la boutique pour le module autoupgrade.
Je vais essayer d'installer PhenixSuite directement depuis le script phenix-install.php au lieu de passer par une version intermédiaire 1.6.1.24.

Excellente journée.

Lionel

Capture d'écran 2024-01-04 102219.png

Link to comment
Share on other sites
Lionel_JDN Apprentice

Lionel_JDN

Posted
Posted
15 hours ago, Eolia said:

Pouvez-vous ouvrir votre console (F12) et regarder le ou les messages d'erreurs ? (et éventuellement activer le mode debug dans la BO)

Bonjour Eolia,
Je n'ai pas d'erreur dans la console.

Et le mode Debug indique simplement ceci : 

Warning: Use of undefined constant _RIJNDAEL_KEY_ - assumed '_RIJNDAEL_KEY_' (this will throw an Error in a future version of PHP) in /home/jdnadm/www/phenixsuite/classes/Cookie.php on line 83

Warning: Use of undefined constant _RIJNDAEL_IV_ - assumed '_RIJNDAEL_IV_' (this will throw an Error in a future version of PHP) in /home/www/phenixsuite/classes/Cookie.php on line 83

Warning: openssl_decrypt(): IV passed is only 7 bytes long, cipher expects an IV of precisely 16 bytes, padding with \0 in /home/www/phenixsuite/classes/Rijndael.php on line 97

Warning: Use of undefined constant _RIJNDAEL_KEY_ - assumed '_RIJNDAEL_KEY_' (this will throw an Error in a future version of PHP) in /home/www/phenixsuite/classes/Cookie.php on line 83

Warning: Use of undefined constant _RIJNDAEL_IV_ - assumed '_RIJNDAEL_IV_' (this will throw an Error in a future version of PHP) in /home/www/phenixsuite/classes/Cookie.php on line 83

Warning: openssl_decrypt(): IV passed is only 7 bytes long, cipher expects an IV of precisely 16 bytes, padding with \0 in /home/www/phenixsuite/classes/Rijndael.php on line 97

Mais je vais installer PhenixSuite directement depuis le script phenix-install.php pour voir si je reproduis ce souci.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...