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

jusqu'à maintenant on était très peu nombreux... le code est assez crade,
mais on apprend en marchant. Autrement dit : tu n'es pas tombé sur des
hackers mais sur des gensses qui veulent un truc conforme à leurs besoins

En général, le code des hackers est loin d'être propre parce-qu'ils comprennent ce qu'ils font et repoussent aux calendes grecques le manuel... :slight_smile:

le fichier inc_texte.php3 contient essentiellement la fonction propre() qui
prend ce qui est dans la base de données et le transforme, via les
raccourcis SPIP, en html (certes non conformant à la quality assurance).
C'est cette fonction propore() qui devrait être "conformée".

OK regardons de plus près cette fonction.
Voilà pourquoi il est intéressant d'avoir un manuel de chaque variable, de chaque fonction, etc, un guide du développeur. En fait, ce que vous devriez faire à chaque fois que vous créez une fonction, c'est
  - d'ajouter le code de cette fonction a un manuel (une page par fonction),
  - de spécifier les fichiers dans lesquels est appeler la fonction si elle est appelé à plusieurs endroits
  - de spécifier les variables
  - d'expliquer à quoi elle sert.

Si le travail semble monstrueux, la politique des petits pas est envisageable, ainsi le premier qui retouche à une fonction l'ajoute au GUIDE DU DEVELOPPEUR (géré grâce au système SPIP :wink: ). D'autre part, cela a l'avantage de pouvoir permettre de garder une trace du code des modifications intervenues sur la fonction de ne pas avoir à rediscuter 36 fois de quelques choses qui a été fait il y a 6 mois, etc....

PREMIERE QUESTION pour la
  function propre($letexte)

- Quel est le contenu exact de $letexte ? (format, origine, un example? )

- Cette question est en partie motivée pour comprendre la raison de
  $regexp_echap = "<[Aa] [^>]+>|<HTML>([^<]|<[^/]|</[^H]|</H[^T])*</HTML>";
  while (ereg($regexp_echap, $letexte, $regs)){
    $compt_sources++;
    $zesources[$compt_sources] = $regs[0];
    $zetexte = split($regexp_echap,$letexte,2);
    $letexte = $zetexte[0]."<SOURCE$compt_sources>".$zetexte[1];
  }

Hello,

Warning : on rentre dans les querelles de chapelles entre
informaticiens, vu que chacun a sa vue sur le sujet.... :wink:

OK regardons de plus près cette fonction.
Voilà pourquoi il est intéressant d'avoir un manuel de chaque
variable, de chaque fonction, etc, un guide du développeur. En fait,
ce que vous devriez faire à chaque fois que vous créez une fonction,
c'est
        - d'ajouter le code de cette fonction a un manuel (une page
par fonction),
        - de spécifier les fichiers dans lesquels est appeler la
fonction si elle est appelé à plusieurs endroits
        - de spécifier les variables
        - d'expliquer à quoi elle sert.

Là, c'est la frange extrêmiste inverse de l'existant de SPIP :))
Le code est plutôt crade et c'est un problème, par contre la doc
au quotidien, c'est monstrueusement pénible et fastidieux. Je
préfère largement un code clean et (plus ou moins légèrement)
commenté, qui est une habitude indispensable de programmation.
Disons pour éclaircir que le temps disponible doit plutôt
être passé sur l'éclaircissement du code que celui de la doc
à destination des développeurs. Pour un projet comme SPIP,
un code suffisamment propre devrait permettre aux développeurs
suffisamment impliqués de maîtriser l'ensemble du projet
(architecture + majorité des détails) sans avoir besoin
d'une doc lourde. Pour l'instant, on est deux à avoir cette
maîtrise : Arno et moi (et peut-être Fil).

Par contre, quelques docs générales, comme sur l'organisation
de la base de données (en cours (?)), c'est effectivement utile.

Mettre également tout le code sous CVS permettrait de favoriser un
développement partagé en insérant des commentaires pour les modifs.

Je commence à penser aussi que c'est une bonne idée, vu que le
nombre de modification s'accélère (surtout avec les corrections
de bugs). En plus, ça résoudra peut-être les problèmes d'accents
dus aux clients FTP foireux sur Macintosh :slight_smile:

