[spip-dev] solution 32 ko

Dev
1

Coucou,

Je remplace dans la beta21 les fichiers ecrire/articles.php3 et
ecrire/articles_edit.php3 ; cela résoud la question des 32 ko, en créant
autant de champs texte de 29 ko que nécessaire pour passer tout le texte.

Attention quand on recolle les morceaux on en recolle au maximum 10, ce qui
fait tout de même un texte de 290 ko... Ca ne serait rien à changer, il
faudrait juste faire une ligne plus longue dans articles.php3 où il est
indiqué
    $texte = $texte1 . $texte2 . ..... . $texte9 . $texte;

mais de toutes façons des textes > 290 ko c'est le meilleur moyen de
flinguer le serveur lorsqu'il calcule propre()...

-- Fil

2

salut

dans la joie de cette bonne nouvelle, j'ai juste remplace les deux fichiers

resultat un bo message

Fatal error: Call to unsupported or undefined function
envoyer_mail_publication() in
/data/data/doma/conflits.org/demo/ecrire/articles.php3 on line 395

c'est juste histoire de le signaler, je fais une vraie update et je vous
tiens au courant

A+
Pedro

PS : vu que mon netscape merdouillait ;-(, j'ai utilise IE

le 20/06/01 13:58, Fil a ecrit :

3

M'ouaif, bof bof bof...

- Sur le principe, ça m'enquiquine beaucoup: ça pénalise ceux qui font l'effort d'utiliser le bon logiciel qui va bien. Exemple: sur Mac, si j'utilise Netscape je n'ai plus de problème, mais mes textes se retrouvent découpés en deux parties alors que je n'en ai pas besoin. J'utilise systématiquement un éditeur externe pour travailler sur mes textes longs, avec copier-coller dans 1 fenêtre; là, avec plusieurs formulaires, je peux plus travailler.

- Dans la pratique: il faut faire une coupure "intelligente": c'est-à-dire découper là où il y a un changement de paragraphe. Là ça coupe au pif au milieu d'une phrase.

- Toujours dans la pratique: celui qui a déjà réussi à télécharger un fichier >32ko l'a fait sans la découpe. Il est donc pour le moins illogique de lui imposer ensuite ce découpage de 32ko.

Je suis vraiment partisan de revenir à la méthode précédente, mais en documentant clairement le bug: c'est-à-dire indiquer pour chaque plateforme quel est le soucis et comment le contourner (quel soft fonctionne correctement).

Pour moi, la seule méthode valable reste l'upload d'un fichier.

ARNO*

4

@ Arno* (arno@scarabee.com) :

- Sur le principe, ça m'enquiquine beaucoup: ça pénalise ceux qui
font l'effort d'utiliser le bon logiciel qui va bien. Exemple: sur
Mac, si j'utilise Netscape je n'ai plus de problème, mais mes textes
se retrouvent découpés en deux parties alors que je n'en ai pas
besoin. J'utilise systématiquement un éditeur externe pour travailler
sur mes textes longs, avec copier-coller dans 1 fenêtre; là, avec
plusieurs formulaires, je peux plus travailler.

Sur le fond je ne suis pas d'accord du tout avec toi : sur le spip_diplo,
par exemple, Explorer pose les "bons" cookies et Netscape non (c'est un bug,
me signale Antoine, mais bref.) Par ailleurs Netscape affiche très mal les
formulaires de spip, alors qu'Explorer les affiche bien. etc. Et, de plus
chacun a ses habitudes, et si tu nous as bassinés pour l compatibilité avec
les hébergeurs les plus pourris de la planète pourquoi ne pas faire de même
avec les brouteurs ??

Enfin, dernier argument, massue cette fois : ce bug fait prendre des risques
ÉNORMES à l'intégrité de ton site. Imagine un admin qui vient juste faire
une petite modif dans un titre. Paf! le texte est mort...

- Dans la pratique: il faut faire une coupure "intelligente":
c'est-à-dire découper là où il y a un changement de paragraphe. Là ça
coupe au pif au milieu d'une phrase.

J'ai fait une coupure sur un espace, mais on peut améliorer pour faire sur
un paragraphe, bien sûr. Je l'avais essayé mais n'y étais pas arrivé du
premier coup: ça avait tendance, au moment où je recollais, à sucrer le
paragraphe en question. Je veux bien réessayer.

- Toujours dans la pratique: celui qui a déjà réussi à télécharger un
fichier >32ko l'a fait sans la découpe. Il est donc pour le moins
illogique de lui imposer ensuite ce découpage de 32ko.

Pas forcément, car avec Explorer j'ai réussi à envoyer un texte de 100ko
mais pas à le relire sans coupe.

Je suis vraiment partisan de revenir à la méthode précédente, mais en
documentant clairement le bug: c'est-à-dire indiquer pour chaque
plateforme quel est le soucis et comment le contourner (quel soft
fonctionne correctement).

D'après le texte que j'ai signalé certains Netscape ne fonctionnent pas
"correctement" non plus. Pas plus que lynx, iCab, etc. Donc: pas de retour
au statu quo ante.

Pour moi, la seule méthode valable reste l'upload d'un fichier.

C'était aussi mon hypothèse de départ. MAIS tu as un problème lors des mises
à jour. Car il faut avoir le fichier à downloader automatiquement et penser
à le reuploader : hyperlourd. L'idée est qu'une modif dans un titre ou un
chapo ne doit impliquer qu'une seule passe: modifier le champ en question.
Et ce quel que soit le brouteur.

Pistes :

    * couper au paragraphe si possible (j'en occupe de toutes façons)

    * ajouter à côté du premier champ texte un bouton "texte complet" qui te
      poppe une fenêtre avec le texte complet (pas dur, mais il faut juste
      imaginer une solution pour effacer tous les champs d'un coup:
      jajascript?) : en débat ?

    * un spip_meta ou un réglage par cookie utilisateur (bof, à mon avis)

5

> Pour moi, la seule méthode valable reste l'upload d'un fichier.

Post-scriptum sur cette question : l'upload de fichier (texte brut OU xml OU
M$Word OU ...) est bien entendu une hyper-bonne idée, mais surtout lors de
la CRÉATION d'un article.

6

Salut,

Je suis en train d'essayer de fabriquer une page qui provoque le download (le client récupère le document) du "texte" d'un article. Par exemple:
www.rezo.net/~arno/ecrire/text_edit.php3?id_article=447

Le but est de récupérer une version en mode texte du source de l'article, afin de pouvoir le modifier dans un éditeur et ensuite de le réinjecter (upload).

Le problème, c'est que je n'arrive pas à obtenir le bon "charset". Pour le moment, je fais:

header("Content-Type: text/download; charset=iso-8859-1\n");
header("Content-Transfer-Encoding: quoted-printable\n");
header("Content-Length: $longueur\n");
header("Content-Disposition: inline; filename=texte$id_article.txt\n");

Le "text/download" m'assure que la page ne s'affiche pas, mais que ça provoque bien la sauvegarde d'un fichier ("texte447.txt", grâce à "filename=..."). Mais les accents dans ce cas déconnent complètement (en tout cas, sur Mac...), malgré le "charset=iso-8859-1". J'essaie plusieurs variantes de "Transfer-Encoding", mais ça ne provoque rigoureusement aucune modification (7bit, 8bit, quoted-printable...).

Quelqu'un sait-il faire ce genre d'opérations?

Amicalement,
ARNO*

7

Mmmh, dites, c'est pas évident ce machin-là....

L'argument de Fil me semble d'importance :

Enfin, dernier argument, massue cette fois : ce bug fait prendre des risques
ÉNORMES à l'intégrité de ton site. Imagine un admin qui vient juste faire
une petite modif dans un titre. Paf! le texte est mort...

    * couper au paragraphe si possible (j'en occupe de toutes façons)

Si on fait une découpe, oui, ça paraît primordial.
Un ereg("^(.*)( *[\r\n]){3,}(.*)$", substr($texte, 0, 25000), $regs) ne renverrait-il
pas dans $regs[1] et $regs[3] la première partie et le début de la seconde ?
Ca pourrait même être fait de façon itérative :

$texte_coupe = '';
$nb_coupes = 0;
$suite = $texte;
while (strlen($suite) > 30000) {
  if (!ereg("^(.*)( *[\r\n]){3,}(.*)$", substr($suite, 0, 25000), $regs)) break;
  $texte_coupe[++$nb_coupes] = $regs[1];
  $suite = $regs[3].substr($suite, 25000);
}
$texte_coupe[++$nb_coupes] = $suite;

    * ajouter à côté du premier champ texte un bouton "texte complet" qui te
      poppe une fenêtre avec le texte complet (pas dur, mais il faut juste
      imaginer une solution pour effacer tous les champs d'un coup:
      jajascript?) : en débat ?

A propos de fenêtre qui poppe, j'ai un problème avec celle qui
sert à s'enregistrer pour les forums avec abonnement : sous
netscape : elle se met systématiquement SOUS la fenêtre principale.
Y a pas un truc pour remédier à ça ?

a+

Antoine.

8

ARNO* wrote:

Le "text/download" m'assure que la page ne s'affiche pas, mais que ça
provoque bien la sauvegarde d'un fichier ("texte447.txt", grâce à
"filename=..."). Mais les accents dans ce cas déconnent complètement
(en tout cas, sur Mac...), malgré le "charset=iso-8859-1". J'essaie
plusieurs variantes de "Transfer-Encoding", mais ça ne provoque
rigoureusement aucune modification (7bit, 8bit, quoted-printable...).

Ben... ton Mac accepte le charset iso-8859-1 en .txt, d'habitude ?

header("Content-Transfer-Encoding: quoted-printable\n");
header("Content-Length: $longueur\n");

Pourquoi ceux-là ?

9

ARNO* wrote:

Le "text/download" m'assure que la page ne s'affiche pas, mais que ça
provoque bien la sauvegarde d'un fichier ("texte447.txt", grâce à
"filename=..."). Mais les accents dans ce cas déconnent complètement
(en tout cas, sur Mac...), malgré le "charset=iso-8859-1". J'essaie
plusieurs variantes de "Transfer-Encoding", mais ça ne provoque
rigoureusement aucune modification (7bit, 8bit, quoted-printable...).

