[spip-dev] fn propre() dans ecrire/inc_texte.php3

Hello,

Oui, ce sont de bonnes idées. Mais ça fait partie du "groupware"
et en tant que tels je pense que ça devrait être étudié en
commun. Ce qui ne veut pas dire qu'il faille tout implémenter
en même temps.

J'ai mis un groupware.txt qui sert de boîte à idées pour la chose.
(dans http://rezo.net/spip-dev/devel/)

a+

ARNO* wrote:

Le Dimanche 8 Juillet 2001 07:50, vous avez écrit :

- quand on édite un article, ça passe en champs caché un hash de
l'ancien $texte; et lors de la validation, vérifier avant de modifier
la base qu'on a toujours le même hash dans la base (c'est-à-dire, pas
de modif entre temps).

Si je puis me permettre, en SGBDR ce qu'on fait classiquement c'est qu'on
ajoute une colonne "timestamp", et on verifie qu'il a pas changé.

C'est pareil, sauf que ca le fait plus rapidement et que ca prend moins de
place.

... et plutot que de "vérifier" s'il a changé, on l'ajoute dans la clause
WHERE du update, et après l'exécution du SQL on vérifie qu'une ligne a bien
été affectée par le UPDATE.
Avec Sybase on utilise pour ça la variable @@rowcount , avec MySQL je sais
pas, je connais pas

Salut,

> - quand on édite un article, ça passe en champs caché un hash de
> l'ancien $texte; et lors de la validation, vérifier avant de modifier
> la base qu'on a toujours le même hash dans la base (c'est-à-dire, pas
> de modif entre temps).

Si je puis me permettre, en SGBDR ce qu'on fait classiquement c'est qu'on
ajoute une colonne "timestamp", et on verifie qu'il a pas changé.

Ouip, suis-je bête, en plus elle existe déjà.

Merci :wink:

a+

Antoine.

Bonjour,

je découvre avec joie spip.

Je suggère:

dans les corrections typo:

si {italique} et {{gras}} pourquoi pas {{{gras italique}}} ?
pas de possibilité pour inserrer un retour chariot <br> ? c'est dommage
car il est nécessaire, au même titre que ligne blanche ! pourquoi pas une
convention de type %%% pour inserrer un <br> ?

pas de possibilité de faire un trait horizontal ? pourquoi pas une convention
de type --- pour inserrer un <hr> ?

J'ai vu qu'on avait le droit à texte->url pour faire un lien:
Ex: texte->http://www.rezo.net ou texte->page_sur_mon_site.php

