🌍
Français
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 ;-)
Bonjour.
En attendant une prochaine mise à jour.
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;
}
A+
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...
Bravo pour ce plugin qui évite qu'on se pourrisse trop la vie online :)
Pour info, la fenêtre d'administration présente un petit défaut de skin. Dois-je notifier le bugtracker ?
Je vais regarder les possibilités.
Et par le trigger lié directement à la fonction pwg_mail() :
trigger_event('send_mail',
false, /* Result */
trigger_event('send_mail_to', get_strict_email_list($to)),
trigger_event('send_mail_subject', $cvt_subject),
trigger_event('send_mail_content', $content),
trigger_event('send_mail_headers', $headers),
$args
);On ne pourrait pas générer le blocage à partir de là ?
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?
Tu veux que j'ouvre un bug dans le bugtracker du plugin ?
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...
cljosse a écrit:
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 ?
Et ? Si c'est une détection comme spam qui bloque l'envoie du mail, cela ne change rien. Le mail n'est pas envoyé donc les process qui en découlent devraient en tenir compte. Sur une NBM, par exemple, si un mail ne part pas pour cause de détection comme spam (ou toute autre raison), le compte destinataire ne devrait pas disparaitre de la liste des personnes à notifier quoi qu'il arrive. C'est seulement lorsque le mail est réellement parti qu'il peut être considéré comme "notifié".
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 freeJe 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 ?
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 ?
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 ?
Super !
Comme je te le disais par MP, donc, je teste dans la semaine.
Bonjour.
Livraison de la version 1.5.3 de extension:315
- Ajout de la mémorisation des erreurs dans un fichier log:
sous _data/mail_supervisor_log
- Ajout option débogage.
Affichage des informations envoyées.
- 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
A+
cljosse a écrit:
Normalement il ne devrait pas avoir de détection de spam
+1
cljosse a écrit:
à moins que tu aies été déclaré comme un spammeur...
!!
Euh... je ne crois pas...
cljosse a écrit:
Si tu veux me passer en admin+webmestre utilisateur( cl.josse ) sur ta galerie(http://michelisabeth2.free.fr/pwg22rc3) que je puisse ce week-end tester à mes moments perdus avec un plugin de débogage.
Voilà qui est fait. Je l'ai fait aussi sur lucmorizur.free.fr/tests/mail/pwg220 et lucmorizur.free.fr/tests/mail/pwg216 afin que tu puisses comparer si nécessaire.
Merci beaucoup pour ton intérêt.