[spip-dev] a faire dans spip

Dev
1

Quelques TODO et remarques :

1) interface interne

* "les rubriques", "naviguer" et "tout le site" sont un poil redondants.
  (ARNO*?)

2) distribution

on s'achemine vers la distribution publique de la v1.0 de SPIP? ce serait
bien que, au moment où l'utilisateur fait son install, il y ait un
remplissage automatique de la base de données avec un ou plusieurs articles,
une ou plusieurs rubriques. Ca permettrait de positionner le programme comme
un "pas comme les autres", et de diminuer la difficulté de prise en main
(modifier un article, plus facile que créer).

Pour le contenu, je propose "De la liberté de la presse (Robespierre, 22
aout 1791), ainsi qu'un article de "Libres enfants du savoir numérique" --
Autre solution : mettre la doc de SPIP. C'est moins marrant, mais... Autres
idées ? (Il faut des textes libres de droits)

* puisqu'on n'aura pas le temps de faire plein d'exemples de squelettes,
autant être raisonnables = avoir une maquette "de base" un peu moins laide
(ARNO*?) et encourager les utilisateurs à faire circuler leurs squelettes
sur la liste <spip@rezo.net>

3) customisation

* supprimer intelligemment la ligne
  $retour .= "<? if (\$db_erreur) echo "<P><H4>Attention&nbsp;
dans inc-calcul.php3 (idée : définir une variable, et si undef() alors
mettre cette horreur. Elle ne sert qu'à mettre en garde l'utilisateur d'un
forum lorsque la base de données est en rade : elle devrait être plus
discrète et placée au niveau de l'appel forum (si appel il y a)

* il y a un début de ça dans inc_texte.php3 : il suffit d'avoir, dans le
article.php3, une ligne $puce="*"; pour que la puce soit une étoile.

De même, définir $debut_intertitre et $fin_intertitre permet que les
{{{intertitre}}} deviennent par exemple
<H4>intertitre</H4>
    ou
<H3 style=...>intertitre</H3>
(ou ce qu'on voudra)

4) Fonctionnalités

* une boucle retrouvant les articles par mots-clés.

-- Fil

2

Hello,

* "les rubriques", "naviguer" et "tout le site" sont un poil redondants.
  (ARNO*?)

Mmmh, on pourrait supprimer "rubriques" (la seule exclusivité étant de
pouvoir supprimer une rubrique, ce qu'on peut rajouter dans "naviguer").
En plus, la place laissée libre dans le bandeau de navigation pourrait
être utilisée pour autre chose : par exemple les mots-clés, quand il
y aura une page récapitulative.

Pour le contenu, je propose "De la liberté de la presse (Robespierre, 22
aout 1791), ainsi qu'un article de "Libres enfants du savoir numérique" --
Autre solution : mettre la doc de SPIP. C'est moins marrant, mais...

Mais plus utile :)) On pourrait combiner les deux. Enfin, ça rajoute
quand même du code chiant (penser, à chaque fois, à recopier le code
SPIP des articles de la doc...). Effectivement, avec un texte "figé",
c'est plus simple.

* puisqu'on n'aura pas le temps de faire plein d'exemples de squelettes,
autant être raisonnables = avoir une maquette "de base" un peu moins laide

Je la trouve tout à fait correcte : elle démontre très bien les fonctionnalités
(sauf la syndication, qu'il faudra rajouter). Les couleurs sont sûrement à
revoir (petites fontes en blanc sur fond sombre, c'est illisible : même remarque
pour les boutons colorisés sous Explorer dans l'espace privé - sous Netscape,
pas de problème, la feuille de style n'est pas prise en compte :-))).

et encourager les utilisateurs à faire circuler leurs squelettes
sur la liste <spip@rezo.net>

Yes !

* supprimer intelligemment la ligne
  $retour .= "<? if (\$db_erreur) echo "<P><H4>Attention&nbsp;
dans inc-calcul.php3 (idée : définir une variable, et si undef() alors
mettre cette horreur. Elle ne sert qu'à mettre en garde l'utilisateur d'un
forum lorsque la base de données est en rade : elle devrait être plus
discrète et placée au niveau de l'appel forum (si appel il y a)

Hmm, oui...

4) Fonctionnalités

* une boucle retrouvant les articles par mots-clés.

Déjà fait :)) (cf. squelettes par défaut).

