RE: [spip-dev] trolls divers ...

La suite... Dans le message...

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-----

GRELLIER Jean-Luc <jl-grellier <at> cr-limousin.fr> writes:

sauce mais avec les champs présents, il en va de même pour une newsletter :
ce type d'outil c'est de séparer totalement les inscrits à la newsletter des

rédacteurs/admin et

autres contributeurs aux contenus, cela me semble primordial.

réponse ici :

http://www.spip-contrib.net/ecrire/articles.php3?id_article=528

"Descriptif : Adaptation de WAnewsletter pour Spip
permettant l’envoi manuel de pages générées par Spip.
La version 2 de cette contrib inclue la possibilité
d’avoir une newsletter différente par langue et
d’indiquer le nombre de jour couvert par les nouveautés."

Te reste plus qu'à la tester et faire redesecndre les infos.
J'ai pas encore eu le temps de tester cette version,
mais j'utilise la précédente sur l'un de mes sites ...

et c'est une merveille ...

Soÿ

> Newsletter (une vraie....)
  Oula .. chaud ça. Difficile à coder sans tomber dans l'utilisation de
produits externes et pas forcement utilisable partout.
  Il ne faut pas perdre de vue que dire «ça serait bien une newsletter»
est facile à dire, mais préciser un mode de fonctionnement pour
l'envoi, le format et surtout l'abonnement, c'est pas immédiat du tout.
  Et si on se lance là dedans, on verra très vite qu'il y a 20 façons
de faire, et qu'on arrivera jamais à mettre tout le monde d'accord.
  Quoique la notion de mots clé pour abonnement évoqué récemment
pourrait être une solution simple.

Pas d'accord du tout : les articles ont une structure souple, certes
mais figée, dès lors chacun fait sa sauce mais avec les champs
présents, il en va de même pour une newsletter : c'est encore plus
'facile' dans un sens car les fonctionnalités de base d'une newsletter
sont les mêmes. L'avantege que je vois à ce type d'outil c'est de
séparer totalement les inscrits à la newsletter des rédacteurs/admin
et autres contributeurs aux contenus, cela me semble primordial.

  Effectivement, le contenu d'une newsletter unique peut être vu comme
une syndication particulière, et n'être qu'un simple squelette
spécifique, mais :
- comment différencier newsletters si on veut en faire plusieurs ?
- comment gérer l'inscription à une newsletter (implique une table
  des abonnés) ? idem pour plusieurs ?
- jusqu'où personnaliser la newsletter en fonction de l'abonné
- comment effectuer l'envoi (forcement massif et donc lourd
  en ressources) ?
- comment gérer la désinscription, la validation d'inscription (pour
  pas abonner n'importe qui à n'importe quoi) ?

  C'est ça qui est compliqué et qui n'existe pas actuellement dans spip.

Sans rien changer ? Quand tu utilises la date de publication antérieur
pour la date de fin, cela veut dire que tu ne peux pas l'utiliser pour
sa vraie fonction...

  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).

Tout à fait d'accord, sur les modules optionnels, mais une fois
installés, il faut que l'on puisse les désactivés depuyis l'interface
d'admin (c'est aussi plus facile à gérer et plus... Grand public non
?)

si par "désactiver" tu entends "désinstaller", les mods le permettent.
si c'est dans le sens "rendre optionnel", c'est à chaque mod de faire
sa tambouille pour modifier l'admin.

À+, Pif.

> 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*

Ce qui est cool avec Arno*, c'est qu'il a une mémoire de
bibliothécaire :slight_smile:
  On ressort du placard un sujet d'il y a 6 mois, et paf il ressort tous
les arguments qui font que tous ceux qui sont convaincus que le refus
était catégorique et complètement arbitraire n'ont plus qu'à changer
d'avis.

À+, Pif.

PS: bon, et les mots clés sur les auteurs alors ? :wink:

Salut, une newsletter pourrait etre intéressante dans le cadre de spip pour permettre d'envoyer des infos générées par l'intermédiaire d'un squelette spip.

Christian Lefebvre a écrit :

  Effectivement, le contenu d'une newsletter unique peut être vu comme
une syndication particulière, et n'être qu'un simple squelette
spécifique, mais :

- comment différencier newsletters si on veut en faire plusieurs ?

On pourrait utiliser des groupes d'abonnés avec un squelette attaché.

On définirait alors une news par son groupe d'abonnés :

Groupe d'auteurs : Newsletter sport : Euro 2004