Ben... ton Mac accepte le charset iso-8859-1 en .txt, d'habitude ?

Ouh là, t'es pas loin de me parler en chinois, là :-))

> header("Content-Transfer-Encoding: quoted-printable\n");

header("Content-Length: $longueur\n");

Pourquoi ceux-là ?

Euh, pour le "transfer-encoding", je sais pas à quoi ça sert. Disons que j'étais en train d'essayer toutes les variantes autour du header (7bit, 8bit, du us-ascii et compagnie).

Pour le "content-length", c'est ce qui permet au butineur d'afficher une barre de progression lors du download ($longueur étant la taille du fichier récupéré).

ARNO*

10

Je cherche un nom potable pour le fichier spip_unpack.php3
(cf. http://rezo.net/spip-dev/INSTALL/)

Fil a proposé amorce.php3, je trouve ça pas terrible
(d'autant que ça peut servir à réinstaller aussi).
Je proposais carrément spip.php3, peut-être un peu
trop général. Sinon : charger, chargeur, loader.php3,
bof bof bof.... Des idées ?

11

Le problème pour "couper au paragraphe" ne vient pas du problème de la
localisation du paragraphe en question. Un strpos(...) conviendrait. En
revanche la difficulté vient du fait que si l'on passe des lignes vides en
début de formulaire le brouteur peut ne pas en tenir compte, et donc au
moment où il renvoit le texte, il ne renvoit pas les sauts de ligne, ce qui
fait qu'au final le paragraphe est (peut être) perdu.

Bref, une solution serait de couper au paragraphe ET d'inclure un <p>
devant, qui sera donc recollé gentiment au retour (on peut même au retour,
avant de recoller, faire un ereg_replace("^<p>","\n\n"...)), mais tout ça
est un peu... lourd. Peut-on trouver plus élégant ?

(Interdit de recoller en ajoutant le paragraphe sans précaution, car s'il
n'y a aucun paragraphe dans les 1024 caractères qui suivent le caractère
situé à 28ko, on doit chercher un espace, et s'il n'y a pas d'espace couper
"dans la viande", à 28ko précisément. On peut se donner du mou en coupant à
28ko ± 3ko, mais il y aura toujours le texte de folie qui fait que ça
casse... un texte sans paragraphes, par exemple...)

PS: faut-il tolérer des textes > 280 ko ? Actuellement ils seraient
tronqués -> une solution serait, au moment où l'on recolle, de faire une
boucle
    tant que ($texte[$i] non vide) {
        coller $texte[$i]
    }

mais je ne sais pas faire lorsqu'il s'agit des variables $texte1 $texte2 etc.
et non d'un tableau.

PPS: la fonction qui coupe est au début d'articles_edit.php3 : tu lui donnes
un texte, elle te renvoie le $debut (28ko ± 1ko, coupé sur un espace SI
POSSIBLE) et la suite (à re-couper si nécessaire).

function coupe\_trop\_long\($texte\)\{    // utile pour les textes &gt; 32ko
    $debut = substr\($texte, 0, 28\*1024\);
    $suite = substr\($texte, 28\*1024\);

    $pos = strpos\($suite,&quot; &quot;\);
    if \(is\_int\($pos\) &amp;&amp; $pos &lt; 1024\)\{
        $ajout = substr\($suite, 0, $pos\)\.&quot; &quot;; // le \.&quot; &quot; est sans doute

                                                  // inutile...
$suite = substr($suite, $pos);
$debut .= $ajout;
}

    return \(array\($debut,$suite\)\);
\}
12

Re-coucou,

Fil wrote:

Le problème pour "couper au paragraphe" ne vient pas du problème de la
localisation du paragraphe en question. Un strpos(...) conviendrait. En
revanche la difficulté vient du fait que si l'on passe des lignes vides en
début de formulaire le brouteur peut ne pas en tenir compte, et donc au
moment où il renvoit le texte, il ne renvoit pas les sauts de ligne, ce qui
fait qu'au final le paragraphe est (peut être) perdu.

???.... heu, j'ai pas bien compris ;))

(Interdit de recoller en ajoutant le paragraphe sans précaution, car s'il
n'y a aucun paragraphe dans les 1024 caractères qui suivent le caractère
situé à 28ko, on doit chercher un espace, et s'il n'y a pas d'espace couper
"dans la viande", à 28ko précisément.

Si tu regardes la routine que je t'ai fournie, elle devrait chercher le _dernier_
saut de paragraphe, grâce au caractère "greedy" du (.*) en début de regexp.
Du coup, pas besoin de restreindre la recherche aux 1024 caractères etc.

Quant aux textes avec des paragraphes de plus de 32 Ko, on va dire que
SPIP est en-dehors de ce genre d'utilisation ;))

mais je ne sais pas faire lorsqu'il s'agit des variables $texte1 $texte2 etc.
et non d'un tableau.

$nom_var = "$texte$i";
$texte_i = $$nom_var; // double dollar pour prendre la variable dont le nom est $nom_var

a+

13

A propos des coupes à 32ko, nouvelle version dans beta21 : cf. explications
************************** confuses ci-dessous.

> Le problème pour "couper au paragraphe" ne vient pas du problème de la
???.... heu, j'ai pas bien compris ;))

on avait la situation suivante :

%% texte original %%

texte A\n
\n
\n
texte B

%% coupe %%

formulaire 1 -> texte A\n\n\n

formulaire 2 -> texte B

%% renvoie vers spip %%

-> texte Atexte B (le paragraphe a disparu)

Pour récupérer le paragraphe, j'insère donc, au moment où je coupe, un tag
final <P SPIP> dans le champ texteA, que je vais nettoyer au moment où je
recolle. Et le plus étonnant est que... ça marche. :wink:

L'essentiel est là : le fichier n'est pas tué par une petite modif sur un
titre. Reste des petits soucis d'interface :

1) comment provoquer la création d'un champ texte1 ? (pas hypernécessaire,
puisqu'il suffit de bourrer le champ texte "ras la gueule" pour obtenir deux
champs à remplir avec le bon texte) -> peut-être est)ce mieux de ne rien
ajouter.

