J'ai tenté une approche qui me paraissait bien... Au départ...
Avant la génération du mail, j'ai testé la présence à ON de FCK Editor sur le champ texte en question pour appliquer un html_entity_decode() au texte remanié par le plugin. Cà a fonctionné pour un champ de texte précis mais, dans le cas de la validation de l'inscription, il y a deux champs distincts : Un pour la partie information et l'autre pour la partie validation. L'un comme l'autre pouvant supporter FCK Editor indépendamment.
C'est là que çà s'est gâté : Les caractères transcodés n'étaient plus lisibles du tout sur les mails reçu (présence d'un "?" à la place). Plus le fait que, pour une raison encore indéterminée, même le sujet du mail est impacté par le html_entity_decode() alors qu'il n'a rien à voir dans l'histoire...
Je ne laisse pas tomber mais je mets cette partie entre parenthèses pour la prochaine version de NBC_UAM (qui devrait sortir ce soir).
Tes idées ont souvent fait bouger les choses, ami Gotcha ;-)
Mais là, je ne vois vraiment pas comment ton idée pourrait résoudre le problème des caractères accentués transformés en code par FCK Editor et re-transformés par la fonction htmlspecialchars utilisée dans pwg_mail().
Peut-être en échappant les codes HTML des caractères accentués avant le passage à pwg_mail pour qu'ils ne soient pas re-traités ? Je ne sais pas si c'est réalisable. Je verrai ce soir...
En fait j'imagine non pas des champs visibles par le webmaster mais dans la BDD.
Suivant la destination de l'information, ton plugin irait cherchez soit dans le champs "simple" ou bien dans le champs "complet" mais du coté de la BDD uniquement.
C'est juste une idée... :-s
Je ne suis pas certain de bien comprendre le fond de ton raisonnement. Doubler les champs de saisie de textes additionnels pour les mails générés par UAM ?
Déjà que l'interface, bien qu'édulcorée, est assez chargée... Et puis cela ne changerait rien au problème puisque les mails seront toujours envoyés via la fonction pwg_mail. Le problème resterait entier sauf à réécrire une fonction d'envoi de mail spécifique à ce cas de figure.
J'ai peur de brasser beaucoup d'air pour un résultat et une plus-valu des plus limitée.
Une réflexion très "neuneu" mais pourquoi ne pas doubler le champs afin que l'un soit géré par la FCK Editor et l'autre par NBM ?
Bon, finalement, je crois que l'utilisation de FCK Editor pour gérer des contenus de mails est définitivement incompatible. J'ai regardé la fonction pwg_mail() car je pense que le pb vient de là. Effectivement, pour les contenus HTML de mails passent par un htmlspecialchars. Ce qui est tout à fait normal et recommandé pour des contenus bruts.
Mais comme FCK Editor opère déjà une transformation de caractères en code, la fonction htmlspecialchars re-transforme les codes générés. D'où les & ajoutés devant chaque code de caractère accentué.
La doc de CKEditor ne donne aucune info sur la possibilité de désactiver la gestion des caractères accentués. Et c'est un peu normal dans le sens où il s'agit d'un éditeur pour pages HTML publiées et pas pour des contenus de mails. Détourner son utilisation dans ce sens ne me parait pas réalisable.
C'est cljosse qui va être déçu ;-)
Eric a écrit:
P@t a écrit:
Je ne crois pas que ce soit prévu... à vérifier dans la la doc de FCK Editor.
Bizarre qu'un client mail ne supporte pas le HTML...Thunderbird supporte normalement très bien le HTML. En fait, je pense qu'il s'agit d'un problème à la génération du mail. Pb à l'encodage ? J'utilise pourtant pwg_mail()... A voir.
Oui, c'est bien çà. Voici le source d'un texte de mail géré par FCK Editor :
Bonjour. Ceci est un message de rappel car vous vous êtes inscrits sur notre galerie mais vous n'avez pas validé votre inscription
Et voici le source de ce même texte reçu par mail :
Ceci est un message de rappel car vous vous êtes inscrits sur notre galerie mais vous n'avez pas validé votre inscription
Il y a & qui s'ajoute devant chaque code de caractère accentué et c'est çà qui empêche le client mail d'interpréter l'info correctement.
P@t a écrit:
Je ne crois pas que ce soit prévu... à vérifier dans la la doc de FCK Editor.
Bizarre qu'un client mail ne supporte pas le HTML...
Thunderbird supporte normalement très bien le HTML. En fait, je pense qu'il s'agit d'un problème à la génération du mail. Pb à l'encodage ? J'utilise pourtant pwg_mail()... A voir.
P@t a écrit:
Eric a écrit:
Question subsidiaire : Je ne parviens pas à faire en sorte que FCK Editor soit à OFF par défaut sur mes champs de texte. Je préfèrerai que les utilisateurs du plugin NBC_UAM activent la saisie FCK Editor en toute connaissance de cause.
Ca par contre, ca doit etre jouable...
Merci P@t, la deuxième solution correspond tout à fait au fonctionnement souhaité !
Eric a écrit:
J'ai ensuite implémenté le code pour permettre l'utilisation de FCK Editor pour les champs texte personnalisables dans les emails. Si je n'ai plus de pb avec la gestion des ";", il perdure malgré tout pour les caractères accentués et spéciaux qui sont systématiquement transformés en code. Comme il s'agit de contenu de mails, à leur réception, il ne sont pas interprétés par les clients emails. En tous cas, pas avec mon Thunderbird 3.0.3.
Je ne crois pas que ce soit prévu... à vérifier dans la la doc de FCK Editor.
Bizarre qu'un client mail ne supporte pas le HTML...
Eric a écrit:
Question subsidiaire : Je ne parviens pas à faire en sorte que FCK Editor soit à OFF par défaut sur mes champs de texte. Je préfèrerai que les utilisateurs du plugin NBC_UAM activent la saisie FCK Editor en toute connaissance de cause.
Ca par contre, ca doit etre jouable...
Pour que FCK Editor soit systématiquement désactivé par défaut sur tes champs:
$toolbar = 'Basic';
$width = '750px';
$height = '300px';
$areas = array();
array_push( $areas,'UAM_MailInfo_Text','UAM_ConfirmMail_Text','UAM_GhostTracker_ReminderText','UAM_ConfirmMail_ReMail_Txt1','UAM_ConfirmMail_ReMail_Txt2');
if (function_exists('set_fckeditor_instance'))
{
$fcke_config = unserialize($conf['FCKEditor']);
foreach($areas as $area)
{
$fcke_config[$area] = false;
}
$conf['FCKEditor'] = serialize($fcke_config);
set_fckeditor_instance($areas, $toolbar, $width, $height);
}
Si par contre, tu veux que ce soit désactivé par défaut la première fois, mais qu'ensuite, l'utilisation de FCK Editor soit mémorisé pour chaque textarea:
$toolbar = 'Basic';
$width = '750px';
$height = '300px';
$areas = array();
array_push( $areas,'UAM_MailInfo_Text','UAM_ConfirmMail_Text','UAM_GhostTracker_ReminderText','UAM_ConfirmMail_ReMail_Txt1','UAM_ConfirmMail_ReMail_Txt2');
if (function_exists('set_fckeditor_instance'))
{
$fcke_config = unserialize($conf['FCKEditor']);
foreach($areas as $area)
{
if (!isset($fcke_config[$area]))
{
$fcke_config[$area] = false;
}
}
$conf['FCKEditor'] = serialize($fcke_config);
set_fckeditor_instance($areas, $toolbar, $width, $height);
}
Il faudrait que je rajoute ce paramètre dans la fonction set_fckeditor_instance...
J'ai validé la sérialisation des données du plugin NBC_UAM en bdd et cela pose beaucoup moins de problèmes avec la gestion des points-virgules d'une manière générale. C'est déjà un bon point !
J'ai ensuite implémenté le code pour permettre l'utilisation de FCK Editor pour les champs texte personnalisables dans les emails. Si je n'ai plus de pb avec la gestion des ";", il perdure malgré tout pour les caractères accentués et spéciaux qui sont systématiquement transformés en code. Comme il s'agit de contenu de mails, à leur réception, il ne sont pas interprétés par les clients emails. En tous cas, pas avec mon Thunderbird 3.0.3.
Pour des contenus en anglais, cela pose moins de problèmes puisque seules les apostrophes ne sont pas converties. Mais pour les langues latines ou germaniques, le contenu devient vite illisible. :-(
Y aurait-il une possibilité pour que FCK Editor implémente à l'avenir une fonction d'activation / désactivation de cette transformation des caractères accentués en code ?
Question subsidiaire : Je ne parviens pas à faire en sorte que FCK Editor soit à OFF par défaut sur mes champs de texte. Je préfèrerai que les utilisateurs du plugin NBC_UAM activent la saisie FCK Editor en toute connaissance de cause. J'ai implémenté FCK Editor de la manière suivante :
$toolbar = 'Basic'; $width = '750px'; $height = '300px'; $areas = array(); array_push( $areas,'UAM_MailInfo_Text','UAM_ConfirmMail_Text','UAM_GhostTracker_ReminderText','UAM_ConfirmMail_ReMail_Txt1','UAM_ConfirmMail_ReMail_Txt2'); if (function_exists('set_fckeditor_instance')) set_fckeditor_instance($areas, $toolbar, $width, $height);
Et dans le tpl (exemple pour un champ texte):
{if 'FCK_PATH'|@defined} <div style="text-align:right;"> <a href="#" onClick="toogleEditor('UAM_GhostTracker_ReminderText'); return false;">FCK Editor On/Off</a> </div> {/if}
Eric a écrit:
Grrr... Un jour, faudra que je perde cette sale manie d'aller toujours chercher midi à 14h... C'était pourtant évident ! :-/
Merci, P@t !
Une autre manière de le dire : pourquoi faire simple quand on peut faire compliqué :lol:
Grrr... Un jour, faudra que je perde cette sale manie d'aller toujours chercher midi à 14h... C'était pourtant évident ! :-/
Merci, P@t !
// Ici les valeurs saisies par l'utilisateur et remontées via le submit du formulaire
$newconf_UAM = array(
"'".$_POST['UserAdvManager_Mail_Info']."'",
"'".$_POST['UserAdvManager_No_Casse']."'",
"'".$_POST['UserAdvManager_Confirm_Mail']."'",
(isset($_POST['UserAdvManager_No_Confirm_Group'])?$_POST['UserAdvManager_No_Confirm_Group']:''),
(isset($_POST['UserAdvManager_Validated_Group'])?$_POST['UserAdvManager_Validated_Group']:''),
(isset($_POST['UserAdvManager_Validated_Status'])?$_POST['UserAdvManager_Validated_Status']:''),
"'".$_POST['UserAdvManager_No_Comment_Anonymous']."'",
"'".$_POST['UserAdvManager_Username_Char']."'",
"'".$_POST['UserAdvManager_Username_List']."'",
(isset($_POST['UserAdvManager_No_Confirm_Status'])?$_POST['UserAdvManager_No_Confirm_Status']:''),
"'".$_POST['UserAdvManager_MailInfo_Text']."'",
"'".$_POST['UserAdvManager_ConfirmMail_Text']."'",
"'".$_POST['UserAdvManager_MailExclusion']."'",
"'".$_POST['UserAdvManager_MailExclusion_List']."'",
"'".$_POST['UserAdvManager_Password_Enforced']."'",
$_POST['UserAdvManager_Password_Score'],
"'".$_POST['UserAdvManager_AdminPassword_Enforced']."'",
"'".$_POST['UserAdvManager_GhostUser_Tracker']."'",
$_POST['UserAdvManager_GhostTracker_DayLimit'],
"'".$_POST['UserAdvManager_GhostTracker_ReminderText']."'",
"'".$_POST['UserAdvManager_Add_LastVisit_Column']."'");
$conf['nbc_UserAdvManager'] = addslashes(serialize($newconf_UAM));
// Mise à jour de la base de données
$query = '
UPDATE '.CONFIG_TABLE.'
SET value="'.$conf['nbc_UserAdvManager'].'"
WHERE param="nbc_UserAdvManager"
LIMIT 1
;';
pwg_query($query);
// Et je récupère les paramètres pour utilisation dans la suite
$conf_nbc_UserAdvManager = unserialize($conf['nbc_UserAdvManager']);
J'ai modifier le système de stockage des paramètres du plugin en base de données selon les recommandations de P@t. L'initialisation du plugin fonctionne bien mais je suis confronté au problème de la sauvegarde a posteriori des nouvelles valeurs lorsqu'un utilisateur les modifie et les enregistre depuis l'interface de gestion.
En gros, voila comment je m'y prend :
// Ici les valeurs saisies par l'utilisateur et remontées via le submit du formulaire $newconf_UAM = array( "'".$_POST['UserAdvManager_Mail_Info']."'", "'".$_POST['UserAdvManager_No_Casse']."'", "'".$_POST['UserAdvManager_Confirm_Mail']."'", (isset($_POST['UserAdvManager_No_Confirm_Group'])?$_POST['UserAdvManager_No_Confirm_Group']:''), (isset($_POST['UserAdvManager_Validated_Group'])?$_POST['UserAdvManager_Validated_Group']:''), (isset($_POST['UserAdvManager_Validated_Status'])?$_POST['UserAdvManager_Validated_Status']:''), "'".$_POST['UserAdvManager_No_Comment_Anonymous']."'", "'".$_POST['UserAdvManager_Username_Char']."'", "'".$_POST['UserAdvManager_Username_List']."'", (isset($_POST['UserAdvManager_No_Confirm_Status'])?$_POST['UserAdvManager_No_Confirm_Status']:''), "'".$_POST['UserAdvManager_MailInfo_Text']."'", "'".$_POST['UserAdvManager_ConfirmMail_Text']."'", "'".$_POST['UserAdvManager_MailExclusion']."'", "'".$_POST['UserAdvManager_MailExclusion_List']."'", "'".$_POST['UserAdvManager_Password_Enforced']."'", $_POST['UserAdvManager_Password_Score'], "'".$_POST['UserAdvManager_AdminPassword_Enforced']."'", "'".$_POST['UserAdvManager_GhostUser_Tracker']."'", $_POST['UserAdvManager_GhostTracker_DayLimit'], "'".$_POST['UserAdvManager_GhostTracker_ReminderText']."'", "'".$_POST['UserAdvManager_Add_LastVisit_Column']."'"); $conf['nbc_UserAdvManager'] = $newconf_UAM; // Mise à jour de la base de données $query = ' UPDATE '.CONFIG_TABLE.' SET value="'.addslashes(serialize($newconf_UAM)).'" WHERE param="nbc_UserAdvManager" LIMIT 1 ;'; pwg_query($query); // Et je récupère les paramètres pour utilisation dans la suite $conf_nbc_UserAdvManager = unserialize($conf['nbc_UserAdvManager']);
Mais çà ne fonctionne pas. Dès que je submit (avec ou sans changement des paramètres), j'ai un message :
Warning: unserialize() expects parameter 1 to be string, array given in E:\www\Infernoweb\phpwebgallery\plugins\NBC_UserAdvManager\admin\UserAdvManager_admin.php on line xxx
Où "line xxx" correspond à la ligne "$conf_nbc_UserAdvManager = unserialize($conf['nbc_UserAdvManager']);"
Je comprends que unserialize attend un string en paramètre 1 mais c'est pourtant bien le cas, non?
Ok, merci P@t !
Je note çà pour plus tard. Je dois sortir la nouvelle version 2.13.4 du plugin UAM aujourd'hui car je n'aurais plus beaucoup de dispo ensuite. Je modifierai le modèle de données du plugin pour une version ultérieure avec l'intégration de FCK Editor.