ciao

Antoine.

3

Salut,

A faire avant tout:

- tout doit fonctionner sous PHP3. Les mots-clé et le rétablissement de la base de données doivent fonctionner sous PHP3 (la récupération d'une base qui gèle le fonctionnement du site, c'est pas bon du tout du tout). Raison principale: on s'est pas fait chié à adapter SPIP pour n'importe quel hébergeur pour que d'un coup on se prive de la compatibilité PHP3. Surtout: SPIP qui ne tournerait pas sur le Scarabée, je suis pas prêt de l'accepter :slight_smile:

- refondre l'interface. La page "articles" est devenue imbitable. Le fait d'avoir deux versions de présentation ne doit pas nous autoriser à proposer une version incompréhensible (la version "complète" ne doit pas être une version "compliquée"). De plus, la gestion des mots-clé, c'est n'importe quoi. Gaffe à ne pas se laisser emporter par l'enthousiasme technique: SPIP est volontairement bridé, histoire justement que la compréhension du site et de l'interface par l'utilisateur soit _évidente_ (l'idée de base: le mode d'emplois est quasiment inutile). L'exemple classique, c'est l'impossibilité de double hiérarchie (une seule hiérarchie des rubriques, et un article ne peut pas être dans plusieurs rubriques): c'est pas un problème technique (on aurait sans problème pu autoriser deux hiérarchies et un rubricage multiple des articles), c'est avant tout un problème de conception de site: très très peu de webmestres sont capables de créer une interface à plusieurs niveaux de hiérarchie (conceptualisation _et_ interface graphique).

- corriger le problème de la syndication: Antoine a fait remarquer qu'une des boucles ne provoquait pas le chargement des items syndiqués. J'ai pas encore trouvé de solution élégante.

- je suis totalement opposé à l'installation de contenus "par défaut": ça oblige ensuite à sucrer ce contenu (et c'est plutôt chiant à faire). Ca me semble vraiment une fausse bonne idée.

- est-ce qu'on a fait des nouveaux tests de vitesse? Ainsi, est-ce que la nouvelle version de propre() ne ralentit pas trop les sites (genre chez Free). Ajouter des ereg_replace sur un texte de plusieurs milliers de signes, ça doit se sentir, non?

Sinon, les récentes modifs à toute vitesse pendant que je suis pris sur JeBoycotteDanone, c'est moyennement sympa. Je découvre 3 listes SPIP, un nouveau FTP (est-ce que j'ai les codes pour effectuer les modifs?), de nouvelles boucles sans documentation... et la mise en ligne de versions dont les fonctions ne sont pas finalisées (mots-clé à l'interface incohérente), c'est pas bon, ça. Remarque importante: on s'approche de la release avec des versions qui évoluent de plus en plus vite, de plus en plus impossible d'arriver à stabliser l'évolution de SPIP. Les "to do lists" qui me semblent induire plus d'instabilité que de stabilité.

Pour mois, la to do list avant la release est simple:
- stabiliser l'évolution de SPIP: _pas de nouvelles fonctionnalités_, mais au contraire le débuggage complet de ce qui existe et une vérification complète du système sur différents sites "en service" (pour info, manquent toujours des fonctionnalités très simple pour qu'uZine passe sous SPIP);
- la refonte de l'interface pour retrouver le caractère d'évidence qu'on a perdu;
- une documentation complète;
- des squelettes et une bibliothèque de squelettes.

Amicalement,
ARNO*

4

@ Arno* (arno@scarabee.com) :

- corriger le problème de la syndication: Antoine a fait remarquer
qu'une des boucles ne provoquait pas le chargement des items
syndiqués. J'ai pas encore trouvé de solution élégante.

Une remarque : si la syndication se fait au moment où tu demandes la page,
ce sera forcément TRÈS lent. Ce qui n'interdit pas de se poser la question :

- est-ce qu'on a fait des nouveaux tests de vitesse? Ainsi, est-ce
que la nouvelle version de propre() ne ralentit pas trop les sites
(genre chez Free). Ajouter des ereg_replace sur un texte de plusieurs
milliers de signes, ça doit se sentir, non?

Après tests, elle est deux fois plus lente que celle d'avant (~ 1/2 sec.
contre ~ 1/4 sec dans un exemple moyen). 100 fois sur le métier... je vais
essayer de l'accéléler (peut-être au détriment de sa lisibilité).