Texte du groupe : Vous pouvez vous abonner à l'alerte Euro 2004, et recevoir par email le détail des buts en temps réel !

Il faut alors prévoir d'attacher un squelette à un groupe d'auteur, dans le cas ou le groupe est une liste de diffusion par email.

Une idée :

liste-12.html : le squelette des newsletters adressées au groupe d'auteur 12.

- comment gérer l'inscription à une newsletter (implique une table
  des abonnés) ?

Un auteur s'abonne au groupe qui va bien. (implique un lien auteur/groupe)

idem pour plusieurs ?
Et recommence plusieurs fois si il faut.

- jusqu'où personnaliser la newsletter en fonction de l'abonné

Le moins possible à mon avis

- comment effectuer l'envoi (forcement massif et donc lourd
  en ressources) ?

Avec un spip-cron qui envoi des petits lots tant que la pile n'est pas vide. La pile étant constituée d'un groupe d'auteurs à traiter et d'un cran délimitant les envois déjà effectués et la taille des lots.

- comment gérer la désinscription, la validation d'inscription (pour
  pas abonner n'importe qui à n'importe quoi) ?

Ca mérite d'être étudié en effet, peut etre avec une vérification par email, du style de la procédure des mots de passe perdus

Voir la bloogletter pour des applications de spip et de newsletter
http://bloog.net/article.php3?id_article=83

@+
BoOz

Note : évitez les messages multi thématiques styles "évolutions diverses" c'est mieux pour les archives.

Christian Lefebvre <christian.lefebvre <at> atosorigin.com> writes:

PS: bon, et les mots clés sur les auteurs alors ?

et leur arborexcence hiérarchique ? :wink: (aux mot-clefs) ?

je profite de ce post pour remercier à nouveau très sincèrement
tous ceux qui collaborent à ce magnifique outil qu'est SPIP

Soÿ

J'ai mis à jour avec ces éléments (problemes envois en nombre massif) la page du wiki du lab sur la gestion des mails
http://lab.spip.net/spikini/?wiki=FonctionnalitesExperimentales

@+
BoOz

ARNO* a écrit :

Bonsoir,

Le Tue, 22 Jun 2004 13:14:13 +0200, Christian Lefebvre

> 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.

Certes.

L'élément qui me manquerait, à moi, c'est une "date d'évènement". On a un
article qui parle d'un évènement futur. Cet article a une date de
publication dans SPIP et éventuellement une date de première publication.

Pourquoi ne pourrait-il pas être lié à une date d'évènement futur (ou passé
d'ailleurs) ? Cette date pourrait être de la forme JJ-MM-AAAA, MM-AAAA ou
AAAA comme maintenant, mais aussi JJ-MM et JJ.

Pour annoncer un évènement futur, j'utilise la date de première publication,
mais
1- je me prive d'une vrai date de première publication ;
2- le format de la date de première publication n'est pas adapté aux besoins
sur ces évènements. Ex : parmi les dates 03-sept, 2-août-2006 et
5-oct-2005, quelle est la "prochaine" ?

Bien sur, l'article en lui-même ne disparait jamais, même une fois la date
passée.

Après, on peut penser à un site syndiqué, envoyant avec chaque lien une date
que SPIP saurait mouliner comme une telle date d'évènement. Ou même une
lecture des fichiers ical, vu comme un fichier RSS, avec une date
d'évènement en plus. Du coup c'est cohérent avec les fichiers ical que SPIP
sait créer depuis peu.

Mais bien sûr, je ne code pas. C'est juste une idée en l'air...

ced.

C'est effectivement quelque chose qui pourrait être très utile, mais
le besoin peut vite aller très loin.
  L'idéal serait de pouvoir représenter les événements fixes (une
