[spip-dev] 1.4a5, documents liés aux articles

Dev
1

Salut,

Je suis en train d'installer une version 1.4a5.

Cette version est le début de la gestion des documents associés (pdf, sons, vidéo...). Pour l'instant, ce qui est fait:

- l'interface privée;
- les documents intégrés aux articles -> il manque la boucle pour gérer les documents non intégrés aux articles.
- manque le pseudo-tag <DOC1> pour compléter <IMG1> (la même chose, mais avec les indications de nom, descriptif, taille...).

De plus, c'est un premier jet de l'interface, donc soyez indulgents de ce côté...

Principes généraux:

(1) le but est de pouvoir associer tous types de documents à des articles;

(2) il existe en réalité deux façons de lier des documents à des articles:
- les documents disposant d'une image de prévisualisation peuvent être intégrés directement dans les articles; dans ce cas, <IMG1> contient automatiquement le lien vers le document associé;
- les documents qui ne sont pas intégrés dans les articles (soit pas de vignette de prévisualisation, soit pas d'intégration manuelle dans le corps des articles), qui seront appelés par une boucle spécifique (et aux critères plutôt complets...).

Il y a donc deux endroits pour "ajouter" des documents:
- dans l'édition des articles, quand on a créé une image, celle-ci contient un nouveau lien "associer un document à cette image"; ainsi l'ancien système d'images peut être utilisé comme avant (cependant, les images sont désormais traitées dans la table des "spip_documents"), soit comme preview des documents;
- sous le texte des articles, pour les articles qui n'ont pas forcément de preview.

(3) Sécurité: un fichier "spip_formats.txt" contient la liste des terminaisons autorisées. Seuls de tels fichiers peuvent être envoyés vers le serveur par le formulaire Web. Pour les autres types de fichiers (ou les fichiers trop gros), on peut les installer par FTP dans "/ecrire/upload", et là il n'y a plus de limitation sur les terminaisons. Par ailleurs, les fichiers sont systématiquement renommés (selon la nomenclature habituelle des images dans SPIP). Le webmestre qui a des besoins spécifiques peut ajouter des terminaisons dans "spip_formats.txt" (ou même en supprimer, par exemple s'il ne veut pas de fichiers MP3 sur sa machine).

Je continue là-dessus...

ARNO*

2

Suite de l'intégration des documents liés.

