[spip-dev] Documentation pour 1.4

Salut,

J'ai inséré dans le manuel de référence les éléments concernant la version 1.4 (c'est signalé par la mention explicite [SPIP 1.4]). De plus, il y a carrément deux nouveaux articles dans le manuel de référence:

- La boucle DOCUMENTS
http://www.uzine.net/article1823.html

- Les variables de personnalisation
http://www.uzine.net/article1825.html

Evidemment, lors de la sortie officielle de la version 1.4, il y aura un grand article récapitulant toutes les nouveautés, ce qui facilitera la consultation du Manuel de référence...

De plus, je prévois au moins deux petits tutoriaux: un pour l'utilisation des documents (notamment l'utilisation à peine détournée pour gérer des logos supplémentaires; par exemple, sur uZine, il y a un grand logo sur la page d'accueil pour le dernier article publié, et c'est géré par un document associé à l'article, et non en détournant le logo de survol comme on faisait souvent), et un pour l'utilisation des mots-clés dans les forums publics (par exemple, choix d'une icone pour signer son article, ou choix d'un thème pour son message, ou encore système de "notation" comme il y a dans la doc de SPIP).

ARNO*

Salut,

Pour moi, ça m'a l'air bon. Je suis donc partisan (comme Fil), de passer officiellement en RC1 et de lancer la dernière phase de beta-test. Ce qui nous permettrait de sortir la 1.4 pour la rentrée.

ARNO*

Pour moi, ça m'a l'air bon. Je suis donc partisan (comme Fil), de
passer officiellement en RC1 et de lancer la dernière phase de
beta-test.

Euh, je croyais qu'on ne disait pas RC1 (release candidate) mais PR1 :
version PRéalable :wink:

Sinon, je pense qu'il faudra tout de même vérifier le nouveau système de
connexion sous php3, antoine avait des doutes ; simplifier encore le texte
qui apparaît dans les "alertes de connexion" : incompréhensible, on va avoir
des tonnes de mails sur la liste ; améliorer un peu le texte "votre
identifiant" (qui parfois parle de "vos identifiants")... ; revoir l'aide en
ligne.

Mais ce ne sont que des dpetits détails textuels, les plus difficiles à
trouver car on ne les lit plus, ces textes, et si on les lit c'est sans
forcément penser à celui qui "débarque" dans l'interface.