2) comment satisfaire le besoin d'ARNO* de récupérer et remonter le texte en
un seul fichier :
- le download, il y travaille
- mais après pour remonter le texte l'idéal est de le coller d'un bloc dans
le champ texte1. Problème : il faut alors vider les champs texte2, texte3...
et texte de leur contenu. Pas hyper pratique donc. Un petit bouton jajascript??

A propos de spip_amorce :

14

Fil wrote:

%% coupe %%

formulaire 1 -> texte A\n\n\n

formulaire 2 -> texte B

%% renvoie vers spip %%

-> texte Atexte B (le paragraphe a disparu)

Pour récupérer le paragraphe, j'insère donc, au moment où je coupe, un tag
final <P SPIP> dans le champ texteA, que je vais nettoyer au moment où je
recolle. Et le plus étonnant est que... ça marche. :wink:

Mais, heu, attends, c'est plus simple de rajouter les \n\n\n
quand tu recolles, non ? Sachant que de toute façon, en cas
de \n superflus, la fonction propre les bazarde... Quant à
la disparition de paragraphe, c'est probablement qu'il y a un
trim() quelque part, et qui est là pour ça ;))

1) comment provoquer la création d'un champ texte1 ? (pas hypernécessaire,
puisqu'il suffit de bourrer le champ texte "ras la gueule" pour obtenir deux
champs à remplir avec le bon texte) -> peut-être est)ce mieux de ne rien
ajouter.