date, point) et aussi les événements récurrents : tous les 25/10,
chaque lundi, le 5 de chaque mois, le 2ème mardi du mois (plus
dur déjà), le 29 février, à chaque pentecôte (là, c'est chaud !),
à la pleine lune (bon, là, j'exagère :slight_smile:

  Mais comment représenter ça de façon ergonomique coté interface,
de façon explicite coté critères de boucle, et de façon utilisable
coté codage ! c'est carrément pas immédiat.
  Ça ressemble un peu au système de crontab, mais on rencontre
vite des limitations difficiles à surmonter (faut-il faire des "et"
ou des "ou" entre les différents critères, comment spécifier
plusieurs dates, comment faire une interface html sur ça sans
s'y paumer, et comment faire le "select" qui va bien sans exploser
la bdd)

  À cogiter sur le labo ?

À+, Pif.

Christian Lefebvre <christian.lefebvre <at> atosorigin.com> writes:

  L'idéal serait de pouvoir représenter les événements fixes (une
date, point) et aussi les événements récurrents : tous les 25/10,
chaque lundi, le 5 de chaque mois, le 2ème mardi du mois (plus
dur déjà), le 29 février, à chaque pentecôte (là, c'est chaud !),
à la pleine lune (bon, là, j'exagère

  Mais comment représenter ça de façon ergonomique coté interface,
de façon explicite coté critères de boucle, et de façon utilisable
coté codage ! c'est carrément pas immédiat.

À+, Pif.

J'ai sur l'un de mes sites un forum IPB : http://www.invisionboard.com/
ces forums (qui sont à mon avis se qui se fait de mieux sur le web)
gèrent, entre autre, un calendrier hyper génial
avec événements récurrents etc.

Peut-être qu'un petit coup d'oeil à "comment ils l'ont fait"
en entrant dans le noyau (open source) vous donnerait
des idées.

Soÿ a écrit :

J'ai sur l'un de mes sites un forum IPB : http://www.invisionboard.com/
ces forums (qui sont à mon avis se qui se fait de mieux sur le web)
gèrent, entre autre, un calendrier hyper génial
avec événements récurrents etc.

Peut-être qu'un petit coup d'oeil à "comment ils l'ont fait"
en entrant dans le noyau (open source) vous donnerait
des idées.

IPB n'est pas Open Source que je sache (sauf si cela a changé depuis peu) mais la généralisation du système payant me laisse penser le contraire...

Aller, j'entre dans le débat ...

Un besoin clairement exprimé semble etre une gestion du cycle de vie d'un
article, c.a.d., pour Spip qui fait deja 90% du boulot, l'ajout d'un etat
archivé avec la date d'archivage
A partir de la, on peut imaginer automatiser l'archivage (changement d'etat
automatique si date d'archivage dépassée et etat publié par exemple).

Le rapport avec l'agenda :
pour des évenements sur plusieurs jours, on peut utiliser la date
d'archivage comme date de fin, bien qu'une durée en champs extra fasse
l'affaire (on fait rarement des requetes sur la date de fin ou sur la durée)

Si une procedure d'archivage était mise en place, il faudrait evidement que
les boucles excluent les archives, mais permettent d'y acceder (archives
seules et tous).
On peut alors imaginer qu'un agenda affiche ou non les evenements passés en
fonction de ce critère et pourquoi pas supprimer les archives après un
certain temps, voir les transferer sur un autre site d'archive (meme base
mais prefixe different pour les mutualisés ne disposant que d'une base, ca
serait mieux si on pouvait utiliser le meme noyau Spip, mais c'est un autre
débat).

Le "et on fait quoi des archives" (sauvegarde XML, flux rss pour y acceder
et suppression après quarantaine ou à la demande ....) me semble de toutes
facons secondaire car il y a plusieurs approche et un systeme vraiment
fonctionnel doit les gerer toutes (et si possible gerer les exceptions du
genre dans cette rubrique on supprime les archives, dans celle la on les
gardent ...).
Il faudrait donc essayer de lister les possibilités interessantes.

Pour ce qui est des documents liés aux articles, le probleme est beaucoup
plus délicat, certains articles pouvant les utilisés "embarqués" sans qu'il
y ait un relation repérable en base.
Peut etre les documents eux memes devraient avoir leur propre cycle de vie
(ce qui n'est pas évidents et s'eloigne beaucoup du modele actuel, mais les
documents embarqués posent de toute facon un réel probleme)?
en autorisant les articles orphelins (je crois que c'est deja le cas, mais
je ne suis pas sur) ?

Cette approche, si elle est loin d'etre parfaite me parait réalisable
progressivement et sans "tout casser".
Qu'en pensez-vous ?

Aller, j'entre dans le débat ...

Un besoin clairement exprimé semble etre une gestion du cycle de vie d'un
article, c.a.d., pour Spip qui fait deja 90% du boulot, l'ajout d'un etat
archivé avec la date d'archivage

  Et cette idée est rejetée avec force arguments par Arno*.

A partir de la, on peut imaginer automatiser l'archivage (changement d'etat
automatique si date d'archivage dépassée et etat publié par exemple).

  Soit à ce moment là on déplace/supprime/rend innaccessible/rend payant
l'article, et on est en plein dans ce qu'Arno* indiquait, soit on ne
fait qu'empécher son apparition dans les boucles, et dans ce cas, une
règle générale (critère {age}) est généralement bien suffisante.

Le rapport avec l'agenda :
pour des évenements sur plusieurs jours, on peut utiliser la date
d'archivage comme date de fin

  Là, tu vas te faire tuer :wink:
  Tu es en train de proposer une évolution avec comme première
application un détournement de son utilisation normale !

, bien qu'une durée en champs extra fasse
l'affaire (on fait rarement des requetes sur la date de fin ou sur la durée)

  Ben si justement : j'aimerais bien savoir ce qui se passe en ce
moment.
  Par exemple, un cinéma ou un café théatre pourrait afficher son
programme de cette façon, et il faut pouvoir demander ce qui passe ce
soir.
  Ce qu'il faut c'est donc des dates de "pertinence", associées à
l'article. Et ce sont bien des dates de début et fin (donc 2), qui sont
à part de celle de publication (j'annonce aujourd'hui le spectacle de
la semaine prochaine) et d'archivage (après la date de fin, j'affiche
encore l'article parce que je veux que les internautes puissent
donner leur avis dessus dans le forum associé, mais un mois après,
j'arrète de le mettre en avant sur la home (notez que dans ce cas, il
n'y a pas besoin de date d'archivage explicite, mais simplement d'un
{age_fin>30})).

