Mieux sur spip-dev.
-------- Message original --------
Pour rappel :
http://www.spip-contrib.net/Facteur
"Un plugin pour regrouper toutes les fonctions *avancées* autour de l’envoi de courriels."
Je note du coup qu'il y a désormais deux manières différentes d'ajouter des pièces jointes. Même en intégrant cette modification de la signature uniquement à partir de SPIP 3, ça posera quand même un problème de confusion, dès que ce sera documenté publiquement.
2011/7/6 RastaPopoulos <rastapopoulos@spip.org>
Oui, lorsque la question d'alourdir envoyer_mail s'était posée, on avait choisit de ne rien en faire et de gérer tout ce qui est 'non trivial' (pièces jointes, mails html..) dans un plugin dédie, sur la zone (cf la discussion du 16 au 25 mars 2009 sur spip-zone)
De fait il existait déjà une signature étendue de la fonction envoyer_mail, qui n'est pas celle introduite ici.
Cédric
Ah je me rappelais bien qu'on en avait déjà discuté, mais pas aussi précisément que ça, c'est pratique les archives.
Du coup, j'ai pour l'instant l'impression qu'il faut revert l'ajout d'Emmanuel (d'autant plus en version stable).
Et considérer que c'est le cachet du Facteur qui fait foi.
Ça par contre non. Si on a mis les fonctions avancées dans un plugin c'est justement pour ne pas intégrer les complications au noyau.
De plus Facteur = une librairie externe qui est PHPMailer. Elle a beau être très connue, très documentée, et à priori très stable, ce n'est pas une raison pour l'intégrer au noyau, qui est censé maigrir au contraire.
Effectivement, donc le core doit rester léger.
-Nicolas
le core doit rester léger.
Ce troll oublie un point fondamental de cet envoi qui disait d'abord:
C'est une version qui est beaucoup plus robuste que la précédente pour passer à travers le mode le plus parano de SpamAssassin
parce que SPIP ne respectait pas
http://www.ietf.org/rfc/rfc1036.txt
qui date de 1987, irrespect qu'on peut légitement considérer comme un bug puisque sans cette modif SPIP ne sait pas envoyer des messages corrects vers des boîtes aux lettres où les anti-spam font autre chose que de la figuration.
La mise en conformité nécessite la production d'un identifiant unique de message, que je prends ensuite comme Boundary d'éventuelles pièces jointes. Du coup cet envoi qui a très gravement alourdi SPIP de 910 octets, se compose de 410 octets de correction de bug, et 500 octets d'ajout d'une fonctionnalité (dont 145 pour les commentaires).
La sodomie des brachycères est décidément une activité toujours très prisée.
Committo,Ergo:Sum
Absolument pas, une fonctionnalité ne se compte pas en nombre d'octet que je sache.
Modifier la signature d'une fonction et ajouter une deuxième méthode différente pour quelque chose qui existait déjà (fut-ce dans un plugin !), ce n'est pas un envoi anodin.
En revanche la correction pour SpamAssasin c'est différent. Cela aurait d'ailleurs dû être l'objet de deux commits séparés d'après moi.
Il est toujours bizarre d'avoir dans le même commit à la fois une correction de bug ET un ajout de fonctionnalité important. Ya pas mieux pour s'embrouiller, la preuve.
Grand spécialiste de la discipline, je propose donc
http://core.spip.org/projects/spip/repository/revisions/18198
qui garde la partie importante (support correct de la RFC), et évacue la partie incompatible ($parts),
en proposant une alternative pour l’envoi de pièces jointes, basée sur la signature utilisée dans le plugin Facteur,
et la fourniture d’une fonction externe mail_embarquer_pieces_jointes chargée de générer $parts
Cédric,
avec son bras qui sert
(mais l’autre non)
Reporté par http://core.spip.org/projects/spip/repository/revisions/18235 donc.