Ne serait il pas interessant que dans le premier cas (http://), on ouvre une
fenêtre supplémentaire pour afficher le lien vers un site extérieur, et que
dans le second cas, lien sur une page interne, on reste dans la même
fenètre ?

Ayant beaucoup travaillé sur phpNuke, j'en aurais encore bien d'autres à
venir ! pour y corporer une saisie du type de la votre, j'ai du utiliser des
morceaux de phpwiki que vous connaissez surement, sur
http://sourceforge.net/projects/phpwiki/

Encore bravo pour SPIP, que je n'ai pas encore eu le courage de regarder
à l'intérieur !

A +

@ Sébastien Bernard (sbernard@mouzaia.com) :

si {italique} et {{gras}} pourquoi pas {{{gras italique}}} ?

{{{texte}}} sert aux intertitres ; {{ {texte} }} te fera du gras italique
(ne pas en abuser!)

pas de possibilité pour inserrer un retour chariot <br> ? c'est dommage
car il est nécessaire, au même titre que ligne blanche ! pourquoi pas une
convention de type %%% pour inserrer un <br> ?

tu peux insérer le code <br /> toi même, pour quoi réinventer des choses
existantes ? les raccourcis installés sont là pour nous simplifier la vie,
mais pas pour avoir un langage HTML alternatif.

pas de possibilité de faire un trait horizontal ? pourquoi pas une convention
de type --- pour inserrer un <hr> ?

même chose : tu tapes <hr />

J'ai vu qu'on avait le droit à texte->url pour faire un lien:
Ex: texte->http://www.rezo.net ou texte->page_sur_mon_site.php
Ne serait il pas interessant que dans le premier cas (http://), on ouvre une
fenêtre supplémentaire pour afficher le lien vers un site extérieur, et que
dans le second cas, lien sur une page interne, on reste dans la même
fenètre ?

Ca peut être bien pour toi et pas bien pour d'autres. Comment choisir ? Si
tu veux modifier cette fonctionnalité, elle se trouve dans
ecrire/inc_texte.php3, il te faudra intégrer une variable globale
    par exemple $faire_sauter_les_liens_http

et ajouter le code suivant :
    if ($faire_sauter_les_liens_http){
        ... le lien que tu veux ...
    } else {
        ... le lien actuel ...
    }

et proposer ton patch à l'équipe des développeurs SPIP <spip-dev@rezo.net>.
Pour l'utiliser les gens devront mettre $faire_sauter_les_liens_http = true;
dans leur fonction d'appel (article.php3).

une autre possibilité, plus simple : si tu veux des liens qui sautent dans
les références de brèves ou de forum, tu n'as qu'à modifier le squelette
d'affichage.

-- Fil

Excuses, j'avais oublié qu'on était en france.

@ Sébastien Bernard (sbernard@mouzaia.com) :
> si {italique} et {{gras}} pourquoi pas {{{gras italique}}} ?

{{{texte}}} sert aux intertitres ; {{ {texte} }} te fera du gras
italique (ne pas en abuser!)

ME fera ? merci pour eux.

> pas de possibilité pour inserrer un retour chariot <br> ? c'est
> dommage car il est nécessaire, au même titre que ligne blanche !
> pourquoi pas une convention de type %%% pour inserrer un <br> ?

tu peux insérer le code <br /> toi même, pour quoi réinventer des
choses existantes ? les raccourcis installés sont là pour nous
simplifier la vie, mais pas pour avoir un langage HTML alternatif.

On peut étendre votre raisonnement:
Pourquoi {italiques}, alors que <em>italiques</em> marche si bien, et
pourquoi {{gras}} alors que <strong>gras</strong> est si performant. Je
peux même aller plus loin, pourquoi SPIP, alors qu'un journal sur papier
existe depuis si longtemps, et même qu'il rapporte de l'argent ?
Quand à l'idée d'un HTML alternatif, je crois que vous et "vos" squelettes,
vous en êtes vraiment un bon exemple. Alors, à quoi servez vous, alors
que nous avons phpNuke !!!

> pas de possibilité de faire un trait horizontal ? pourquoi pas une
> convention de type --- pour inserrer un <hr> ?

même chose : tu tapes <hr />

Même chose, vous pouvez lire le paragraphe ci dessus.

> J'ai vu qu'on avait le droit à texte->url pour faire un lien:
> Ex: texte->http://www.rezo.net ou texte->page_sur_mon_site.php
> Ne serait il pas interessant que dans le premier cas (http://), on
> ouvre une fenêtre supplémentaire pour afficher le lien vers un site
> extérieur, et que dans le second cas, lien sur une page interne, on
> reste dans la même fenètre ?

Ca peut être bien pour toi et pas bien pour d'autres. Comment choisir
? Si tu veux modifier cette fonctionnalité, elle se trouve dans
ecrire/inc_texte.php3, il te faudra intégrer une variable globale
    par exemple $faire_sauter_les_liens_http

et ajouter le code suivant :
    if ($faire_sauter_les_liens_http){
        ... le lien que tu veux ...
    } else {
        ... le lien actuel ...
    }

et proposer ton patch à l'équipe des développeurs SPIP
<spip-dev@rezo.net>. Pour l'utiliser les gens devront mettre
$faire_sauter_les_liens_http = true; dans leur fonction d'appel
(article.php3).

Je ne vous écris pas pour que vous me répondiez avec condescendence
comment modifier vos sources, je n'ai vraiment pas besoin de vous pour
cela, et suis même prèt à vous donner des cours, quoique je n'en ai pas
vraiment le temps. Si je vous écris, c'est pour suggérer quelque chose qui
pourrait peut être servir à quelqu'un. Or vous proposez des choix dans
SPIP, des paramétrages. Pourquoi pas celui ci ? Par contre je
comprendrais parfaitement que vous me répondiez:
"Merci beaucoup, nous détenons la vérité absolue, cela fait des années
que nous développons en entreprise, nous connaissons tout de la
mentalité des utilisateurs, nous n'avons vraiment pas besoin de conseils
ou d'avis de quelque sorte, et allez vous faire ..."

une autre possibilité, plus simple : si tu veux des liens qui sautent
dans les références de brèves ou de forum, tu n'as qu'à modifier le
squelette d'affichage.

Oui c'est probable, il faut que je regarde de plus près.

@ Sébastien Bernard (sbernard@mouzaia.com) :

Je ne vous écris pas pour que vous me répondiez avec condescendence
comment modifier vos sources, je n'ai vraiment pas besoin de vous pour

Il ne s'agit pas de "modifier NOS sources", mais bien de "modifier LES
sources de SPIP" pour que ça puisse profiter à tous. Mais pour cela il faut
accepter de discuter de ce qu'on veut apporter, et peser les
avantages/inconvénients en termes d'usage, de temps de calcul, etc. D'où mon
invitation à modifier le code et à en parler.

Désolé si ma réponse vous est apparue "condescendante". Ce n'était ni mon
but ni mon sentiment.

-- Fil

En réponse à Sébastien Bernard <sbernard@mouzaia.com>:

Je ne vous écris pas pour que vous me répondiez avec condescendence

Je suis attéré de lire des choses pareilles.

Autrement, si je puis me permettre, bien que découvrant SPIP j'ai cru comprendre
que dans ce système, la notion de présentation et de mise en page *N'APPARTIENT
PAS* au rédacteur.

le <HR> , les neens dans une nouvelle fenetre ou pas, ca fait partie des choses qui
appartienne au maquettiste, mais pas au rédacteur.

Si le rédacteur a à sa disposition des saut de paragraphe, des listes avec le '-', etc.
c'est que ça correspont à la structure de l'article, et non pas à sa présentation.

De même, le gras ou italique correspondent en général à une citation ou bien un
titre d'ouvrage, c'est plus une question de fond que de forme.

Mais quelque part, je me demande bien pourquoi j'ai pris la peine a un post rédigé
sur ce ton. T'as qu'a garder ton PHP-Nuke si tu ne vois pas l'interet de l'un par
rapport à l'autre !

Désolé d'avoir été un peu brutal.
Je suis d'accord avec vous, il s'agit de modifier les sources, mais c'est
fatiguant de modifier les sources, et de les remodifier à chaque nouvelle
release.
Et en ce qui concerne ma proposition sur ce http, notre échange est tout
à fait fructueux, vous êtes venu à me faire une proposition, et j'en suis
arrivé à vous en faire une autre ...

Amicalement.

Autrement, si je puis me permettre, bien que découvrant SPIP j'ai cru
comprendre que dans ce système, la notion de présentation et de mise
en page *N'APPARTIENT PAS* au rédacteur.

le <HR> , les neens dans une nouvelle fenetre ou pas, ca fait partie
des choses qui appartienne au maquettiste, mais pas au rédacteur.

Si le rédacteur a à sa disposition des saut de paragraphe, des listes
avec le '-', etc. c'est que ça correspont à la structure de l'article,
et non pas à sa présentation.

De même, le gras ou italique correspondent en général à une citation
ou bien un titre d'ouvrage, c'est plus une question de fond que de
forme.

Je crois que vous n'avez rien compris à cet échange de messages.
Il y a 3 problêmes, d'une part le problême du rédacteur, d'autre part le pb
du maquettiste, et enfin le problême du programmeur.

Le rédacteur doit mettre son article en page. Il a à sa disposition des
aides typographiques, on peut citer les gras, les italiques, les gras en
italiques, les titres, les retours à la ligne, les lignes blanches, les traits de
séparations, et pourquoi pas les liens .... Le tout, et c'est dit dans la
présentation de SPIP:

SPIP est un Système de Publication pour l'Internet. Kesako ? Il s'agit
d'un ensemble de fichiers, installés sur votre compte Web, qui vous
permettent de bénéficier d'un certain nombre d'automatismes : gérer un
site à plusieurs, mettre en page vos articles sans avoir à taper de
HTML, modifier très facilement la structure de votre site... Avec le
même logiciel qui sert à visiter un site (Netscape, Microsoft Explorer,
Mozilla, Opera...), SPIP permet de fabriquer et de tenir un site à jour,
grâce à une interface très simple d'utilisation.

Les auteurs de SPIP ont réalisés une prouesse de programmation en
créant un macro language, qui permets au "rédacteur" de mettre du {gras},
de l'{italique} et je me contentais de demander pourquoi pas du {{ {gras
italique} }}, pourquoi pas un retour à la ligne, et pourquoi pas une ligne de
séparation ...
Le maquettiste n'a pas à décider de mettre du gras ou une séparation qui
peuvent changer le sens d'un article.