Le problème, c'est que comme Fil je n'y connais à peu près rien.
Je saurai me débrouiller avec un client (http://www.cvsgui.org/
pour des clients graphiques pour Mac et Windows, merci Michael),
mais côté serveur, nada.

a+

Antoine.

Coucou,

les balises <HTML> (pour court-circuiter le propre()) ne sont
reconnues qu'en majuscules et je me dis que c'est un peu bête.
Est-ce que quelqu'un voit un inconvénient à faire une comparaison
case-insensitive ?

a+

bien au contraire.... :slight_smile:

J'y vois un autre problème : c'est la même balise que le <HTML> du langage
html, ce qui pourrait dérouter certains brouteurs (sait-on jamais)

On devrait sans doute les remplacer d'office par des tags <XXXXX> </XXXXX>
(ou autres, cf. Karl!), et traiter ces tags-là comme signifiant "pas
touche". Si on choisit bien nos tags, l'expression régulière qui les
récupère sera plus belle que l'actuelle ([^Hh]|[Hh][^Tt]|....)

@ Antoine Pitrou (pitrou@free.fr) :

les balises <HTML> (pour court-circuiter le propre()) ne sont
reconnues qu'en majuscules et je me dis que c'est un peu bête.
Est-ce que quelqu'un voit un inconvénient à faire une comparaison
case-insensitive ?

-- Fil

d'autant plus que je n'ai toujours pas compris à quoi elle servait...

Voir mon autre mail [1] où je demande l'explication du contenu de la variable $texte de function propre()
Je ne peux pas vous aider si je ne sais pas de quoi il en retourne.

[1] http://listes.rezo.net/pipermail/spip-dev/2001-July/001619.html

Si vous créez des balises réservées pour votre document, des balises du type xml, je veux bien écrire la DTD qui va avec. Cela semble idiot et très fondamentaliste de faire cela, mais en fait c'est penser au futur quand votre système SPIP sera LE système de gestion de contenu incontournable et que d'autres personnes voudront développer des interfaces autour :wink:

Tout comme l'exportation de votre base au format XML.

Fil wrote:

J'y vois un autre problème : c'est la même balise que le <HTML> du langage
html, ce qui pourrait dérouter certains brouteurs (sait-on jamais)

Ben non, vu qu'elle n'apparaît pas dans le HTML résultant.

a+

@ Antoine Pitrou (pitrou@free.fr) :

> J'y vois un autre problème : c'est la même balise que le <HTML> du langage
> html, ce qui pourrait dérouter certains brouteurs (sait-on jamais)

Ben non, vu qu'elle n'apparaît pas dans le HTML résultant.

%% De l'intérêt de tester avant d'affirmer : elle apparaît. (On ne la supprime
pas de manière à ce que le code soit idempotent, ie
    propre(propre($texte)) == propre($texte)
)

%% Karl : dans la fonction propre() ainsi que dans typo(), si on repère dans
le texte à modifier une séquence du type
                    <HTML>quelque chose</HTML>
on préserve "quelque chose", c'est-à-dire qu'on ne lui applique aucune
transformation/correction typo etc. Même chose si on repère <A Href=blabla>,
on ne touche pas, histoire de ne pas casser des liens du type

    ^espaces ^ ^
     insécables

C'est à ça que sert l'expression régulière qui te fait question.

(PS: ton mail n'est pas conformant iso88machin ? les accents passent mal)

-- Fil

Salut,

Je suis en train d'installer une version 1.0.2 de débuggage (réalisée à partir de la 1.0.1). Correction du problème du nom du site (j'espère pas d'erreurs). Modif pour mieux reconnaître Multimania.

Ce serait vraiment bien de la tester, histoire qu'on puisse distribuer cette version compatible avec Multimania (parce que pour l'heure, Multimania est le seul endroit pour pouvoir tester SPIP facilement - Free, faut attendre de recevoir des codes par courrier).

Amicalement,
ARNO*

Fil wrote:

%% De l'intérêt de tester avant d'affirmer : elle apparaît. (On ne la supprime
pas de manière à ce que le code soit idempotent, ie
    propre(propre($texte)) == propre($texte)
)