oui, à mon avis c'est mieux.

par contre, ce qui serait classe, c'est détecter si le navigateur a besoin
d'un découpage : test sur $HTTP_USER_AGENT. Par exemple, pour Mozilla/4.*,
a priori, y a pas besoin (?).

- mais après pour remonter le texte l'idéal est de le coller d'un bloc dans
le champ texte1. Problème : il faut alors vider les champs texte2, texte3...
et texte de leur contenu. Pas hyper pratique donc. Un petit bouton jajascript??

Oui pquoi pas. Heu, de tte façon, il est rare qu'il y ait plus de deux
texte[i], non ?! Après, y a un problème de confort de consultation du
site....

les FICHIERS !

oups, ok ;))

a+

15

Salut,

Je suis en train de travailler assez sévèrement sur:
/inc-calcul.php3

Ce serait sympa de ne pas bosser dessus pile maintenant... :slight_smile:

(Pour info, j'inclus notamment la gestion des pétitions dans l'interface publique - m'enfin comme c'est pas géré dans l'interface publique, ça ne vous mènera nulle part dans l'immédiat :-))

Amicalement,
ARNO*

16

@ Antoine Pitrou (pitrou@free.fr) :

Mais, heu, attends, c'est plus simple de rajouter les \n\n\n
quand tu recolles, non ? Sachant que de toute façon, en cas