D'autre part, je soulevais un autre problême, le suivant:
Quand on est webmestre d'un site, on peut avoir envie que ses visiteurs
restent sur ce site. Or le problême des liens, selon moi, est qu'ils envoient
le visiteur sur un autre site, qui vient souvent occuper la même fenêtre que
son propre site. Ce qui n'est pas génant quand il s'agit d'une page de son
propre site. Or il est vrai qu'on peut facilement faire la différence entre ces
deux types de liens, par la présence d'un http ou pas. Fil a
raison de dire que certains le veulent et pas d'autres, d'ou l'intérèt d'un
paramétrage ...

Mais quelque part, je me demande bien pourquoi j'ai pris la peine a un
post rédigé sur ce ton. T'as qu'a garder ton PHP-Nuke si tu ne vois
pas l'interet de l'un par rapport à l'autre !

La par contre, je ne comprends pas pourquoi vous changez de ton pour
devenir grossier et bète. Je me suis contenté de dire que je connaissais
bien phpnuke, et qu'il y avait beaucoup de choses dedans qui n'allaient
pas ou qui manquaient, et que je serais ravi d'en parler. En particulier je
disais que cette notion de correction typo n'éxistait pas dans phpnuke et
que ma connaissance de phpwiki m'avait permis de les y ajouter au
bénéfice de mes utilisateurs.
De plus, et malheureusement je doute que vous ne le compreniez, mais je
pense que phpnuke et spip sont pour le moment deux produits différents,
à usage différent. Quoique cela puisse changer. De plus, je pense
aujourd'hui, que spip est beaucoup plus brillant que phpnuke.

