Voilà une explication que je qualifie de très claire et qui devrait figurer sur une faq spip.
Je reste donc avec ma Wanewsletter adaptée qui est un très bon compromis.
Par contre sur l'aspect d'une date de fin (pas de retrait) je ne partage pas du tout ton avis (à moi d'argumenter).
Pas question pour moi de suprimer ces articles (on néglige trop l'aspect archivage des données). En ce qui me concerne, cette date me permettrait non seulement de gérer correctement et clairement un agenda (date de fin d'un événement) mais aussi d'archiver mes articles une fois cette date de fin arrivée.
Je suis ok ensuite sur le respect de la netiquette (c'est le cas lors d'un archivage). Par contre vous de devriez pas (je me permets un conseil... Désolé) préjuger de ce que peuvent faire ou pas les utilisateurs ou bien à ce moment là il faut le généraliser, auquel cas on en revient à l'incessant discours des respects de normes à la c.. Nom d'un machibouzouk !
Enfin merci pour ces réponses et de faire de votre mieux.
A+
Jean-Luc GRELLIER
Chargé de Mission TIC
Courriel : jl-grellier@cr-limousin.fr
Tél : 05 55 45 18 96
Fax : 05 55 45 17 48
Région Limousin
27 Bd de la Corderie
87031 Limoges cedex
-----Message d'origine-----
> Newsletter (une vraie....)
Le problème ici, c'est qu'en général, on nous demande une newsletter, et on pense en même temps à une gestion de mailing-list...
-> La gestion de newsletter, c'est la question de créer le message
lui-même, de manière automatique. Et là, avec des squelettes spécifiques, ça n'est déjà pas méchant à réaliser. Au pire, on fait un squelette dont on ne publie pas l'adresse, on fait un copier-coller quand on veut envoyer la newsletter, et on l'envoie. Comme on n'envoie pas une newsletter toutes les deux heures, c'est pas la mer à boire.
-> La grosse difficulté, c'est l'envoi en masse sur une mailing-list, ou
bien sur des mailing-lists spécifiques. C'est là que se trouve la difficulté...
- Il est très difficile de demander à SPIP de gérer l'envoi en nombre de mails, via PHP. Un système de mailing-list doit gérer des automatismes
liés: aux abonnements, aux désabonnements, aux adresses qui disparaissent, aux mailer-daemon qui renvoient les mails, etc. C'est déjà pas rigolo avec une liste de 10 messages, ça devient extrêmement pénible à partir de plusieurs dizaines (centaines, milliers, dizaines de milliers pour certains sites) de destinataires. Il faut de plus parvenir à envoyer ces mails. Or, l'envoi du mail est un procédé relativement lourd, et _lent_.
Au bout de 5 mails, s'attendre à ce que le script s'arrête bicoz limitation (nécessaire) du serveur quant aux scripts PHP. Il faudrait alors un cron (déclenchement automatique de fonctions). SPIP en simule un, mais c'est déclenché en réalité par les visites du site. Et s'il faut envoyer 1000 messages, ça devient carrément très risqué (notamment si la fréquence des visites ne suffit pas à déclencher toutes les actions nécessaires).
C'est là l'énorme difficulté.
- La solution "propre", c'est de faire effectuer la gestion de mailing-list par un système spécialisé. C'est même le principe de fonctionnement d'un serveur: on confie à des logiciels spécialisés les tâches spécialisées.
Dans ce cas, il faut prévoir l'interfaçage entre SPIP et un système inconnu (on ne sait pas, et on peut difficilement savoi quel logiciel de liste est installé sur le serveur, comment on le commande). Faire ça proprement est difficile. L'interface de configuration risque d'être coton.
L'autre difficulté, c'est que les messages demande à ce que les inscriptions soient gérées par SPIP. Or, la gestion d'un grand nombre de mails nécessite non seulement une interface adaptée, mais aussi la réception de mails (demandes de désabonnement par mail, c'est la norme des mailing-lists), les mises en "absence" (suspendre son abonnement pendant qu'on part en vacances), et surtout la gestion des retours d'erreurs (adresses email mal renseignées, adresses qui disparaissent, mailer daemon insultant, etc.).
De plus, on demande cela avec des abonnements précis, par mots-clés par exemple. Extrêmement lourd, potentiellement des dizaines de combinaisons possibles (ça augmente rapidement: le nombre de newsletters différentes à créer est le factoriel du nombre de mots-clés sélectionnables)... Or, autant interfacer un seul message avec une liste de mails est déjà lourd (il faut savoir comment commander le système de liste), surtout ça devient coton s'il y a 128 messages différents... (ça n'est plus de la mailing-list, où l'on envoit un message à une unique liste d'abonnés; c'est l'envoi de messages différents en indiquant à chaque fois la liste des destinataires spécifiques).
C'est bien ce que j'ai dit : il manque la notion de date de fin, qui
peut également servir à automatiser une mise hors ligne, ou un
archivage plus finement qu'avec le critère {age}. Mais ça aussi ça
heurte les convictions d'Arno* (pour j'sais plus quelle raison
d'ailleurs).
L'absence de date de retrait, ça n'est pas une conviction d'ARNO*, c'est le fonctionnement même de l'internet: on évite autant que possible de provoquer des erreurs 404 en déplaçant ou supprimant des articles à tout bout de champ. Cette nouvelle mode de vouloir retirer des articles, cela détruit la nature réticulaire du réseau: il devient impossible de faire des liens vers des articles, parce que les webmestres passent leur temps à les supprimer arbitrairement.
C'est vraiment une mode (ce besoin vital de supprimer des publications), et c'est une mode à la con. Ca ne sert le plus souvent pas à grand chose (il suffit d'être clair dans l'énoncé de son information pour que le lecteur sache bien que le débarquement du 6 juin 1944, c'est un événement passé, et non l'annonce d'une manifestation festive la semaine prochaine, même si l'information est toujours accessible en ligne), alors que cela accentue la fermeture des sites Web (on ne peut pas référencer depuis l'extérieur les sites qui se livrent à ce genre de manipulations, parce que ça revient à truffer son site de liens morts à moyenne échéance - et ça, c'est vraiment insupportable: essayez de parler de l'actualité en linkant des articles du Monde ou de Libé, vous allez adorer).
-> SPIP n'est pas conçu comme un système technique transparent: les
fonctionnalités sont toujours conçues dans l'optique de promouvoir, notamment auprès des webmestres débutants, des comportements aussi respectueux que possible de la nétiquette (norme de comportement permettant de respecter les utilisateurs et/ou les autres webmestres et de fluidifier l'utilisation du réseau).
Donc, oui, il y a parfois des fonctionnalités, faciles à implémenter (quoique proposer pour les articles une date de mise en ligne, une date de première publication, une date de modification et une date de "fin", ça va faire une interface rigolote...), qu'on n'installe pas parce que, pour la majorité des webmestres, ça provoquera des comportements irrespectueux des normes de respect sur l'internet (même chose pour la modification du texte des messages de forums, le suivi de sessions de visites, etc.). Et installer une fonction en indiquant "surtout ne l'utilisez pas, sauf cas exceptionnel", c'est pas franchement une solution.
Amicalement,
ARNO*