[spip-dev] Envoyer cet article par mail pour la 1.4

Salut,

Je crois que la fonction "Envoyer cette page à un ami" intéresse pas mal de monde.

- Ajouter un tag #FORMULAIRE_ENVOI_MAIL qui s'en charge automatiquement.

- Ah oui: cette fonction enverrai l'article lui-même, et non un bête message du genre "Machin vous signale que cet article: http://www.monsite.com/article23.html pourrait vous intéresser", qui n'a rigoureusement aucun intérêt (parce que ça, on peut le faire bêtement avec un mailto: bien paramétré en HTML).

- Possibilité d'envoyer _une autre page_ que la page affichée actuellement. Notamment, une page simplifiée (sans l'interface de navigation par exemple, ou en mode texte pur, vu que personnellement je déteste qu'on m'envoit des mails en HTML...). Pour cela, comme pour #FORMULAIRE_RECHERCHE, possibilité d'indiquer une autre adresse: [(#FORMULAIRE_ENVOI_MAIL|article-texte.php3?id_article=#ID_ARTICLE)]

- Stocker l'IP de ceux qui envoient des mails, et fixer une limite (laquelle, comment?) pour éviter que ça ne serve à spammer (je détesterais qu'un robot m'envoit par l'intermédiaire de SPIP des tripotées de versions d'un texte de 50000 caractères....).

- Grosse difficulté: il faut remplacer les liens relatifs par des liens absolus, idem pour les images. Et cela sans recourir à un filtre placé dans la page, puisque ça peut être la page "actuelle" qu'on envoit... Chiant comme la mort à gérer, non?

ARNO*

Salut,

navigation par exemple, ou en mode texte pur, vu que personnellement
je déteste qu'on m'envoit des mails en HTML...).

Moi non plus, donc n'offrons pas cette fonctionnalité.

détesterais qu'un robot m'envoit par l'intermédiaire de SPIP des
tripotées de versions d'un texte de 50000 caractères....).

Dans ce cas, autant abandonner la fonctionnalité et envoyer
l'URL suivie du début de l'article en mode texte (comme pour
l'annonce des nouveautés).

- Grosse difficulté: il faut remplacer les liens relatifs par des

Non, on ne va pas se faire chier à ça ;))

a+

Antoine.

Hervé Lefebvre (aegir@free.fr) avait déjà fait une fonction de ce type qui
fonctionne sur LinuxFrench (http://www.linuxfrench.net) avec un fichier
mail_article.php3. Vous pourriez le prendre comme base. Il fonctionne bien, à
part peut-etre le formattage des balises à améliorer.

Non, très facile à gérer il suffit de mettre dans le HEAD :
<BASE HREF="http://www.linuxfrench.net">

A vrai dire j'attendais la sortie de spip 1.3 pour me remettre à travailler
dessus. Car si j'ai bien compris, la fonction envoyer_mail() a évolué (j'ai
pas regardé encore).

En fait je pensais faire une fonction envoyant soit en HTML, soit en TXT. Le
formulaire ne proposant le choix que si on est sur un hébergeur "compatible
HTML" (il peut y avoir des pb dans les entetes de mail)

Bonsoir,

Je suis petit utilisateur de spip et y'a des petits détails qui
m'intrigue...

Je lis dans l'aide (à l'occasion de la 1.3 j'y retourne...) que :
"lorsqu'une contribution à un forum est postée, la page correspondante
est effacée du cache, et recalculée immédiatement, quel que soit le
délai fixé pour cette page."
Est-il possible de faire la même chose pour les accès au rubrique,
article, etc
c'est à dire pourquoi vous vous embêter a comparer les $delais pour
savoir, s'il faut le recalculer ou pas ?
Le "schéma" des forums n'est pas envisageable pour le reste de la
gestion de spip ?!
N'est-il pas possible que lorsque l'on clique sur proposé à la
publication il compose la page en html et que cette article ne soit plus
appelé par du php ?