Salut.

En réponse à Sébastien Bernard <sbernard@mouzaia.com>:

Je crois que vous n'avez rien compris à cet échange de messages.

Probable, faut pas m'en voiloir, je débute avec spip et suis donc bien sûr ignorant.

Il y a 3 problêmes, d'une part le problême du rédacteur, d'autre part le
pb du maquettiste, et enfin le problême du programmeur.

ben oui.

Le rédacteur doit mettre son article en page.

Ben non, il fait pas la mise en page puisqu'il rédige.

Il a à sa disposition des
aides typographiques, on peut citer les gras, les italiques, les gras
en
italiques, les titres, les retours à la ligne, les lignes blanches,

C'est de la typo, pas de la mise en page.

les traits de séparations,

J'ai sous la main une édition d'"Ajourd'hui en France" (qui je le reconnait n'est pas
forcément un modèle d'école dans le domaine de la typo, mais ils sont probablement
bcp plus compétents que moi dans le domaine), et je n'arrive pas à trouver de traits
de séparation au sein d'un article.
Il y a par exemple un trait de séparation sous un titre de brève, ex :

o Transport aérien

Bon je ne voulais pas intervenir au départ, car cela vire au débat de clocher.

Mais je vais apporter un troisième point de vue, qui sera celui d'un autre clocher. Je trouve que SPIP a beaucoup de qualités dans son principe et des défauts. Je trouve également que les auteurs du code ont eu le courage d'ouvrir les sources au public pouvant provoquer justement la hire de nombreuses personnes.

permettent de bénéficier d'un certain nombre d'automatismes : gérer un
site à plusieurs, mettre en page vos articles sans avoir à taper de

Attention, mettre en page est le travail d'un maquettiste pour reprendre les termes de la publication classique.

L'auteur structure son texte et j'insiste bien sur la structure, car si le web est un tel foutoir, c'est que les gens n'en comprennent pas la dimension sémantique et confondent présentation et sémantique d'un texte. Ce qui veut dire que la présentation ne peut pas aider à interprêter la sémantique d'un texte quand c'est un voyant qui le lit. Mais une machine (search engine, analyseur textuelle, lexicographique, etc), ou un non voyant ne tiront rien d'un font color...

Le maquettiste n'a pas à décider de mettre du gras ou une séparation qui
peuvent changer le sens d'un article.

Si c'est le travail du maquettiste de dire comment doit être le gras, par contre c'est à l'auteur de dire si cette portion de texte est importante, que ceci soit exprimé par un <strong></strong>, par un {important}, par un ***blabla*** ou un <span class="top_important"></span>. Ce n'est que du hacking pour donner un langage simplifié à l'auteur.

Ensuite, que ce marquage soit interprêté en lui donnant un style particulier, on tombe dans le travail du graphiste et du maquettiste qui grâce au CSS vont interprêter le <strong> par exemple d'une certaine façon.

