• alpha2

    (@neoseeyou)


    Bonjour,

    Depuis l’activation de HPOS sur notre site WooCommerce, nous rencontrons un problème avec la génération des étiquettes retour via CDI.

    L’étiquette aller fonctionne correctement. En revanche, lorsque nous cliquons sur le bouton de génération d’une étiquette retour depuis la métabox CDI :

    • la page se recharge ;
    • aucun message d’erreur n’est affiché ;
    • aucun bouton ou lien de téléchargement n’apparaît ;
    • le numéro de retour est pourtant bien créé et enregistré dans la commande ;
    • _cdi_meta_return_executed est également enregistré à yes ;
    • mais _cdi_meta_base64_return n’est jamais créé et _cdi_meta_pdfurl_return reste vide.

    Nous avons reproduit exactement le même comportement sur notre site de développement également configuré avec HPOS.

    Le problème semble donc se situer dans la récupération ou l’extraction du PDF renvoyé par Colissimo après la création du retour, et non dans la création du colis retour elle-même.

    Pouvez-vous vérifier la compatibilité HPOS de ce traitement, notamment dans :

    includes/CDI-Carrier-colissimo/Colissimo-Retourcolis.php
    includes/CDI-Carrier-colissimo/Colissimo-Affranchissement.php

    Merci par avance pour votre retour.

    Cordialement,

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter alpha2

    (@neoseeyou)

    Une piste semble être la structure de la table wp_wc_orders_meta : sur notre installation, la colonne meta_value était définie en TEXT. Or le PDF retour encodé en base64 dépassait largement cette capacité, ce qui pourrait expliquer pourquoi le numéro de retour était bien enregistré, mais pas _cdi_meta_base64_return.

    Après passage de cette colonne en LONGTEXT, la génération et l’affichage des étiquettes retour ont de nouveau fonctionné.

    Pouvez-vous vérifier si cette hypothèse est cohérente avec le fonctionnement du module et si ce point doit être contrôlé côté CDI ou lors de la migration HPOS ?

    Plugin Author Halyra

    (@harasse)

    Bonjour,

    C’est très certainement ça. La postmeta : meta_value de WordPress est en longtext, alors que Woocommerce créé sa wc_orders_meta : meta_value censée la remplacer , en text. Or selon les transporteurs et les types d’étiquette et leurs éventuels logo elles peuvent dépasser les 64K.

    Avez-vous eu dans vos logs une erreur du type « Data too long for column meta_value » par WordPress ou Woocommerce ?

    Constatez-vous des problèmes de performances sur votre site de prod après être passé en longtext ?

    Thread Starter alpha2

    (@neoseeyou)

    Merci pour votre retour, cela confirme bien la piste identifiée.

    Nous n’avons pas retrouvé dans les logs d’erreur explicite du type :

    Data too long for column 'meta_value'

    Le comportement était silencieux : le numéro de retour était bien créé et enregistré, mais la métadonnée _cdi_meta_base64_return était absente.

    Nous avons uniquement passé wc_orders_meta.meta_value en LONGTEXT sur notre site de développement. La modification a été assez longue et phpMyAdmin a retourné un timeout 504, même si l’opération s’est finalement terminée (semble t il) correctement côté base.

    Après cette modification, l’étiquette retour et le CN23 ont bien été enregistrés et affichés. Nous n’avons pas constaté de problème de performance particulier sur le site de développement.

    Nous n’avons pas encore appliqué la modification sur la production, compte tenu de la taille importante de la table et du risque de verrouillage ou de ralentissement pendant l’ALTER TABLE.

    Avez-vous une recommandation pour effectuer cette modification en production de manière sécurisée ?

    Cordialement,

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.