On n'y injecte donc plus le mot de passe actuel, qui est affiche partiellement en dessous pour verifier si il est bon
(si le mot de passe est court, on affiche que des * a la place des caracteres, si il est long on affiche une portion de 10% au debut et a la fin)
Si le champ est vide, la configuration actuelle est conservee, si un nouveau mot de passe est saisi il est mis en configuration et conserve dans le formulaire
Ce format de saisie pourrait etre un pattern a generaliser pour les saisies d'API key ou mot de passe un peu sensible
- on ajoute l'auto-detection des mails HTML dans envoyer_mail : si aucun Content-Type n'est fourni, et que le mail commence par un < finit par un > et contient bien un </html> on considère que c'est un mail HTML. Cette feature etait fournie pour les notifications uniquement (par inc/notifications) jusqu'ici
- on recupere la fonction de conversion HTML->Texte du plugin Newsletter, qui s'appuie sur MarkDownify
- si aucune alternative texte n'est fournie à un mail HTML, on génère automatiquement une alternative texte dans envoyer_mail()
A tester et stabiliser.
Fournir un filtre facteur_email_wrap_to_html applicable dans un squelette de mail par #FILTRE{facteur_email_wrap_to_html}
Si le mail est au format texte : la premiere ligne est le sujet, le reste le corps du mail
Le mail peut etre aussi dans un format HTML *simplifié*, detecte par le fait que le mail commence par < et finit par > et contient un </body> : dans ce cas le mail fournit un <title></title> qui fera le sujet et un <body></body> qui fera le corps HTML du texte, encapsulé dans le wrapper emails/texte.html
A titre experimental on prend aussi en charge une <intro></intro> qui sera injectee en texte de debut mais non affichee, pour servir d'introduction dans les clients mails qui affichent le debut du texte du message sous son titre dans la vue de la BAL
- il casse les mails faits mains sur mesure (comme le wrapper html des emails texte du plugin) car incapable de gerer les @media
- il peut etre utile sur certains mails html simples
- il est a utiliser au cas par cas, et c'est le webmestre qui code son mail html qui peut le savoir, pas l'admin qui configure le site et utilise simplement
En consequence, le reglage disparait de la configuration et n'est plus pris en compte
Par compatibilite la methode ConvertirStylesEnligne de la classe Facteur reste disponible, mais tout son code est deporte dans le filtre facteur_convertir_styles_inline
que l'on appellera au cas par cas dans les squelettes HTML par un appel #FILTRE{facteur_convertir_styles_inline}
Ainsi on preserve son usage quand necessaire, sans plus risque de casser les emails HTML bien fichus
On incremente la version en 2.2.0 pour marquer la difference fonctionnelle
lien vers la bonne icone
modernisation du script d'upgrade
grostitre sur la page de configuration
ne pas inclure classes/facteur sur chaque calcul, les scripts qui ont besoin de mailer le font par cette inclusion
ou par inc/envoyer_mail
jluc@no-log.org