Tout comme, un auteur lorsqu'il tape du texte comme dans ce mail et le sépare par deux retours chariots donnant la structure visuelle d'un paragraphe se doit d'être interprêté en entourant le texte de 'p' : <p>Ici le texte</p>. Que le texte soit rouge vert bleu, avec des marges, une lettrine, etc, cela concerne le style.

D'autre part, je soulevais un autre problême, le suivant:
Quand on est webmestre d'un site, on peut avoir envie que ses visiteurs
restent sur ce site. Or le problême des liens, selon moi, est qu'ils envoient

Bon ça c'est un tout autre problème, je me place cette fois-ci en tant qu'utilisateur. JE DETESTE CELA, lorsqu'un site me poppe une fenêtre que je n'ai pas demandé. Si je m'en vais du site, très bien, c'est que je l'ai désiré. Si je veux revenir sur le site précédent je reviendrais. Si je veux ouvrir dans une nouvelle fenêtre, j'ai le menu contextuel. Je ne veux pas qu'on m'impose le fait d'avoir à rester sur un site.

Lire bien sûr:

Ce qui NE veut PAS dire que la présentation ne peut pas aider à interprêter la sémantique d'un texte.

@ Sébastien Bernard (sbernard@mouzaia.com) :

si {italique} et {{gras}} pourquoi pas {{{gras italique}}} ?

{{{texte}}} sert aux intertitres ; {{ {texte} }} te fera du gras italique
(ne pas en abuser!)

Plus généralement, on a essayé de se limiter à des raccourcis qui correspondent aux règles de la typo française.

Du coup: "gras+italique" n'est pas censé faire partie de la typo française (c'est une lourdeur à éviter). Le gras et l'italique ont chacun une signification typographique, mais "gras+italique" n'en a pas (dans les guides de typo, j'entends). D'où l'absence de "gras+italique" en une seule fonction. En revanche, on peut utiliser de l'italique à l'intérieur du gras (ou l'inverse) et là la solution d'Antoine suffit.

> pas de possibilité pour inserrer un retour chariot <br> ? c'est dommage

car il est nécessaire, au même titre que ligne blanche ! pourquoi pas une

> convention de type %%% pour inserrer un <br> ?

tu peux insérer le code <br /> toi même, pour quoi réinventer des choses
existantes ? les raccourcis installés sont là pour nous simplifier la vie,
mais pas pour avoir un langage HTML alternatif.

C'est un peut la même remarque que ci-dessus: le "retour" à la ligne n'est pas tellement utilisé en typographie. On change de paragraphe, ou on n'en change pas. D'où l'absence de raccourcis pour cela. Donc -> si réellement tu en as besoin (et c'est une sorte d'exception à la règle typographique), tu utilises le br du html.

> pas de possibilité de faire un trait horizontal ? pourquoi pas une convention

de type --- pour inserrer un <hr> ?

même chose : tu tapes <hr />

Cela dit, on pourrait envisager de repérer les lignes constituées uniquement de tirets et les remplacer par un hr... (d'autant qu'on en trouve régulièrement dans les forums, et que c'est pas trop joli).

> J'ai vu qu'on avait le droit à texte->url pour faire un lien:
> Ex: texte->http://www.rezo.net ou texte->page_sur_mon_site.php
> Ne serait il pas interessant que dans le premier cas (http://), on ouvre une
> fenêtre supplémentaire pour afficher le lien vers un site extérieur, et que
> dans le second cas, lien sur une page interne, on reste dans la même
> fenètre ?

Y'a effectivement des idées à voir pour le fonctionnement des liens.

- possibilité d'afficher une icone pour signaler les liens externes par rapport aux liens internes (avec ouverture d'une fenêtre pourquoi pas);
- transformer les liens en notes de bas de page pour le format "imprimer"...
- possibilité de récupérer la liste des liens d'un article...

De cette façon, quand on le désire, on utiliserait #TEXTE|icone... ou ce genre de chose pour provoquer un affichage différent.

ARNO*

Salut,

Je pense qu'on pourrait ouvrir quelques forums spécifiques dans uZine au sujet de SPIP:
http://www.uzine.net/ecrire/naviguer.php3?coll=147
Ce qui permettrait de centraliser certains thèmes qui risquent de revenir souvent dans les autres pages.

Pour commencer:
- "Site SPIP cherche collaborateur..." où l'on annoncerait son site (ou projet de site) en indiquant qu'on cherche des collaborateurs (soit des rédacteurs, soit un graphiste...)
- "J'ai besoin d'une nouvelle fonctionnalité", où l'on indique qu'on a besoin de telle ou telle "nouvelle" fonction. Ce qui nous permettrait, si nécessaire, d'enrichir notre "to do list".

Qu'est-ce que vous en pensez?

En particulier: est-ce que ça risque de nous apporter plus de boulot (et en ce moment, on en a déjà plutôt trop :-)), alors que j'espère que ça allègerait notre suivi des forums. En particulier, "nouvelle fonctionnalité", il me semble que ça pourrait alléger les discussions de la liste SPIP, non?

