Eric a écrit:

cljosse a écrit:

- Ajout d'un test sur la présence de "boundary_key" dans le headers.
   Bloque l'envoi du message, si cette clef manque.
    En effet durant les tests éffectués, de temps en temps cette "clef" n'était pas envoyée avec le header !!! --> spam détecté par free

Je viens d'être victime de cette "perte" du "boudary_key" sur ma galerie chez E-clicking lors d'un envoie de notification NBM. Ce qui est bizarre c'est le caractère aléatoire du phénomène. En effet, la première tentative a échouée avec cette erreur "ERREUR manque : boundary_key dans le headers " mais la seconde, sur le même destinataire, est passée sans pb. As-tu une idée du pourquoi de cette perte ?

Je ne vois pas pourquoi , et étant donné le faible taux de reproduction, il est difficle de reproduire ce défaut.
- Comme solution je peux toujours regenerer le boundary_key, s'il est manquant.

Eric a écrit:

Autrement, ce serait bien, quand un pb d'envoi est détecté, de bloquer les mécanismes liés. Je m'explique:
Lorsque j'ai eu l'erreur de boundary sur une NBM, le destinataire du mail en défaut a disparu de la liste des utilisateurs à notifier comme si la notification s'était bien passée alors que ce n'était pas le cas. Du coup, il m'a fallu "tricher" dans la BDD pour réinitialiser l'état de cet utilisateur pour qu'il réapparaisse dans la liste à notifier. Ce serait bien que, si le mail ne part pas (quelque soit la raison), la suite du process reste dans l'état avant la tentative de notification.

Ceci est un exemple basé sur la NBM mais c'est aussi valable pour d'autres plugins (comme UAM ^^) qui utilisent la fonction pwg_mail().

Je ne sais pas si ce comportement peut être réalisé via Mail_Supervisor. Qu'en penses-tu ?

J'y est pensé , mais si le défaut génère un spam ?

Exact, j'ai répondu un peu trop vite :-). Je dois vérifier au niveau des comptages de mails,spam.

Effectivement si le mail n'est pas envoyé , il devrait toujours être en attente d'envoi, je vais regarder du coté du retour de la fonction, et quand la notification disparait.
   Il me semble aussi qu'il y a un problème du même genre lors de l'inscription des usagers, si le mail est refusé l'inscription est quand même effectué.
   Il faut que je me replonge dans tout ça...

La fonction mail() retourne soit du texte s'il y a une erreur ou true si tout est ok.
Avec mail_supervisor je suis forcé de retourner autre chose que false, la fonction "send_mail" est executée.
  Si je renvoie tu texte  "notification_by_mail.php" considere que le mail s'est déroulé correctement.
D'ou le problème.

- Une solution existe :
Dans notification_by_mail.php
Par exemple.
ligne 389:
             if (pwg_mail
                  (
                    format_email(stripslashes($nbm_user['username']), $nbm_user['mail_address']),
                    array
                    (
                      'from' => $env_nbm['send_as_mail_formated'],
                      'subject' => $subject,
                      'email_format' => $env_nbm['email_format'],
                      'content' => $env_nbm['mail_template']->parse('notification_by_mail', true),
                      'content_format' => $env_nbm['email_format'],
                      'theme' => $nbm_user['theme']
                    )
                  )[b]=="true"|/b])

dans ce cas Mail_supervisor pourrait renvoyer un information d'erreur qui pourrait être traitée par la suite par les fonctions appellantes.

Qu'en penses tu?

Je vais regarder les possibilités.

makno a écrit:

Pour info, la fenêtre d'administration présente un petit défaut de skin.

Je ne reproduis pas ce problème sur mes galeries...

Eric a écrit:

Je ne reproduis pas ce problème sur mes galeries...

cljosse a écrit:

On peut contourner ce pb en utilisant le plugin "LocalFiles Editor"
       Editer le fichier:  "local/css/rules.css"
Ajouter les lignes suivantes.


.throw{
  background-color:transparent;
}

Arfff !! J'ai oublié que j'avais déjà corrigé le css sur mes galeries ;-)