pourquoi pas supprimer les archives après un
certain temps, voir les transferer sur un autre site d'archive

  Parce que dans les 2 cas, google va être plein de 404.

Cette approche, si elle est loin d'etre parfaite me parait réalisable
progressivement et sans "tout casser".
Qu'en pensez-vous ?

  J'en pense que les core-dev insistent pour qu'on réfléchisse le
"à quoi ça sert" avant le "comment le réaliser". Quand j'ai commencé à
m'intéresser à spip, cette façon de tout discuter, même ce qui prend 2
heures à coder m'emm...dait profondemment, mais il est flagrant que
c'est pourtant la meilleure façon de ne pas arriver très vite à un
produit à la vignette, qui pèse 2Go et demande 5 serveurs dédiés pour
tirer 100 pages vues par jour (bon, ok, j'exagère, par minute on va
dire).

À+, Pif.

Christian Lefebvre a écrit :

soit on ne
fait qu'empécher son apparition dans les boucles, et dans ce cas, une
règle générale (critère {age}) est généralement bien suffisante.

Faut-il encore que ton "age" soit le même pour tous les articles... :-/

Ex d'un musée qui fait une conf d'1 mois sur tel sujet et de 15j sur un autre et de 6 mois sur un troisième.

Comment gères-tu cela avec age de telle sorte que chaque élément soit automatiquement caché/archivé/cequevousvoulez lorsque l'événement se termine ??

Même si j'ai lu les arguments d'ARNO* qui se défendent bien sur et sont intéressants, une "date de fin" et/ou un statut archive peuvent être utiles.

D'ailleurs, j'y pense : est-ce qu'un système de notification (automatique ou non) est prévu de telle sorte que tous les X mois, un mail soit envoyé à l'internaute pour une réactualisation de son document ?
Cette situation permettrait par ex d'assurer la pérénité, l'évolutivité des contenus d'un site par ex.

Nicolas

Bonjour,

Un besoin clairement exprimé semble etre une gestion du cycle de vie d'un
article, c.a.d., pour Spip qui fait deja 90% du boulot, l'ajout d'un etat
archivé avec la date d'archivage

  Et cette idée est rejetée avec force arguments par Arno*.

Arno* rejette l'idée (si j'ai bien compris) que des articles validés disparaissent du net pour un devoir de mémoire et de pérennité des oeuvres impérissables de nos rédacteurs.
Pour des articles de fond c'est certain, pour des articles d'annonces d'événement il manque clairement un statut pour permettre au webmestre non pas de supprimer l'article mais de le sortir de la ligne éditoriale.
Sur allergique.org j'ai opté pour un secteur événement avec une rubrique annonce et une rubrique compte rendu; je ne pense pas changer pour l'instant mais il est certain que les annonces des congrès d'il y a deux ans n'intéressent plus grand monde et si je pouvais trier les événements passés des événements à venir facilement par une date limite (celle du congrés) ça m'aiderai dans la présentation.
Pour le reste l'archivage des annonces ne me gêne pas :slight_smile:

Christian Lefebvre a écrit :

> soit on ne
> fait qu'empécher son apparition dans les boucles, et dans ce cas, une
> règle générale (critère {age}) est généralement bien suffisante.