ARNO* wrote:

- "Site SPIP cherche collaborateur..." où l'on annoncerait son site
(ou projet de site) en indiquant qu'on cherche des collaborateurs
(soit des rédacteurs, soit un graphiste...)

bof....

En particulier, "nouvelle
fonctionnalité", il me semble que ça pourrait alléger les discussions
de la liste SPIP, non?

il vaut mieux les avoir sur la liste que dans un forum uzine, non ?

Seconde idée: est-ce que je ne pourrais pas ajouter, dans chaque page
des articles, et avant les forums, un petit texte rappelant qu'avant
de poster, il faut relire les faqs, que pour les problèmes d'install,
c'est telle page, qu'il faut penser à lire les archives de la liste
SPIP, et que pour Multimania, on a fait une page spécifique

oui, et ce qui serait bien ce serait de mettre toute l'arborescence
des rubriques (et articles) SPIP bien lisible, histoire d'avoir
toute la doc en vue.

a+

Salut,

Petite modif dans /inc-calcul.php3 dans la 1.0.3: ajout d'une fonction afficher_notes, et l'affichage des notes passe désormais par cette fonction. Le but: réinitialiser $les_notes. En effet, j'avais un truc qui m'empêchait de faire une format "Imprimer toute cette rubrique": les notes s'accumulaient systématiquement.

De ce façon, je vais pouvoir ajouter l'affichage sur une seule page de toute la doc de SPIP. Ca nous évitera de faire un fichier PDF...

ARNO*

En réponse à ARNO* <arno@scarabee.com>:

> > pas de possibilité de faire un trait horizontal ? pourquoi pas
>une convention
>> de type --- pour inserrer un <hr> ?

Cela dit, on pourrait envisager de repérer les lignes constituées
uniquement de tirets et les remplacer par un hr... (d'autant qu'on en
trouve régulièrement dans les forums, et que c'est pas trop joli).

A ce niveau là, pourquoi ne pas "tout simplement" constituer l'insertion d'une
ligne graphique, à l'instar de ce que vous avez fait pour les tirets ?

Jukap.

Salut tout le monde,

Je charge à l'instant une version 1.0.5 contenant plusieurs nouveautés (dont 2 assez importantes).

- La page "A suivre" (/ecrire/index.php3) met plus en évidence les articles et les brèves à valider (dans un pavé en relief).

- Grosses modifs pour les brèves. Nouvelle présentation, avec nouveaux petits logos (mêmes boutons d'état que les articles, mais en plus petit). Surtout: désormais les brèves proposent également des forums internes (comme pour les articles). Du coup, la page qui affiche la brève (breves_voir) est également modifiée, avec un pavé blanc comme les articles, afin de mieux marquer la différence entre le texte et les forums.

- Une nouvelle page permet de suivre/gérer les forums publics, selon leurs threads, pour chaque article individuel. Accès via la page de chaque article, et via la page générale de suivi des forums. De cette façon, on allie à la fois la précision introduite précédemment (on ne sucre plus un thread d'un coup, mais un message unique), et la possibilité, tout de même, de pouvoir facilement sucrer un thread complet. Dans cette page, on a de plus la possibilité de remettre en ligne un message supprimé.

Au passage, modif dans la procédure de suppression d'un message: les messages "supprimés" ne sont plus décalés dans leur thread (uniquement les messages publiés). Ainsi, si vous voulez supprimer un thread, commencez par les derniers messages du thread, en remontant, de cette façon la structure du thread est conservée (même si les messages sont sucrés).

Sinon, j'ai essayé de programmer plus propre: la fonction "afficher_forum" est la même pour les articles, les brèves et le suivi/contrôle des messages publics. En revanche, j'ai pas encore réussi à l'adapter pour que ce soit toujours la même qui gère la gestion globale des forums. De même, la suppression et la publication des contributions est centralisée dans inc.php3.

Amicalement,
ARNO*