Sinon autre petites question : j'aimerais savoir comment sur uzine vous
faites pour que vos adresses n'utilise pas de php3 ou d'autre chose..
(exemple http://www.uzine.net/article1054.html)

Bon voilà c'était quelques questions restés sans réponse... excusez moi
s'il existe une réponse qq. part sur votre site j'ai pas trouvé :frowning:
merci de votre lecture et de vos futures réponse :slight_smile:

Salut,

Je lis dans l'aide (à l'occasion de la 1.3 j'y retourne...) que :
"lorsqu'une contribution à un forum est postée, la page correspondante
est effacée du cache, et recalculée immédiatement, quel que soit le
délai fixé pour cette page."
Est-il possible de faire la même chose pour les accès au rubrique,
article, etc
c'est à dire pourquoi vous vous embêter a comparer les $delais pour
savoir, s'il faut le recalculer ou pas ?
Le "schéma" des forums n'est pas envisageable pour le reste de la
gestion de spip ?!

Non car le schéma des forums est beaucoup plus simple en général
que le reste des dépendances qu'on peut observer sur un site donné.
Il faudrait contraindre les types de critères et de séquences
utilisables dans les boucles pour avoir une gestion des dépendances
efficace. Ce n'est pas envisageable avec la sémantique actuelle des
squelettes.

Sinon autre petites question : j'aimerais savoir comment sur uzine vous
faites pour que vos adresses n'utilise pas de php3 ou d'autre chose..
(exemple [uZine 3] FAQ webmestre)

Il y a un article quelque part dans la doc qui "explique" (certes de
façon un peu confuse ;-)) comment utiliser des URLs personnalisées.

a+

Antoine.

Bonsoir,

Je suis petit utilisateur de spip et y'a des petits détails qui
m'intrigue...

Je lis dans l'aide (à l'occasion de la 1.3 j'y retourne...) que :
"lorsqu'une contribution à un forum est postée, la page correspondante
est effacée du cache, et recalculée immédiatement, quel que soit le
délai fixé pour cette page."
Est-il possible de faire la même chose pour les accès au rubrique,
article, etc
c'est à dire pourquoi vous vous embêter a comparer les $delais pour
savoir, s'il faut le recalculer ou pas ?
Le "schéma" des forums n'est pas envisageable pour le reste de la
gestion de spip ?!
N'est-il pas possible que lorsque l'on clique sur proposé à la
publication il compose la page en html et que cette article ne soit plus
appelé par du php ?

C'est une excellente question, si je la comprend bien. Dit autrement: pourquoi ne pas recalculer une page (une rubrique, un article) que si des éléments contenus sur cette page sont modifiés? C'est pas idiot, ça permettrait même de rendre le site totalement statique en l'absence de toute modification (alors que pour le moment, c'est recalculé en fonction d'un "délai" arbitraire).

Hum... pour faire très simple: parce que ce serait très compliqué! De part la souplesse (relative, certes) du langage des boucles et des critères utilisés, il est très difficile de prévoir à l'avance qu'une modification quelque part va modifier l'affichage sur telle ou telle page. Par exemple, une page affiche les articles de la rubrique 2 (et de toutes ses sous-rubriques), à l'exclusion de la rubrique 25 (une des sous-rubriques de la rubrique 2), et uniquement les articles associés à un mot-clé du groupe de mots "Relations internationales"... maintenant j'ajoute un article dans une sous-rubrique de la rubrique 2; pour savoir (comme pour les forums) que je dois recalculer le cache des autres pages, je dois déterminer si cet article est dans une sous-rubrique de la 2, s'il n'est pas dans la rubrique 25, et s'il est lié à un mot-clé du groupe "Relations internationales". Mine de rien, un enfer à gérer de manière informatique...

Si on considère en plus que de nouveaux critères apparaissent avec chaque version de SPIP, il faudrait intégrer ces nouveaux critères dans le problème précédent. On obtiendrait donc rapidement une usine à gaz.

Donc: oui, d'une manière stricte, on pourrait imaginer ne pas utiliser de "delai" arbitraire pour recalculer les pages, et ne recalculer qu'en fonction des modifications réelles sur les pages. Mais dans la pratique, c'est un boulot assez énorme pour le programmer et le tenir à jour.

(Antoine, tu n'hésites pas à me contredire si je dis des bêtises :-))

Sinon autre petites question : j'aimerais savoir comment sur uzine vous
faites pour que vos adresses n'utilise pas de php3 ou d'autre chose..
(exemple [uZine 3] FAQ webmestre)

Cela fait l'objet d'un article dans la documentation:
http://www.uzine.net/article765.html
Attention: ça n'est pas évident si l'on n'a aucune connaissance du fonctionne du serveur Apache, et ça n'est pas possible chez tous les hébergeurs (en particulier: ça l'est très rarement chez les hébergeurs gratuits).

ARNO*