- Si on attribue une image de prévisualisation à un document (ou, plus simplement, si on associe un document à une image d'un article), cette image est considérée comme une image "normale", mais avec un lien supplémentaire.

- Ainsi, le comportement des raccourcis "<IMG1|left>"... change automatiquement si on lié un document à une image. Le lien vers le document est créé.

- Introduction d'un nouveau raccourci, qui s'utilise exactement comme <IMGx>: <DOCx> (c'est-à-dire <DOC1|left> et compagnie). Dans ce cas, l'affichage est plus complet, avec le cas échéant le titre et le descriptif du document, le type de document (PDF, GIF, WAV, etc.), la taille du fichier (en ko), la largeur et la hauteur si c'est un fichier image.

Au fait, petit truc: on peut indiquer un titre et un descriptif, sans pour autant réellement associer un document à une image. De cette façon, on peut avec <DOCx> afficher un titre et un descriptif pour toutes les images du document. Ca pourra être pratique pour certains...

Bon, j'attaque l'intégration de la boucle qui va bien...

ARNO*

3

Salut,

Le langage de boucle inclus désormais les boucles de type (DOCUMENTS).

Le critère principal de sélection {id_article}, puisque les documents sont liés à des articles.
Critère important: {inclus=non} ne récupère que les documents qui ne sont pas déjà affichés à l'intérieur de l'article. Vous pouvez aussi faire {inclus=oui} pour afficher uniquement les documents déjà affichés par l'article (hum...).

J'ai pas trop essayé, mais à priori on peut travailler sur tous les critères de la table:
- {titre}, le titre du document (tiens: pratique pour ceux qui voudraient créer des "logos" supplémentaires pour leurs articles, en utilisant par exemple systématiquement un titre du genre "grand_logo", et ensuite utiliser un critère de documents {titre=grand_logo})
- {descriptif}
- {inclus} (oui/non)
- {numero_document} (l'ordre des documents ajoutés au fur et à mesure; à priori aucun intérêt) - oups, j'y pense, j'ai peut-être un bug à vérifier de ce côté...)
- {type} le type de fichier (gif, jpg, pdf...) sans doute un critère intéressant à utiliser...

Peut-être aussi travailler sur la taille des vignettes ou du document:
- {largeur_preview}
- {hauteur_preview}
- {largeur_doc}
- {hauteur_doc}

Surtout, les pseudo tags associés:
#ID_DOCUMENT
#ID_ARTICLE
#TITRE
#DESCRIPTIF
#TYPE
#FICHIER_DOCUMENT
#LARGEUR_DOCUMENT
#HAUTEUR_DOCUMENT
#TAILLE_DOCUMENT

Notez bien: il manque encore le tag pour afficher automatiquement la vignette. Je suppose que ce sera #LOGO_DOCUMENT, avec lien automatique vers le document.

ARNO*

4

Salut,

Dans les boucles (DOCUMENTS), introduction d'un #LOGO_DOCUMENT. Utilisation logique avec [(#LOGO_DOCUMENT|#URL_DOCUMENT)].

Notez bien: ça s'appelle un "logo" uniquement par simplification mnémotechnique; ici cela fonctionne totalement différemment, puisqu'il n'y a pas de survol, que l'image n'a pas le même type de nom que les autres fichiers, et que ça pointe vers un fichier au format loufoque (PDF, Flash, etc.).

J'ai un peu hésité avant d'appeler ça "#LOGO_DOCUMENT", mais c'est vraiment ce qui me semble le plus simple à mémoriser par les webmestres.

Pour l'exemple, c'est intégré dans "article-dist.html". Evidemment, ceux que ça intéresse peuvent largement démultiplier les possibilités des documents liés.

ARNO*

5

Génial, la gestion de documents joints/liés/attachés. L'intrerface est
nickel.

Quelques détails (je n'ai pas encore tout testé, mais bon) :

* le poids du document est censé etre en ko, mais chez moi ça affiche le nb
d'octets. Par ailleurs, si on dépasse 1 Mo, ce serait mieux d'afficher 2.34
Mo que 2346 ko (avec 1 ou deux chiffres après la virgule maxi).

* La partie "ou sélectionner un fichier" n'est pas du tout explicite,
d'autant qu'au début le seul fichier sélectionnable est "remove.txt" (penser
à ne jamais le proposer)

* Pour l'image de prévisualisation, serait pas mal qu'on soit pas obligé de
la télécharger si jamais on veut juste un truc "standard" (disons, par
exemple, le fichier IMG/pdf.png pour les documents pdf, mp2.png pour les mp3
etc.) Ca éviterait d'avoir sur le site n copies du fichier servant à faire
le lien, n copies à modifier si on change le look du site.

* La manière dont on peut modifier l'image sans effacer le document n'est
pas claire (il faut aller dans "Modifier le document lié à cette image")

* l'interface avec les petits tirets est du plus bel effet. Quand spip se
dirigera vers une interface moins iconisée et plus "texte", ce genre de
trucs me plairait.

C'est tout pour l'instant !

-- Fil

6

* La manière dont on peut modifier l'image sans effacer le document n'est
pas claire (il faut aller dans "Modifier le document lié à cette image")

Tous comptes faits, il suffira de changer cette phrase en "Modifier
cette image et le document lié".

* Petit bug de présentation : la colonne de gauche est en largeur 180
pixels, et l'image est redimensionnée à 190... alors que ça devrait être 170
maxi.

-- Fil

7

Hello,

Notez bien: ça s'appelle un "logo" uniquement par simplification
mnémotechnique; ici cela fonctionne totalement différemment,
puisqu'il n'y a pas de survol, que l'image n'a pas le même type de nom
que les autres fichiers, et que ça pointe vers un fichier au
format loufoque (PDF, Flash, etc.).

Bon, tu vois bien qu'il y a au minimum un problème d'organisation.
Je résume la situation actuelle... On ne peut pas fournir de version
1.3 stable parce qu'on n'a pas eu le temps de recueillir les bugs
(et personne n'a envie de se farcir le maintien de la cohérence de
correction de bugs entre deux versions différentes dont une fluctuante,
le tout à la main). On en vient à conseiller aux gens de la liste SPIP
de récupérer une beta absolument instable afin de corriger les bugs
qui les ennuient, ce qui est un comble.

Il y a un certain nombre de bugs à corriger (au moins ceux qui sont
dans le TODO, dont au moins un est lié aux nouvelles fonctionnalités),
et un certain nombre de modifs conséquentes à faire pour que SPIP soit
plus stable (bugs), plus compatible (authentification), plus propre
(code de l'espace privé) voire plus utilisable (multi-bases ?
internationalisation ?). A peu près tout le monde est d'accord que
c'est la priorité actuellement.

Or, à part moi, personne ne prend le courage de résoudre ce genre de
problèmes (sous différents prétextes). Dans ces conditions, et étant
donné que je dois me taper un diff manuel de tous les sources à chaque
fois qu'il y a une modif, il faut bien faire une temporisation dans
les nouvelles fonctionnalités. Donc, à voir avec les autres, mais les
modifs citées plus haut (qui sont par ailleurs intéressantes) ne me
semblent vraiment pas recevables pour l'instant. A priori, ça devrait
être la même chose pour le formulaire "écrire à un auteur", sauf si
c'est suffisamment localisé pour que les éventuels bugs ne fassent
chier que ceux qui utilisent le formulaire.

Bien sûr, si quelqu'un connaissant très bien SPIP et suffisamment exigeant
(j'insiste :-)) sur la qualité du code veut bien se taper le boulot
de relecture, ça fera d'autant moins de blocages et de lenteurs. Comme
j'ai l'impression désagréable d'être la seule personne à connaître à peu
près tous les recoins de SPIP, j'ai peur qu'un tel souhait reste lettre
morte. Evidemment, on ne peut pas encourager des personnes extérieures
à nous trois à étudier à fond SPIP si cela ne leur donne pas la possibilité
de contribuer facilement au code ;)) (d'où les rumeurs de SSII fourchettant
à donf des méga-projets spip-killers)

Un petit truc en passant pour la suite : le "formats.txt" serait mieux
dans un champ de la table spip_meta, ce qui permet de le modifier dans
la configuration précise (pas de façon très graphique forcément, mais
c'est déjà ça de pouvoir ajouter ou enlever une extension séparée des
autres par un espace). Ou, si on veut ajouter des fonctionnalités plus
riches (du genre pouvoir forcer le mime-type, attribuer un nom au type
de document, voire un descriptif servant à aider au téléchargement
(pour lire un fichier quicktime, vous devez télécharger blabla)), dans
une table séparée.

a+

Antoine.

PS : désolé de mettre le message en "priorité haute", mais c'est pour
m'assurer que tout le monde le lira bien.

8

@ Antoine Pitrou <antoine@rezo.net> :

Moratoire modifs ?

Pas nécessaire à mon avis. Les bugs signalés ne sont pas si nombreux que ça,
principalement des histoires de mail, qui concernent probablement inc_mail,
qui n'est pas affectée par les modifs actuelles.

Pour le reste (déchets dans la base, correction dans la recherche, etc.) ce
n'est pas si capital qu'il faut que ça figure dans la 1.3 débugguée (1.3.2
si vous voulez...)

Or, à part moi, personne ne prend le courage de résoudre ce genre de
problèmes (sous différents prétextes).

T'es le meilleur ! Mais de temps en temps je me cogne un bug report, tu es
dur là quand même...

être la même chose pour le formulaire "écrire à un auteur", sauf si
c'est suffisamment localisé pour que les éventuels bugs ne fassent
chier que ceux qui utilisent le formulaire.

Parfaitement localisé (une fonction dans inc-formulaires.php3)

désolé de mettre le message en "priorité haute", mais c'est pour
m'assurer que tout le monde le lira bien.

Arf.

On est en phase de transition. En général dans ces phases-là il ne sert à
rien de tenter de bloquer les vagues, il faut plutôt manoeuvrer le
gouvernail. Donc prendre des décisions pour mieux s'organiser.

Bises

-- Fil

9

On est en phase de transition. En général dans ces phases-là il ne sert
à rien de tenter de bloquer les vagues, il faut plutôt manoeuvrer le
gouvernail. Donc prendre des décisions pour mieux s'organiser.

Et "Légiférer sur la cryptographie, c'est chercher à capturer le vent",
la phrase la plus idiote de l'année ((c) pplf). Bon, mais pour prendre des
décisions, il faut forcer la discussion. Et pour forcer la discussion, rien
de mieux que de geler les modifs. A moins que tu aies une autre solution.

Enfin, à défaut, je préviens que je n'aurai aucun scrupule à écraser des
modifs en cours, et que les miennes seront toujours prioritaires (puisque
les autres développeurs ne veulent pas considérer une organisation plus
rationnelle, c'est à eux d'en faire les frais).

a+

10

@ Antoine Pitrou <antoine@rezo.net> :

(puisque les autres développeurs ne veulent pas considérer une
organisation plus rationnelle, c'est à eux d'en faire les frais).

Merci bien ! Pourquoi crois-tu que je vais ce soir me former à cvs ??

-- Fil

11

Merci bien ! Pourquoi crois-tu que je vais ce soir me former à cvs ??

Je ne parle pas seulement de CVS. Je parle de savoir reconnaître et
gérer les priorités.

12

Olé,

Quelques détails (je n'ai pas encore tout testé, mais bon) :
* le poids du document est censé etre en ko, mais chez moi ça affiche le nb
d'octets. Par ailleurs, si on dépasse 1 Mo, ce serait mieux d'afficher 2.34
Mo que 2346 ko (avec 1 ou deux chiffres après la virgule maxi).

Peut-être plus "souplement" faire un filtre pour cela ?

if ($volume < 1024) {
  return $volume . " octets";
} elseif ($volume < 1024*1024 ) {
  return $volume/1024 . " kO";
} else if ($volume < 1024*1024*1024 ) {
  return $volume/(1024*1024) . " Mo";
} ...

enfin un truc dans le genre qui permettrait d'avoir un affichage joli
quand on en a envie (avec un |joli_volume ou qqchose comme ça) mais
aussi de pouvoir afficher brutalement le volume en octet...

(oui je sais c'est super con, mais c'était juste un mail pour parler
d'autre chose que de CVS... :wink:

a+

13

Beni soit ARNO*

14

Salut,

Modifs sur:

article-dist.html
ecrire/articles.php3
ecrire/document_edit.php3
ecrire/inc_texte.php3
ecrire/articles_edit.php3
ecrire/IMG2/document-vierge.gif

-> Un petit logo unique pour tous les types de documents, le script ajoute tout seul la mention du type de document. De cette façon, le document est mieux signalé, et ça ressemble aux petits logos de nos systèmes. Je peux faire le même truc dans les squelettes standards, ça devrait même être assez mignon...

-> Fonction "taille_en_octets()" dans inc_texte, utilisée dans l'espace privé, et que l'on peut utiliser dans les squelettes (c'est fait dans article-dist.html). On lui passe la valeur "brute" en octets, et ça complète avec la mention "octets", "ko" ou "Mo" en fonction de la valeur (inférieur à 1024, inférieur à 1024x1024...). Arrondi à un chiffre après la virgule.

ARNO*

15

@ Arno* <arno@scarabee.com> :

-> Un petit logo unique pour tous les types de documents, le script
ajoute tout seul la mention du type de document. De cette façon, le
document est mieux signalé, et ça ressemble aux petits logos de nos
systèmes. Je peux faire le même truc dans les squelettes standards,
ça devrait même être assez mignon...

C'est assez mignon !

Un remarque maintenant : serait-il pas plus cool de subdiviser le
répertoire IMG/ en sous-sections

IMG/mp3/ IMG/pdf/ IMG/doc/

etc. ? Là ça commence à être le bordel, tout est en vrac.

Un détail : on devrait aussi installer un fichier IMG/index.php3 par défaut,
qui jetterait le visiteur curieux. Pas d'objections ? (Je l'installe dans
le dev, supprimez-le si ça vous ennuie)

PS: j'installe tout de suite les docs attachés sur www.labassijysuis.org :
les sons de 2.5 Mo ont du mal à passer en http, mais un fichier de 1 Mo
passe sans souci [sur ma config]

-- Fil

16

Un bug : quand je fais "ajouter un document à cet article" depuis la page
ecrire/articles.php3 (et pas articles_edit.php3) ça me crée deux liens sur
le même document.

-- Fil

17

Un autre souci : logo par défaut s'il n'y a pas de #LOGO_DOCUMENT, comment
faire ? Dans la syntaxe même de spip il n'y a pas de possibilité alternative
dans une construction comme [(#LOGO_DOCUMENT)]

Evidemment je vais faire un échappement php, mais on pourrait peut-être
faire un truc équivalent aux LOGO_ARTICLE_RUBRIQUE, en proposant
LOGO_DOCUMENT_TYPE, qui met le document standard du type s'il n'y a pas de
logo-document. ???

-- Fil

18

Salut,

Je suis en train de regarder la dernière version.

Petites remarques :

- je me rends compte que je me tape du pseudo-CVS dépatouillé à la main
à chaque fois, c'est assez pénible.

- la nouvelle gestion des forums publics est bâclée, il faut la virer.
La première chose à faire serait de rationaliser la gestion des
formulaires publics. D'autre part, il ne faut pas passer de caractéristiques
de présentation dans l'URL (afficher_groupes).

- le index.php3 dans IMG, je ne vois pas l'intérêt, à moins de la jouer
sécuritaire, mais c'est le choix du webmestre. Je ne vois pas pourquoi
SPIP devrait préconiser une telle fermeture. De mon temps....

- les documents devraient être l'occasion de virer les anciennes contraintes
bizarroïdes, et les globals foireux dans propre() (heu, traiter_raccourcis)

- Fil a raison : l'administration restreinte n'est testée qu'une fois sur deux

- Eventuellement hasher le IMG ? Par type (plus lisible) ou par md5 (plus
efficace) ?

a+

19

- la nouvelle gestion des forums publics est bâclée, il faut la virer.
La première chose à faire serait de rationaliser la gestion des
formulaires publics.

"Bâclée", non; mal programmée, je veux bien. :slight_smile:
Bien d'accord pour revoir ça.

D'autre part, il ne faut pas passer de caractéristiques
de présentation dans l'URL (afficher_groupes).

Là je ne sais pas.
Je vois bien que c'est inégant, mais d'un autre côté:
- ça ne pose pas de problème de sécurité, et de toute façon si on attaque avec des "afficher_groupes", c'est qu'on maîtrise l'interface graphique de son site; ça n'est pas plus gênant que le fait de faire passer "id_parent=25" dans l'URL (il suffit de supprimer ce id_parent=25 pour obtenir des incohérences dans la base, mais corrigées par le fait qu'aucun squelette ne les exploite).
- SURTOUT: pour générer les "afficher_groupes", il faut essentiellement passer par PHP (parce que si on a besoin de telles restrictions, c'est qu'on bidouille des conditions assez spéciales, impossibles à réaliser avec les squelettes). Or, la passage de ces valeurs dans l'URL est le seul moyen d'imposer quelque chose tiré de PHP à l'interface de SPIP.

Par exemple, une solution serait de passer des variables-filtres à #FORMULAIRE_FORUM, genre:
[(#FORMULAIRE_FORUM|groupe=5|groupe=3)]
Mais du coup, impossible de générer ça via PHP. Et on perd tout l'intérêt de la manoeuvre.

Mais s'il y a une solution plus élégante, qui conserve cela, je suis preneur, hein. :slight_smile:

- le index.php3 dans IMG, je ne vois pas l'intérêt, à moins de la jouer
sécuritaire, mais c'est le choix du webmestre. Je ne vois pas pourquoi
SPIP devrait préconiser une telle fermeture. De mon temps....

D'accord.

- les documents devraient être l'occasion de virer les anciennes contraintes
bizarroïdes,

De quoi s'agit-il?

et les globals foireux dans propre() (heu, traiter_raccourcis)

Yop. Je préférais énormément la version précédente (genre passer "$espace_logos" dans le fichier d'appel "article.php3" par exemple), mais pb de sécurité. S'il y a moyen de trouver une méthode qui concilie la sécurité et la souplesse, c'est tout bon...

- Fil a raison : l'administration restreinte n'est testée qu'une fois sur deux

Elle est testée sur les éléments vitaux du site, mais effectivement elle doit être étendue.

- Eventuellement hasher le IMG ? Par type (plus lisible) ou par md5 (plus
efficace) ?

Euh, je préférerais qu'on se contente de découper en sous-dossiers par type. A mon avis, c'est important pour comprendre son propre site de savoir qu'on appelle des documents aux noms identifiables plutôt que des machins aux titres abscons ("hLkjhHdkDSTZIuhk24.pdf" :-)).

ARNO*

20

Eventuellement hasher le IMG ? Par type (plus lisible) ou par md5
(plus efficace) ?

Pourquoi continuer à l'appeler IMG d'ailleurs ? Par soucis de
compatibilité je suppose ... dommage. Un DOCS ferait mieux l'affaire.

Eventuellement, un découpage en sous-dossiers par article (si cela est
possible, comme dans le cache) serait un plus, plutôt que par type de
fichier, et permettrais dans 99,99% des cas de conserver les noms de
fichiers.

Nicolas.