Heu, t'es sûr que propre() est idempotente ? Plutôt que de se préoccuper
qu'elle le soit (beaux casse-tête en perspective), je pense qu'il vaut
mieux faire gaffe à ne pas l'appeler deux fois de suite sur le même texte,
c'est tout ;))

a+

Le problème, c'est que comme Fil je n'y connais à peu près rien.
Je saurai me débrouiller avec un client (http://www.cvsgui.org/
pour des clients graphiques pour Mac et Windows, merci Michael),
mais côté serveur, nada.

je viens d'essayer le client maccvs, trouvé à l'adresse que tu indiques, et
ça a l'air praticable.

Pour installer un serveur CVS, il y a toujours la possibilité de revenir
vers sourceforge ??

-- Fil

Salut,

Dans la 1.0.2, fichier:
/ecrire/articles.php3

j'ai ajouté les 2 lignes suivantes:

if ($id_article) setcookie('last_article', $id_article, time()+(3600*24));
else $id_article=$HTTP_COOKIE_VARS['last_article'];

L'idée: il est fréquent qu'on se retrouve à charger la page articles.php3 sans id_article. En effet, dès qu'on poste quelque chose (POST) (notamment quand on vient d'éditer un article), l'URL qui s'affiche est simplement article.php3, sans autre précision. Il suffit de recharger cette page, ou d'y revenir (bouton BACK du butineur) pour que l'horreur apparaisse: y'a pas d'article à cette adresse! (Ca fait cake...) A la longue, c'est un peu chiant d'être confronté ainsi régulièrement à ce genre de petite mesquinerie.

Du coup, les 2 lignes ci-dessus font ça:
- s'il y a un id_article spécifié, il est sauvegardé dans un cookie;
- s'il n'y a pas d'id_article spécifié, alors il reprend le dernier utilisé.