Faut-il encore que ton "age" soit le même pour tous les articles... :-/

Ex d'un musée qui fait une conf d'1 mois sur tel sujet et de 15j sur un
autre et de 6 mois sur un troisième.

ça c'est la date de fin d'événement

Comment gères-tu cela avec age de telle sorte que chaque élément soit
automatiquement caché/archivé/cequevousvoulez lorsque l'événement se
termine ??

ça c'est l'archivage.

ce que je veux dire, c'est qu'il y a 2 débats qui se mélangent :
- gérer des dates d'événements (début + fin)
- gérer un archivage

  Si on s'embarque dans une gestion de l'un en bidouillant l'autre,
ça devient moche et compliqué
  Par contre, si on développe l'idée d'une date de début et d'une date
de fin d'événement, éventuellement avec une notion de récurence (genre
"tous les ans du 1 au 12 juin"), la notion d'archivage devient beaucoup
moins utile puisque qu'un critère de type "après la date de fin" voire
"une semaine après la date de fin" devient possible et semble suffisant.

  Maintenant, oui, ça ajoute 2 dates au lieu d'une, mais ces dates me
paraissent être une façon d'officialiser la notion d'agenda sans
tomber dans le truc impossible à comprendre.

  L'autre question maintenant, c'est plutôt est-ce que ça mérite une
modif du produit, ou une contrib ? car c'est quand même pâs léger
comme truc, et ça allourdirait pas mal, même pour ceux qui n'ont
pas l'intention de s'en servir.

  Je sais, je suis lourd avec mes histoires de mods, mais je
trouve qu'on est en plein dedans :slight_smile:

D'ailleurs, j'y pense : est-ce qu'un système de notification
(automatique ou non) est prévu de telle sorte que tous les X mois, un
mail soit envoyé à l'internaute pour une réactualisation de son document ?

prévu par qui quoi ? je comprend pas trop ce que tu veux dire.

À+, Pif.

Un congrès ça dure jamais plus d'une semaine. Si tu met comme date de
publication celle de début du congrès, il suffit de dégager les articles
passés depuis plus d'une semaine, par un {age>7} (ou un truc du genre,
j'sais plus trop).
  Tu peux en faire autant coté comptes rendus mais avec un délai plus
long.

  Non ?

À+, Pif.

Nicolas Steinmetz <nsteinmetz <at> linagora.com> writes:

IPB n'est pas Open Source que je sache (sauf si cela a changé depuis
peu) mais la généralisation du système payant me laisse penser le
contraire...

Non, tu as raison, autant pour moi, comme précisé ici :
http://forums.ibf-french.com/index.php?showtopic=887&view=findpost&p=4936
par notre cher thewiseoldman :
"Je tiens à préciser que les forums IPB ne sont pas du tout open source,
ni même gratuits, ils coutent juste 0€ (Cherchez pas à comprendre
c'est une idée des responsables du site anglais qui cherchent
à retirer de l'esprit des gens gratuit = open source)"

Pas open source, pas gratuits, coutent juste 0 €.
cf aussi ce sujet :
http://forums.ibf-french.com/index.php?showtopic=11617

Ceci dit, même s'il n'est pas question de copie-coller le code ipb,
(ni de près ni de loin)
ça n'interdit pas d'éditer les fichiers php pour voir comment ils
ont conçu cet agenda, et voir si certains principes intelligents
pourraient faire l'object d'un support de réflexion conduisant
ensuite à la création d'un code propre à spip.

C'était l'idée de ma réponse ci-dessus, et je suis navrée qu'elle ait
été imprécise. Merci de me permettre de la préciser.

:slight_smile:

Soÿ

[...]

  Un congrès ça dure jamais plus d'une semaine. Si tu met comme date de
publication celle de début du congrès, il suffit de dégager les articles
passés depuis plus d'une semaine, par un {age>7} (ou un truc du genre,
j'sais plus trop).
  Tu peux en faire autant coté comptes rendus mais avec un délai plus
long.

  Non ?

Oui si c'est une boucle à part mais le problème c'est que j'ai souvent besoin des articles de plus de sept jours que je gère en excluant la rubrique concernée actuellement mais que j'apprécierai de pouvoir gérer avec un mode {non perime} {perime}
Ceci dit c'est vrai qu'en, bidouillant on affiche bien ce qu'on veut.
C'est pas indispensable chsui d'accord mais ce serait plus facile pour le webmestre...