Quelqu'un a suggéré qu'on mette des docs dans les brèves ; évidemment, si on
surcharge la brève, ce n'est plus une brève, donc je suis contre ; mais du
coup je me dis qu'on peut mieux séparer articles/brèves en faisant que les
visiteurs du site public, soit sur enregistrement public (façon "forums sur
abo) soit, a fortiori, sur enregistrement privé, soit de manière totalement
ouverte (réglage admin), puissent proposer une brève depuis l'espace public
(il faudrait un tag #PROPOSER_BREVE ; réglage par défaut "tout le monde peut
proposer une brève depuis l'espace public" ; réglage en cas d'upgrade, le
contraire (ne pas changer les règles du jeu en cours de route).. c'est une
idée comme ça... :wink:

-- Fil

[...]

Mais ce ne sont que des dpetits détails textuels, les plus difficiles à
trouver car on ne les lit plus, ces textes, et si on les lit c'est sans
forcément penser à celui qui "débarque" dans l'interface.

Quelqu'un a suggéré qu'on mette des docs dans les brèves ; évidemment, si on
surcharge la brève, ce n'est plus une brève, donc je suis contre ; mais du
coup je me dis qu'on peut mieux séparer articles/brèves en faisant que les
visiteurs du site public, soit sur enregistrement public (façon "forums sur
abo) soit, a fortiori, sur enregistrement privé, soit de manière totalement
ouverte (réglage admin), puissent proposer une brève depuis l'espace public

C'est vrai que ce serait une bonne chose ce proposer une brève. Pour les
brèves (non je n'ai pas besoin de document attaché) ce qui manque je trouve
c'est de pouvoir les attacher aux rubriques plutôt qu'aux secteurs. Je ne
vois pas pourquoi le choix de "secteur" a été fait initialement mais je suis
sûr qu'il y a une raison, non?

C'est toujours la même logique: les brèves ne sont pas des articles, et tout est fait pour éviter à tout prix qu'elles ne soient utilisées en concurrence des articles. Donc interface et gestion simplifiées et radicalement différentes de celles des articles.

Grouper les brèves en secteurs et non en rubriques, c'est justement ce qui permet la facilité de gestion et la très grande différenciation d'avec les articles (voir dans l'espace privé d'uZine, c'est assez évident):

- d'abord, parce que la logique du "secteur", c'est celle d'un grand thème; donc, dans le soucis de simplicité, on ne se pose pas de questions finaudes pour savoir où installer une brève: c'est selon le grand thème d'un secteur; y'a qu'à voir la tronche du menu déroulant "dans la rubrique" des articles (dans uZine, doit y'avoir dans la bonne grosse centaine d'entrées...) et dans les brèves (6 entrées pour le même site!);

- les brèves peuvent être présentées sur une page récapitulative unique, selon leur "secteur"; d'où grande simplicité d'emploi: page facile à lire, toute l'info en un lieu unique (ça n'est pas du tout le cas des articles), et pour poster une nouvelle brève au bon endroit, il suffit sur cette page unique de cliquer sur le bon bouton;

- toujours dans le souci de simplicité, cela concerne la gestion du site public et des boucles; la structure d'implémentation des brèves est ultra-simple, et pour l'interface graphique y'a pas trop à se fouler (parce que des brèves, y'en a plein ou bien y'en a pas du tout, alors que pour les articles, il faut prévoir une interface qui prenne en compte le cas où y'en a aucun, où y'en a 2, et où y'en a 50).

A l'inverse, si on autorise les brèves dans toutes les rubriques:
- d'abord il n'y a plus aucune différence d'avec les articles au niveau de la logique (ce sont alors des articles avec moins de champs), on peut carrément les sucrer; au passage, d'ailleurs, je signale que généralement, quand on se plein de la "pauvreté" des possibilités des brèves, hé ben on peut tout aussi bien désactiver les brèves dans l'espace privé et utiliser les articles à la place;
- on ne peut plus avoir la page récapitulative unique, vu qu'il faudrait afficher l'intégralité de la structure du site; donc on reviendrait encore à une interface qui est celle des articles;
- dans les squelettes, il faudrait gérer la présence des brèves exactement comme celles des articles, avec la complexité graphique induite; et là encore, autant ne plus se faire chier avec des brèves et travailler directement avec des articles.

ARNO*

Salut,

Nouvel article dans la doc, récapitulant les différents formulaires disponibles pour l'espace public:
http://www.uzine.net/article1827.html

Au passage, modification de #LOGIN_PUBLIC sur le CVS: pour indiquer l'url de destination, il ne faut pas ajouter url=..., sauf à introduire une incohérence avec #FORMULAIRE_RECHERCHE qui, lui, n'utilisait pas cette syntaxe. De toute façon, il est illusoire de vouloir "filtrer" les formulaires, vu qu'ils ont des fonctionnements très différents, archi-complexes, et que ça change d'une version à l'autre de SPIP.

ARNO*

Pour les
brèves (non je n'ai pas besoin de document attaché) ce qui manque je trouve
c'est de pouvoir les attacher aux rubriques plutôt qu'aux secteurs. Je ne
vois pas pourquoi le choix de "secteur" a été fait initialement mais je suis
sûr qu'il y a une raison, non?

C'est toujours la même logique: les brèves ne sont pas des articles,
et tout est fait pour éviter à tout prix qu'elles ne soient utilisées
en concurrence des articles. Donc interface et gestion simplifiées et
radicalement différentes de celles des articles.

Bonjour,

J'ai bien saisi la nuance et les brèves sont chez moi franchement
différenciées des articles: elles sont BREVES (300 signes) et ne concernent
que ce qui n'est pas produit par le groupe (reprise commentée d'informations
de push avec lien vers la source), alors que les articles sont du travail de
production des auteurs du site (2500 à 6000 signes).

Grouper les brèves en secteurs et non en rubriques, c'est justement
ce qui permet la facilité de gestion et la très grande
différenciation d'avec les articles (voir dans l'espace privé
d'uZine, c'est assez évident):

[...]

Je suis d'accord sur une logique de "secteur", le problème serait la
définition du secteur alors: car certaines rubriques sont étoffées et
découlent pourtant logiquement du secteur au dessus: elles ont donc beaucoup
plus d'articles et de brèves spécifiques.

Cette rubrique beaucoup plus grosse que les autres est pour moi un sous
secteur et je ne voudrais pas qu'elle "bouffe" les breves des autres
rubriques du secteur en s'appropriant ainsi l'intégralité de la liste des
dernières brèves du secteur.

A l'inverse, si on autorise les brèves dans toutes les rubriques:

[...]

autant ne plus se faire chier avec des brèves
et travailler directement avec des articles.