pour info, le code de test que j'utilise est le suivant :
<?
    $texte=join("\n",file("index.html"));
    include "/www/spip/ecrire/inc_texte.php3";
    $a=time();
    for ($i=0; $i<50;$i++) {
        propre($texte);
    }
    print time()-$a;
    print " secondes, $i iterations.";
?>
et je lui passe un fichier html quelconque.

-- Fil

5

Hello,

- tout doit fonctionner sous PHP3. Les mots-clé et le rétablissement
de la base de données doivent fonctionner sous PHP3 (la récupération
d'une base qui gèle le fonctionnement du site, c'est pas bon du tout
du tout). Raison principale: on s'est pas fait chié à adapter SPIP
pour n'importe quel hébergeur pour que d'un coup on se prive de la
compatibilité PHP3. Surtout: SPIP qui ne tournerait pas sur le
Scarabée, je suis pas prêt de l'accepter :slight_smile:

- Le rétablissement de la base fonctionne à partir de PHP 3.0.6,
c'est-à-dire la version dans laquelle le strpos() à 3 paramètres
a été introduit (je ne savais pas que ça ne marchait pas partout
vu que la doc PHP n'en parle pas). J'introduirai un test et
désactiverai la fonctionnalité pour les versions inférieures :
à moins que quelqu'un écrive des routines de parsing XML sans
strpos() à 3 paramètres.

- les mots-clés, aucune incompatibilité, sauf la fonction
recherche qui ne fonctionne que sous php4 (désactivée sous
php3). On peut faire une fonction recherche plus simple
pour php3, mais l'idée était quand même, pour moi, de ne pas
avoir à entrer l'orthographe exacte, et la fonction qui est
utilisée pour ça n'existe pas en php3. Accessoirement il
serait sûrement intéressant de réutiliser cette fonction
pour les auteurs (utile dans uzine : taper "pitrou" au lieu
de sélectionner "Antoine Pitrou" dans le pop-up).

c'est pas un problème
technique (on aurait sans problème pu autoriser deux hiérarchies et
un rubricage multiple des articles), c'est avant tout un problème de
conception de site: très très peu de webmestres sont capables de
créer une interface à plusieurs niveaux de hiérarchie
(conceptualisation _et_ interface graphique).

Et c'est pour ça qu'on a des mots-clés, qui créent de facto une
indexation supplémentaire et multiple. Tu ne peux pas nier que
c'est une fonctionnalité qui sera utilisée sur très peu de sites
(ne serait-ce que parce que créer une indexation, puis sélectionner
des mots-clés pour chaque article prend du temps et que la plupart
des gens n'ont pas beaucoup de raisons de le faire).

- est-ce qu'on a fait des nouveaux tests de vitesse? Ainsi, est-ce
que la nouvelle version de propre() ne ralentit pas trop les sites
(genre chez Free). Ajouter des ereg_replace sur un texte de plusieurs
milliers de signes, ça doit se sentir, non?

Mmmh, oui, voir avec Fil :)) Ceci dit, à vue de nez, le propre a un
impact assez faible sur la vitesse d'affichage (cf. l'espace privé),
par rapport au traitement des squelettes.
Personnellement, je trouve le traitement automatique des M./Mme. et
des nombres quelque peu superflu ;)) Egalement, remettre les str_replace ?

Ah oui je ne sais pas si t'as vu mais j'ai par contre largement
amélioré le couper(), qui ne passe plus sur tout le texte avant
de couper à x caractères. La fonction majuscules de Fil et moi
est aussi largement mieux qu'avant.

Je découvre 3 listes
SPIP, un nouveau FTP (est-ce que j'ai les codes pour effectuer les
modifs?), de nouvelles boucles sans documentation...

Heu, personnellement j'aurai du mal à rentrer dans ton PDF pour
ajouter la doc des boucles nouvellement créées. D'ailleurs les boucles
de syndication y sont-elles ?

et la mise en
ligne de versions dont les fonctions ne sont pas
finalisées

C'est pour ça qu'elles s'appellent "alpha" et qu'elles sont dans "devel".