Bon, je sais, ça fait un peu "truc de cochon", m'enfin en attendant mieux, c'est tout de même très agréable. (La seule alternative, se serait de faire un header(url:...) à chaque fois qu'on a fait un "POST" sur une page.)

Amicalement,
ARNO*

Salut,

Vu qu'on nous réclamait le retour de l'heure de publication des messages des forums dans uZine, j'ai ajouté 3 filtres dans:
/ecrire/inc_texte.php3
(dans la 1.0.2).

- heures
- minutes
- secondes

(qui fonctionnent sur les dates, comme "jour", "mois", "annee").

Bon, ben c'est tout con, pour afficher l'heure de publication des forums, je fais:
[à (#DATE|heures)h][(#DATE|minutes)]

Amicalement,
ARNO*

%% Karl : dans la fonction propre() ainsi que dans typo(), si on repère dans
le texte à modifier une séquence du type
                    <HTML>quelque chose</HTML>
on préserve "quelque chose", c'est-à-dire qu'on ne lui applique aucune
transformation/correction typo etc. Même chose si on repère <A Href=blabla>,
on ne touche pas, histoire de ne pas casser des liens du type
Salesforce Platform for Application Development | Salesforce US
    ^espaces ^ ^
     insécables

C'est à ça que sert l'expression régulière qui te fait question.

Je comprends mieux et en effet, la balise n'est pas heureuse... :slight_smile: soit créer un namespace particulier.
du genre

<root_element xmlns:spip="http://www.uzine.net/spip/2001/&quot;&gt;
  <spip:html>ne sera plus confondu</spip:html>
</root>

ou alors changer le nom de la balise par, par exemple, <fixedml></fixedml>

(PS: ton mail n'est pas conformant iso88machin ? les accents passent mal)

Humm étonnant, car je n'ai pas de problèmes, il passe même relativement bien dans vos archives... également. Sauf que ce thread me pose des problèmes, et cela est un problème de mon mailer, qui va me donner l'occasion de faire un bug report. En effet, le titre html sous forme de balise génère justement un parasite sur l'affichage html des messages... :slight_smile:
Comme quoi l'utilisation de cette balise dans de mauvaises conditions n'est peut-être pas une bonne idée :wink:

C'est en effet une possibilité si vous n'avez pas envie d'installer un serveur CVS.

Non, c'est pas terrible d'avoir un cookie indiquant le dernier id_article
visité. Pas terrible du tout, question _privacy_ par exemple !

Tu as une autre solution : dans article.php3, si $id_article n'est pas là,
tu fais include "404.php3" au lieu de include "inc-public.php3"

@ Arno* (arno@scarabee.com) :

Salut,

Une fonction qu'on pourrait installer: protéger un article pendant qu'un rédacteur est en train de travailler dessus. Et éviter ainsi que les modifs d'un rédacteur soient écrasées par un autre.

Cela pourrait prendre deux formes:

- quand article modifié, installer un "verrou" sur l'article pour les autres rédacteurs, pendant une certaine durée; ou simplement indiquer _très_ clairement la dernière date de modif (en fait, l'âge: "cet article a été modifié il y a 2 heures");
- 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).

ARNO*

slt, pas mal comme idée si je comprend bien c'est "verrouillage d'article"
pour chaque rédacteur. Le premier rédacteur qui "prend la main sur
l'article,
le verrouille, lorsque il le valide une date de modif apparaît pour indiqué
son changement, c'est ca ?
autre idée, l'archivage d'article

slt, pas mal comme idée si je comprend bien c’est « verrouillage d’article »
pour chaque rédacteur. Le premier rédacteur qui "prend la main sur l’article,
le verrouille, lorsque il le valide une date de modif apparaît pour indiqué son changement, c’est ca ?

Oui.

autre idée, l’archivage d’article

Il y a déjà un système d’archivage de la base.

Mais peut-être évoques-tu une idée qu’on a envisagée y’a un moment: la sauvegarde de toutes les versions successives d’un article (histoire qu’en cas de grosse bêtise, on ait accès à une version précédente). Cela pourrait se faire par la sauvegarde de fichiers XML des versions des articles.

Il y a cependant quelques difficultés pour un tel système:

  • le site « gonfle » en taille très rapidement, ce qui peut être chiant. Si on se contente de conserver une seule version précédente de chaque article, le site double de volume. Si on en sauvegarde deux, il triple de volume, etc.
  • problèmes d’interface: pour l’instant, il est très facile, pour n’importe qui, de comprendre qu’il est en train de modifier l’article; mais si on ajoute « anciennes versions du même article », on perd ce caractère d’évidence (qui est l’objectif premier de l’interface de SPIP). Comment « valider » la modification? (Il ne faut surtout pas, en effet, qu’une fausse manip rétablisse une ancienne version par erreur.)

Au passage: le problème d’interface interdit de se limiter à un ou deux niveaux de sauvergarde. En effet, une personne qui se sera planté (perdu un texte, écrasé tout un passage…) va se mettre à paniquer, cliquer partout, essayer de revenir en arrière (bouton « back »…), s’il voit des versions antérieures, essayer n’importe comment, et au final, il faudrait sauvegarder absoluement toutes les versions pour être certain que la bonne n’a pas disparu. Et la taille du site explose.

Dernière idée: l’absence de sauvegarde oblige à travailler « proprement » (bien vérifier qu’on ne clique pas n’importe où, pour les textes longs travailler dans un éditeur de texte à part avec une sauvegarde du texte original chez soi…). Avec l’idée qu’il y aurait des sauvegardes possibles, comportements moins rigoureux et donc risqués.

=> Donc: c’est sans doute une idée à creuser, mais pour l’instant il semble que les inconvénients l’emportent sur les avantages. Pour l’heure, il me semble qu’il vaut mieux apprendre à travailler proprement, c’est-à-dire (1) effectuer des sauvegardes régulières de la base, (2) les auteurs sauvegardent leurs propres textes sur le disque dur au fur et à mesure.

=> Idée dérivée: Antoine, est-ce qu’il serait possible, au moment de la restauration de la base, de ne rétablir qu’un seul article? (Je suppose qu’avec une version zippée ce serait difficile?) Du coup, seul le webmestre ayant accès au FTP pourrait réaliser l’opération, ce qui limite les problèmes indiqués ci-dessus…

ARNO*

Le Scarabée : http://www.scarabee.com
uZine 2 : http://www.minirezo.net

DH/DSS, 0x11930F0B, DEEB 602D B344 644B AF88 BF73 85F4 2297 1193 0F0B

@ Arno* (arno@scarabee.com) :

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

oui, c'est une très bonne idée. Mais passe plutôt un hash de l'ensemble des
données.

-- Fil