par defaut on ne supporte que les methodes standard `mail()` et `smtp`.
A charge pour d'autres plugins de proposer des methodes supplementaires via ce pipeline et en fournissant :
* le formulaires/inc-config-facteur-mailer-xxxx.html
* la classe inc/Facteur/FacteurXxxxx.php (declaree dans le pipeline)
L'ancienne classe Facteur est branchee sur FacteurSMTP qui se degrade en FacteurMail si pas de SMTP configure, pour assurer une continuite fonctionnelle des plugins qui utilisaient la classe Facteur directement
on ne fait pas d'upgrade de base, on gere la lecture de la nouvelle config et le fallback vers l'ancienne sinon via la fonction facteur_config_mailer()
- changer l'adresse d'envoi si domaine différent de celle du webmestre
- et, si on change l'adresse d'envoi, changer aussi le nom de
l'expediteur
Le premier point permet de fonctionner avec des serveurs SMTP stricts,
qui vérifient le domaine.
Toutefois, on peut vouloir garder le nom expediteur, même si on change
l'adresse expeditrice (ce que fait, par ex, Formidable lorsqu'on ne
force pas le champ From).
Une nouvelle option permet cela.
+ un reglage supplementaire permet de forcer le From quand il n'est pas dans le meme domaine que le From de Facteur
dans ce cas le From passe en ReplyTo et le From configure est force. Permet aux mails des formulaire de contact de fonctionner meme avec un service smtp externe qui demande de valider les domaines sortant
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
- 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