(mots-clé
à l'interface incohérente)

Peut-être mais là on attend des suggestions pour l'améliorer, non ?

- la refonte de l'interface pour retrouver le caractère d'évidence
qu'on a perdu;

Hem, en version "interface simplifiée", l'évidence me semble plus
grande qu'auparavant :wink:
A ce propos, Fil, quel est le retour des gens du Diplo (non-informaticiens)
vis-à-vis de l'interface actuelle de SPIP ?

a+

6

Mmmh, oui, voir avec Fil :)) Ceci dit, à vue de nez, le propre a un
impact assez faible sur la vitesse d'affichage (cf. l'espace privé),
par rapport au traitement des squelettes.
Personnellement, je trouve le traitement automatique des M./Mme. et
des nombres quelque peu superflu ;)) Egalement, remettre les str_replace ?

Si je les enlève on gagne bien 1%, rien qui vaille la peine d'en parler.
Non, c'est sans doute en passant par des fonctions plus rapides qu'est la
voie : il faut explorer str_replace et ereg_replace en tableau (mais
problème de version de php : je m'étais concentré sur les fonctions là...
ainsi "str_replace() was added in PHP 3.0.6, but was buggy up until PHP
3.0.8. ")

A ce propos, Fil, quel est le retour des gens du Diplo (non-informaticiens)
vis-à-vis de l'interface actuelle de SPIP ?

Sur SPIP en soi : génial (évidemment). Le côté interface simplifiée/
complète est un peu déroutant, en revanche. Le fait d'avoir limité la taille
des logo_article est très confortable. Prise en mains en deux heures (et
avec des versions changeantes).

-- Fil

7

Fil wrote:

Si je les enlève on gagne bien 1%, rien qui vaille la peine d'en parler.
Non, c'est sans doute en passant par des fonctions plus rapides qu'est la
voie : il faut explorer str_replace et ereg_replace en tableau (mais
problème de version de php : je m'étais concentré sur les fonctions là...
ainsi "str_replace() was added in PHP 3.0.6, but was buggy up until PHP
3.0.8. ")

Oui, suffit d'utiliser le $flag_str_replace dans inc_texte.php3.

a+

8

> ainsi "str_replace() was added in PHP 3.0.6, but was buggy up until PHP
> 3.0.8. ")

Oui, suffit d'utiliser le $flag_str_replace dans inc_texte.php3.

en fait le plus utile c'est preg_replace (PHP 3>= 3.0.9, PHP 4 ) ; très
rapide : mon test passe de 9 secondes (SPIP 0.99c) à 19 secondes (version
actuelle) pour retomber à 7 secondes (avec preg_replace).

Je peaufine et j'envoie à Antoine pour qu'il l'installe dans /devel

-- Fil

9

"Note: The Perl-compatible regular expression functions are available in PHP 4 and in PHP 3.0.9 and up."

hem hem ;))

10

- Le rétablissement de la base fonctionne à partir de PHP 3.0.6,
c'est-à-dire la version dans laquelle le strpos() à 3 paramètres
a été introduit (je ne savais pas que ça ne marchait pas partout
vu que la doc PHP n'en parle pas). J'introduirai un test et
désactiverai la fonctionnalité pour les versions inférieures :
à moins que quelqu'un écrive des routines de parsing XML sans
strpos() à 3 paramètres.

C'est pourtant ce que fait le système de syndication (analyser le backend.php3). Le strpos à 3 positions, est-ce que c'est autre chose qu'un strpos précédé d'un substr à partir du troisième paramètre?

Amicalement,
ARNO*

11

@ Antoine Pitrou (pitrou@free.fr) :

"Note: The Perl-compatible regular expression functions are available in PHP 4 and in PHP 3.0.9 and up."

hem hem ;))

Attends : on ne va pas faire trois version de la fonction !

= 3.09 -> preg_replace

< 3.09 -> ereg_replace

si on ajoute str_replace c'est uniquement pour la version 3.08, et ce ne
sera pas pour les remplacements les plus coûteux !

-- Fil

12

ARNO* wrote:

C'est pourtant ce que fait le système de syndication (analyser le
backend.php3).

Oui mais on ne peut pas faire avec un fichier de 10 Mo ce qu'on fait
avec un fichier de 3 Ko (on ne peut même pas le charger en entier
en mémoire...).

Le strpos à 3 positions, est-ce que c'est autre chose
qu'un strpos précédé d'un substr à partir du troisième paramètre?

Non, mais ça risque de ralentir le truc à mort. J'essaierai.

a+