Sauf si je ne trouve pas de paragraphe et que je coupe sur un espace :slight_smile:
(Sur le site du Diplo ça peut arriver, puisqu'on a intégré des fichiers en
HTML et pas en SPIP, les para sont signalés par des <P> et donc pas coupés
par le coupeur).

Pour la solution du USER_AGENT, ça paraît une bonne idée. Peut-être peut-on
procéder de la manière suivante : a priori tout est suspect sauf une liste
de navigateurs vérifiés un par un. (Ce qui résoudrait au moins le pb d'ARNO*
qui pourrait alors valider son propre brouteur préféré)!

17

Salut,

J’installe la version beta 22. Le grosse nouveauté, c’est la gestion des pétitions (dont j’avais besoin pour uZine). Bon, c’est pas encore intégré aux squelettes par défaut, donc pas de panique…

Les modifs ont porté sur les fichiers:

/inc-calcul.php3
/inc-public.php3
/ecrire/inc.php3
/ecrire/articles.php3
/ecrire/controle_forum.php3
/ecrire/controle_petition.php3

Vous pouvez voir ça en action sur:
http://rezo.net/~arno/article60.html
(vous verrez que ça compte le nombre de signatures, et sur la page suivante ça présente les signatures sur deux colonnes et sur plusieurs pages).

(1) Commencer une boucle selon un paramètre…

18

Petit oubli du précédent envoi: pour déterminer si une pétition est attachée à un article, j’ai introduis le pseudo-tag suivant:
#PETITION

dont le fonctionnement va vous paraître bizarre. Il ne sert en fait que de test conditionnel.

  • s’il y a un pétition, il affiche un espace (" "), donc ce qui l’accompagne est affiché;
  • s’il n’y a pas de pétition, il retourne “” (rien, que dalle), donc ce qui l’accompagne n’est pas affiché.

C’est ce qui me permet ici de faire:

[<A HREF="petition.php3?id_article=#ID_ARTICLE">Signer la pétition</A>(#PETITION)]

Comprendre: s’il y a une pétition, le lien “Signer la pétition” est affiché. Sinon, non.

19

En gros comme en détail, ça ne marchera pas avec un encoding machin, car
Netscape ne fait pas la transformation des accents lors des downloads. (Lors
des ftp, Fetch fait les corrections d'accents sur les fichiers dont il
repère qu'ils sont de type 'texte', c'est parfois hasardeux aussi). Seule
solution : ecrire/articles_edit.php3 repère si le client est un Macintosh,
et fait la conversion en caractères Mac au niveau du serveur.

Mais l'autre solution proposée, qui consiste à repérer le USER_AGENT dans
une liste de navigateurs "sûrs", est peut-être la plus intelligente ?
"Netscape4.5 Macintosh" est dans la liste : on coupe pas ; iCab3.02b1 pour
BeOS n'est pas dans la liste : on coupe. On fait une liste en regexp pour
quand même pas trop se prendre le chou, mais on fait attention à prendre une
option assez restrictive pour ne faire courir de risque à personne, et hop!

Non ?

@ Arno* (arno@scarabee.com) :

20

Salut,

Dans la beta 22, modification du fichier:
/ecrire/controle_forum.php3

On avait un problème avec les messages sucrés: toutes les réponses à ces messages disparaissaient également, ce qui rendait la coupure assez violente. Désormais, quand on sucre un message, ses réponses ne sont plus supprimées toujours (et remontent d'un cran dans le thread).

Cette modif permet donc un contrôle beaucoup plus efficace sur les forums.

ARNO*