Tout d'abord bravo pour tout le boulot SPIP, c'est assez génial et ça
fonctionne plutôt très bien.
Normalement j'aime pas les content-manager car trop figés dans leur
structure, mais là je dois avouer qu'on peut faire ce qu'on veut.
Je suis en train de faire un squelette et j'ai noté un truc ou deux,
ayant eu à aller trifouiller le code.
Les caractères comme le é, à, è etc.. sont remplacés par des
caractères étranges (vu dans inc.formulaires).
Certains fichiers sont également en double interlignage (typique de
certains éditeurs sur win qui enregistrent pas au format unix).
Ma principale critique porte sur le code HTML. Dans les squelettes,
c'est pas gênant puisqu'on a la main dessus. Par contre j'ai vu dans
le code (inc.formulaires) que vous passiez des classes du type
truc_truc. Juste pour info, le '_' ne passe pas avec Netscape, et est
d'ailleur interdit dans tout attribut HTML (normalement).
Si vous le souhaitez je peux vous envoyer la page avec les modifs, ou
si vous avez un CVS...
Concernant le backoffice, je trouve ça très beau mais un peu lourd et
lent. Alors c'est vrai qu'on ne peut rien aux bases de données d'un
serveur mais par contre, toutes ces images sont elles vraiment
nécessaires ?
Voilà pour mes quelques remarques qui ne doivent pas occulter que je
suis comblé par la gestion des articles, des brèves et la syndication
de sites (c'est vraiment génial ça!).
Encore bravo pour ce boulot qui doit être assez monstrueux
PS: j'espère que j'envoie ça à la bonne adresse, j'ai pas trouvé de
mail direct vers un développeur de SPIP.
Les caractères comme le é, à, è etc.. sont remplacés par des
caractères étranges (vu dans inc.formulaires).
Ton client FTP a mal fait son boulot.... Change le réglage
binaire / ascii
Certains fichiers sont également en double interlignage (typique de
certains éditeurs sur win qui enregistrent pas au format unix).
Ou typique de certains éditeurs Unix qui ne gèrent pas correctement
les fichiers issus de Windows Personnellement je suis sous Windows,
et les deux autres développeurs sous Mac. Avec de bons éditeurs, on
arrive à se débrouiller....
Ma principale critique porte sur le code HTML. Dans les squelettes,
c'est pas gênant puisqu'on a la main dessus. Par contre j'ai vu dans
le code (inc.formulaires) que vous passiez des classes du type
truc_truc. Juste pour info, le '_' ne passe pas avec Netscape, et est
d'ailleur interdit dans tout attribut HTML (normalement).
??? C'est bizarre, tu veux dire que <p class="spip_texte"> ne serait
pas conforme HTML ??
Alors c'est vrai qu'on ne peut rien aux bases de données d'un
serveur mais par contre, toutes ces images sont elles vraiment
nécessaires ?
Où machin.php3 est une page SPIP standard avec la définition de
$fond et $delais, et l'appel de inc-public.
Il faudra donc ajouter une nouvelle balise pour l'inclusion (quand
j'aurai suffisamment de courage...). Je penche pour un truc du genre :
<INCLURE(machin.php3) {id_rubrique}>
La mention explicite des paramètres à passer au squelette est obligatoire,
sinon il va y avoir des tas d'instances différentes dans le cache.
Par exemple si je fais un squelette séparé pour l'affichage de la hiérarchie
en haut, et que je l'appelle depuis chaque squelette article, il ne faut
pas que deux articles de la même rubrique créent deux fichiers différents
dans le cache sous prétexte que l'id_article est différent.
Alors que si le webmestre spécifie quels paramètres transmettre, ça
contrôle aussi le nommage du fichier cache.
J'ai pas testé plus loin, mais l'inclusion récursive, du même ou de
plusieurs squelettes, ne devrait poser aucun problème.
>Les caractères comme le é, à, è etc.. sont remplacés par des
>caractères étranges (vu dans inc.formulaires).
Ton client FTP a mal fait son boulot.... Change le réglage
binaire / ascii
Euh, normalement on avait décidé de ne pas laisser traîner d'accents dans
les fichiers, par le recours aux é quand c'est possible, et aux
chr(xx) sinon.
> Certains fichiers sont également en double interlignage (typique de
> certains éditeurs sur win qui enregistrent pas au format unix).
Ou typique de certains éditeurs Unix qui ne gèrent pas correctement
les fichiers issus de Windows Personnellement je suis sous Windows,
et les deux autres développeurs sous Mac. Avec de bons éditeurs, on
arrive à se débrouiller....
Yop. Dans tous les cas, sous unix, un coup d'expression régulière pour
remplacer les fins de ligne comme il faut, ou un cou pde emacs règle le
problème.
En fait, ça apparaît quand un fichier d'une plateforme est éditée sur
une autre, et modifiée. Le truc qui va le lire va rencontrer deux
méthodes pour marque la fin de ligne (entre CR, LF, CR+LF) et se
planter.
> truc_truc. Juste pour info, le '_' ne passe pas avec Netscape, et est
> d'ailleur interdit dans tout attribut HTML (normalement).
??? C'est bizarre, tu veux dire que <p class="spip_texte"> ne serait
pas conforme HTML ??
Tiens ça expliquerait des choses avec netscape 4.X...
- Netscape 4.x does not allow CLASS or ID attributes to contain
underscore characters ("_".) Underscores are legal in HTML atributes
according to the HTML standards but not according to the CSS standard.
[inclusion de squelettes]
Pour l'instant la seule façon de faire est d'écrire l'include PHP en
passant le contexte à la main, par exemple :
<?php
$contexte['id_rubrique'] = $id_rubrique;
include("machin.php3");
?>
Quand j'essaie de faire ça, je me retrouve avec la valeur de $fond
affichée au niveau de chaque include, en plus de l'include qui
fonctionne pourtant bien.
Je suis sur la dernière version CVS, sur un site qui n'est
malheureusement pas accessible en ligne ...
[je reposte car bizarrement le message précédent a l'air vide.
on dirait un (autre) bug de Mozilla...]
Salut,
> Quand j'essaie de faire ça, je me retrouve avec la valeur de $fond
> affichée au niveau de chaque include, en plus de l'include qui
> fonctionne pourtant bien.
Normal, c'est une indication de debug (hum).
Tu peux la virer au début de inc-public.php3, ligne 10.
> Mêmes symptomes chez moi, avec Mozilla 1.0RC1 sur Windows 2000 ...