:slight_smile:
nan je n'en veux pas pour _toutes_ les rubriques mais pour des GROSSES
rubriques pour faire ensuite:

<BOUCLEe_breves(BREVES){id_rubrique!=grosserubrique}{0,10}>
#TITRE
</BOUCLE_breves>

Salut,

Je continue la doc. Cette fois, la documentation de la balise <INCLURE(fichier.php3)>:
http://www.uzine.net/article1828.html

Au passage, je sucre l'utilisation des <INCLURE(hierarchie)> et <INCLURE(pied)> dans les squelettes standards: effectivement c'était beaucoup plus propre, cependant l'inclusion de fichiers externes est un niveau d'abstraction informatique certes pas fulgurant, mais qui ne figure pas au programme scolaire du webmestre lambda avant le DEUG :slight_smile:
Déjà piger le système des boucles n'est pas évident, mais si en plus on évacue une partie du code dans un autre fichier, là c'est too much ("tiens, je vais voir comment modifier le haut de ma page; euh, il est où le haut de ma page?", voyez le genre). C'est typiquement le genre de chose à limiter aux ceusses qui savent.

ARNO*

Modif sur le CVS, inc-presentation. J'ai modifié les messages d'alerte et les infos de sécurité, pour les rendre plus simples, moins gavants, moins alarmistes, et j'espère plus explicites (mis en avant connexions avec plusieurs butineurs, vu que "plusieurs machines", c'est pas tout le monde; sucré "je fais une démo de SPIP", ah ah!; sucré les fournisseurs instables, simplement "si ça déconne passez en mode normal").

ARNO*

Fil wrote:

Pour moi, ça m'a l'air bon. Je suis donc partisan (comme Fil), de
passer officiellement en RC1 et de lancer la dernière phase de
beta-test.

Euh, je croyais qu'on ne disait pas RC1 (release candidate) mais PR1 :
version PRéalable :wink:

Ben, vue la tonne de modifs récentes sur le CVS, je préférerais qu'on
attende un peu (genre une semaine)....

Note : pour les inclusions dans les squelettes standard, je suis
farouchement pour. Premièrement, ça nous fait moins chier, nous,
quand il s'agit de modifier ces squelettes. Deuxièmement, ça habitue
les gens à une fonctionnalités qui est tout de même rudement pratique.
Troisièmement, pour personnaliser un peu ces squelettes, c'est beaucoup
plus simple d'aller taper dans pied.html que dans le fond de chaque
squelette.

Sinon, les alertes de sécurité, c'est vrai que j'en ai des tas en
ce moment, et c'est chiant.... On devrait les virer en mode "sécu
normale", elles n'apportent rien.

a+

Antoine.

OK.
Et pour les doutes sur l'identification en PHP3?

Heu, a priori, rien, sauf le bidule bizarre chez Free.

A propos de Free, j'ai découvert que PHP4 est beaucoup plus
rapide, chez eux, que PHP3.. Ca veut dire que quand on renomme
les fichiers en .php, SPIP devient utilisable chez Free :wink:
C'est facile au moins pour l'espace public, avec le inc-urls :
on peut fournir un lot de quelques fichiers dans contrib/,
et c'est valable pour toutes les versions.

Dans ce cas, uniquement pour pied.php3, parce qu'il n'y a pas de boucle, et que donc ça peut introduire le principe "en douceur". En revanche, pas l'appel de hiérarchie.php3, bicoz y'a l'appel à des boucles à l'extérieur avec le passage d'une variable, c'est vraiment un niveau d'abstraction propre aux informaticiens, totalement étranger aux webmestres.

Dans ce cas on peut ajouter un commentaire renvoyant vers l'article
que tu viens d'ajouter à la doc. Je pense qu'il est bon d'habituer
les webmestres à utiliser ce genre de trucs.

Accessoirement, les squelettes par défaut n'ont jamais été vraiment
simples... La hiérarchie, justement, c'est un paquet de boucles
que même un spipien expérimenté a un peu de mal à lire. Si tu les
mets dans un fichier à part, le reste devient plus lisible.

a+

Antoine.

A propos de Free, j'ai découvert que PHP4 est beaucoup

plus

rapide, chez eux, que PHP3.. Ca veut dire que quand on

renomme

les fichiers en .php, SPIP devient utilisable chez Free :wink:

La solution est d'employer un fichier .htaccess et d'y
mettre une ligne :

AddType application/x-httpd-php .php3

C'est ce que l'on conseille sur Ouvaton pour que spip puisse
fonctionner en php4 avec les extentions .php3.

JM Malsacre
Administrateur Ouvaton.

L'hébergement .coop