Plugin Modèles media

Pour les versions de SPIP antérieures à la version 3.3, les modèles <doc>, <img> et <emb> produisent chacun un résultat différent et ce résultat, pour les images, dépend du fait qu’elle soit dans le portfolio ou non.

Ce plugin propose une nouvelle série de modèles ayant un comportement unifié et indépendant du mode des images. Les modèles existants (doc, emb, img) ne sont pas modifiés afin d’assurer la rétrocompatibilité.

Installation

Les modèles <media> nécessitent que le plugin Médiathèque soit installé et activé.

Le plugin Insérer Modèles n’est pas obligatoire mais fortement recommandé afin de fournir une aide aux rédacteurs pour l’insertion des modèles <media>.

Avertissement

La version 3.3 de SPIP a résolu la grande partie des problèmes auquel ce modèle répondaient. Le plugin est toutefois compatible 3.3 pour les raisons suivantes :
-  permettre de ne pas avoir à migrer ses modèles ;
-  continuer à disposer de certaines options non encore présente dans les modèles de SPIP.

Syntaxe générale

Syntaxe des modèles <media>
Syntaxe des modèles <media>

Trois variantes principales

Les modèles <media> reposent sur trois variantes principales : icone, vignette et embed.

<media12|icone> affichera l’icône représentant le type de document.

<media12|vignette> affichera une vignette du document. Il s’agira dans l’ordre :

  1. de la vignette personnalisée associée au document si elle existe.
  2. d’une vignette générée automatiquement à partir du document. La vignette générée est indépendante de la configuration de SPIP (que l’on ait activé ou non les vignettes automatiques dans Configuration > Fonctions avancées). Enfin, la taille de la vignette n’est pas déterminée par le paramètre de SPIP concernant les vignettes automatiques mais par le paramètre |taille transmis au modèle (voir ci-après).
  3. de l’icône du type de fichier si aucune vignette personnalisée n’est disponible et si aucune fonction de génération automatique de vignette n’est disponible pour ce type de fichier.

<media12|embed> permet d’incruster le document, l’incrustation étant fonction du type du document.

Depuis la vesion 1.2.0, on peut utiliser <media12|insert>, équivalent à <media12|embed> [1].

Alignement

L’alignement se précise comme actuellement avec |left, |center et |right.

Exemple : <media12|icone|right>

Afficher une légende

En l’absence de paramètres spécifiques, aucune légende n’est affichée.

Pour afficher une légende simple (titre + descriptif), on ajoutera simplement |legende au modèle. Par exemple : <media12|vignette|legende>.

Si l’on souhaite une légende complète (titre + descriptif + crédits + type de document + poids en octets), on indiquera |legende=complete. Par exemple : <media12|vignette|legende=complete>.

Il est également possible d’indiquer plus précisément les éléments qui devront composer la légende. Au lieu du paramètre |legende, on aura alors recours aux paramètres |titre, |descriptif, |credits, |type et |poids. Par exemple, si on souhaite afficher uniquement le titre et les crédits on fera : <media12|icone|titre|credits>. Pour afficher seulement le type de document et son poids : <media12|icone|type|poids>.

Il est possible de personnaliser le titre, le descriptif et les crédits à afficher pour utiliser d’autres valeurs que celles associées au document (utile par exemple sur un site multilingue). On précisera alors simplement à ces trois paramètres les valeurs à prendre. Par exemple :

<media12|icone
    |titre=Un autre titre
    |descriptif=Un autre descriptif avec du {{gras}}, de l'{italique} et même une note[[de bas de page]].
    |credits=d'autres crédits>

On peut utilise les deux formes d’écritures. Pour afficher le titre du document, des crédits personnalisés et le poids du document : <media12|icone|titre|credits=autres crédits|poids>. Si on souhaite afficher la légende complète en personnalisant juste le titre : <media12|icone|legende=complete|titre=Mon autre titre>.

Ajouter un lien

Pour les variantes icone et vignette, un lien pointant sur le document sera ajouté par défaut. Pour la variante embed, en l’absence de paramètre lien, aucun lien ne sera ajouté au média.

Pour que le média pointe sur lui-même, on ajoutera simplement |lien. Il est possible de préciser un lien spécifique, par exemple <media12|icone|lien=http://www.monsite.net>. On peut utiliser les raccourcis SPIP pour les liens internes. Par exemple, pour pointer sur la rubrique 3 : <media12|icone|lien=rub3>.

Il est également possible d’utiliser la syntaxe suivante [<media12|icone>->rub3].

L’attribut title du lien est déterminé automatiquement par SPIP en fonction du lien. Cependant, il est possible de spécifier explicitement l’attribut title avec le paramètre |titre_lien. Par exemple : <media12|icone|lien=http://www.monsite.net|titre_lien=Un super site à visiter>.

Spécifier la taille

En l’absence de paramètres spécifiques, la taille du document sera utilisée (modifiable selon le type de fichier), notamment pour les vignettes.

Les modèles <media> proposent 4 tailles standards : icone, petit, moyen et grand. Ces quatre tailles peuvent être personnalisées dans la Configuration de SPIP, sous l’onglet Fonctions avancées.

On spécifiera la taille souhaitée en utilisant le paramètre |taille, par exemple : <media12|vignette|taille=petit>. Il est également possible de spécifier une taille précise en pixels de la manière suivante : <media12|vignette|taille=150>.

Les médias sont redimensionnés en respectant le ratio hauteur/largeur. Ainsi, |taille=150 redimensionnera le média de telle manière que son plus grand côté soit égal à 150 pixels.

Si on souhaite simplement spécifier une hauteur maximum de 150 pixels, on utilisera |hauteur=150. Pour une largeur maximum de 300 pixels, |largeur=300. On peut utiliser les deux paramètres en même temps : <media12|vignette|hauteur=150|largeur=300>.

Personnaliser le texte alternatif

Il est possible de personnaliser le texte alternatif ajouté aux images et autres médias avec le paramètre |alt. Par exemple : <media12|icone|alt=Texte alternatif sur l'icône>.

Cas du modèle appelé sans variante

Il peut arriver que le modèle soit appelé sans spécifier de variante (exemple : <media12>).

Le modèle n’est pas censé être appelé sans variante. Si cela arrive, la variante vignette sera utilisée. Mais cela n’est pas recommandé.

Aide à l’insertion des modèles

Afin de faciliter l’insertion des nouveaux modèles, ce plugin fournit un formulaire d’insertion utilisable avec le plugin Insérer Modèles. Si celui-ci est actif, alors une aide à l’insertion des modèles media sera disponible dans le porte-plume.

Plugins étendant les modèles media

Footnotes

updated on 18 February 2021

Discussion

49 discussions

  • 2

    Ajout d’une classe : afin de mettre en forme différemment plusieurs types d’image, je me demandais si il était possible de passer en paramètres un identifiant de classe (au sens css du terme). J’ai ainsi fait un essai en écrivant : <mediaxxx|embed|border> en espérant qu’il ressorte du chapeau une balise img qui serait dotée d’un attribut classs=border ! Hélas, cela ne fonctionne pas...
    Y a-t-il une façon de faire pour pouvoir attribuer une class css aux éléments concernés par les modèles média ?
    Merci d’avance

    • Et en écrivant explicitement <mediaxxx|embed|class=border>.

      En effet, dès lors que l’on utilise des variantes, class n’est pas automatiquement attribué :

      Leur syntaxe a été étendue, et il est possible de spécifier, outre l’alignement (<img1|left>, <img1|right> ou <img1|center>), une classe plus générique, qui soit correspond à un squelette précis, s’il existe, soit à une classe CSS (<img1|classe> ira chercher le modele modeles/img_classe.html, si ce fichier existe, sinon utilisera le modèle modeles/img.html, mais avec un paramètre class="classe").

      Source : http://www.spip.net/fr_article3454.html

    • C’était pourtant élémentaire mon cher Watson...
      Merci de la réponse et... quelle rapidité !

    Reply to this message

  • 12

    Salut Joseph,

    Je suis souvent confronté à la situation suivante: vouloir mettre un lien vers un document dans un article, mais [->docXXX] (qui affiche automagiquement le titre) ne suffit pas, car parfois je veux aussi mettre dans le texte du lien la taille, le type de fichier ou les crédits. Et là c’est casse pied, il faut tout récrire alors que c’est renseigné dans les infos du document.

    J’ai donc rajouté un “modèle media” que j’ai appelé <mediaXXX|liensimple> (donc dans un fichier modeles/media_liensimple.html) dont je te livre le code ci-dessous.

    Crois-tu qu’il serait judicieux de l’ajouter au plugin ?

    [(#REM)
     
    	Affiche juste un lien textuel comparable à ce que ferait ->docXXX mais avec la
    	possibilité de choisir le contenu du texte du lien en suivant la nomenclature
    	du plugin Modèle média: http://contrib.spip.net/Plugin-Modeles-media
     
    	on l'appelle sous la forme <mediaXXX|liensimple|autres params>
     
    ]
    #SET{legende,#ENV{class}|=={legende}|?{legende,#ENV{legende}}}
    #SET{lien,#ENV{class}|=={lien}|?{lien,#ENV{lien}}}
    #SET{titre,#ENV{class}|=={titre}|?{titre,#ENV{titre}}}
    #SET{descriptif,#ENV{class}|=={descriptif}|?{descriptif,#ENV{descriptif}}}
    #SET{credits,#ENV{class}|=={credits}|?{credits,#ENV{credits}}}
    #SET{type,#ENV{class}|=={type}|?{type,#ENV{type}}}
    #SET{poids,#ENV{class}|=={poids}|?{poids,#ENV{poids}}}
     
    [(#REM) Le cas échéant, il faut donc vider la variable class.]
    #SET{class,#ENV{class}}
    #SET{class,#ENV{class}|=={legende}|?{'',#GET{class}}}
    #SET{class,#ENV{class}|=={lien}|?{'',#GET{class}}}
    #SET{class,#ENV{class}|=={titre}|?{'',#GET{class}}}
    #SET{class,#ENV{class}|=={descriptif}|?{'',#GET{class}}}
    #SET{class,#ENV{class}|=={credits}|?{'',#GET{class}}}
    #SET{class,#ENV{class}|=={type}|?{'',#GET{class}}}
    #SET{class,#ENV{class}|=={poids}|?{'',#GET{class}}}
     
    <BOUCLE_doc (DOCUMENTS) {id_document=#ENV{id}} {tout}>
    <a href="[(#ENV{lien}|sinon{#URL_DOCUMENT})]"[ title="(#TITRE|attribut_html)"] class="[spip_(#DISTANT|=={oui}|?{out,in})][ (#ENV{class})]">#TITRE</a>
    	[(#ENV{legende}|non)
    		[<:par_auteur:> (#ENV{credits}|oui)#CREDITS]
    		[(#ENV{descriptif}|oui)[<br />(#DESCRIPTIF|PtoBR)]<br />]
    		[ (#ENV{type}|oui)#TYPE_DOCUMENT,]
    		[ (#ENV{poids}|oui)[(#TAILLE|taille_en_octets)].]
    	][(#ENV{legende}|oui)
    		[<:par_auteur:> (#CREDITS)]
    		[<br />(#DESCRIPTIF|PtoBR)<br />]
    		[ (#TYPE_DOCUMENT),]
    		[ (#TAILLE|taille_en_octets).]
    	]
    </BOUCLE_doc>

    On peut donc placer dans son texte <mediaXXX|liensimple|poids|type> par exemple...

    • Bonjour Beurt et merci pour ta proposition. Je vois bien le besoin et la demande. Cependant, en y réféchissant ces derniers jours, quelque chose me tracasse.

      D’une part, il me semble qu’un lien devrait pouvoir se gérer via la syntaxe SPIP dédiée. On peut se demander s’il ne faudrait pas l’étendre pour afficher optionnellement le type et le poids d’un doc.

      Par ailleurs, on peut vouloir le type et le poids entre parenthèses après le lien mais pas dans le lien. Ou au contraire dans le lien.

      La syntaxe que tu proposes fait que le modèle renvoie parfois des <br /> et dans un lien ça ne me plait pas.

      De même, s’il faut respecter toute la syntaxe concernant les légendes, on se retrouve aussi avec des éléments non in-line et des retours à la ligne.

      Bref, cette syntaxe ne me parait pas la plus intuitive. Et puis hier, il m’est apparu qu’il y a peut être plus simple en ajoutant les modèles suivants : <mediaXX|titre>, <mediaXX|descriptif>, <mediaXX|credits>, <mediaXX|type> et <mediaXX|poids>. Ces modèles, simples et étant appelé sans autre paramètre, renverrait uniquement l’information demandée. De là on peut faire du coup de ce que l’on veut, par exemple : [->XX] (<mediaXX|type> - <mediaXX|poids>).

      De plus ces modèles seraient tout à fait facile à se souvenir.

      Qu’en penses-tu ?

    • Salut !

      D’une part, il me semble qu’un lien devrait pouvoir se gérer via la syntaxe SPIP dédiée. On peut se demander s’il ne faudrait pas l’étendre pour afficher optionnellement le type et le poids d’un doc.

      Oui, mais ça nécessiterai de déroger à la règle des [->objetXXX] et les exceptions c’est jamais super (compliqué à maintenir, compliqué pour l’utilisateur).

      La syntaxe que tu proposes fait que le modèle renvoie parfois des
      et dans un lien ça ne me plait pas.

      De même, s’il faut respecter toute la syntaxe concernant les légendes, on se retrouve aussi avec des éléments non in-line et des retours à la ligne.

      J’ai essayé de tenir compte de ça: les <br /> sont placés en dehors du <a href="...">...</a> et j’ai choisi d’utiliser le filtre |PtoBR sur le descriptif pour maintenir le côté “inline” du modèle (en évitant les <p></p>).

      Ainsi, même le descriptif peut-être placé en “inline”.

      Et puis hier, il m’est apparu qu’il y a peut être plus simple en ajoutant les modèles suivants : <mediaXX|titre>, <mediaXX|descriptif>, <mediaXX|credits>, <mediaXX|type> et <mediaXX|poids>. Ces modèles, simples et étant appelé sans autre paramètre, renverrait uniquement l’information demandée. De là on peut faire du coup de ce que l’on veut, par exemple : [->XX] (<mediaXX|type> - <mediaXX|poids>).

      Oui c’est intéressant comme approche car elle est plus souple et permet effectivement de choisir les séparateurs. Mais je pense qu’il faudrait aussi maintenir un “tout en un” pour ceux qui n’ont pas besoin de choisir les séparateurs (d’ailleurs, dans un modèle media classique on ne choisit pas le balisage des éléments du modèle).

      Et puis la syntaxe [->XX] (<mediaXX|type> - <mediaXX|poids>) me paraît un peu plus complexe que <mediaXXX|liensimple|poids|type>, notamment pour ceux qui sont déjà habitués à la “syntaxe” des modèles media.

      Par contre, <mediaXX|type> c’est peut-être techniquement plus compliqué à mettre en œuvre, non ? Car actuellement ça renvoie quelque chose de mettre <mediaXX|type> dans son article ! Comment gérer la compatibilité ascendante ?

    • <mediaXX|type> n’est pas officiellement supporté. Normalement, une variante doit toujours être passée.

      Le modèle de base media essaie de retrouver la variante si pas passé au bon endroit. Mais appeler media avec juste type ne devrait pas être autorisée. Le modèle media de base est peut être trop permissif, mais on peut changer ça. Je ne vois pas un souci de compat ascendante. De plus si on utilise bien inserer__modeles, cette situation n’arrive pas.

      Qu’appelles-tu un “tout en un” ? C’est l’affichage des 5 infos ? C’est déjà possible avec un <legendeXX|complete> mais pas propre.

      On peut avoir très bien un <mediaXX|legende> qui englobe le tout d’un div, respecte le position à gauche ou à droite ou au centre, et suive tout les autres params. Mais dans ce cas là, on précise bien que c’est plus que juste un lien.

    • Bon, j’ai ajouté une variante légende ainsi que les variantes titre, descriptif, poids, credits et type.

      cf. http://zone.spip.org/trac/spip-zone... et http://zone.spip.org/trac/spip-zone....

      De plus, si on appelle le modèle media sans variante correctement appelée, un message d’avertissement s’affiche dans l’espace privé.

    • Aie aie ! Avec la compat’ ascendante !!!!

      J’ai vu que tu avais déjà commité les modifs... Pour moi ça risque de casser carrément sur plusieurs de mes sites... Car les rédacteurs ont pris depuis des mois l’habitude de mettre <mediaXX|left> comme ils mettaient avant <docXX|left>... Et là c’est le drame ! (ils ne mettent jamais, absolument jamais la variante).

      Certes, ce n’était pas vraiment la spécification que tu donnais mais l’utilisation implicite de media sans argument était pratique (et rapide) pour les rédacteurs.

      Qu’appelles-tu un « tout en un » ? C’est l’affichage des 5 infos ? C’est déjà possible avec un <legendeXX|complete> mais pas propre.

      Non, par “tout en un”, je voulais dire ce que j’avais essayé de faire... C’est à dire un modèle qui fournit les infos demandées sur un doc, sans l’image ou l’icône, dans des éléments inline (pour pouvoir être placé n’importe où dans le texte). Et pour demander les infos, il suffit d’utiliser la nomenclature que tu avais mise en place pour les autres modèles media. Ainsi on ne demande pas aux utilisateurs d’apprendre un autre mécanisme. Donc un truc comme:

      <mediaXXX|liensimple|poids|type>
      qui donne:

      Ma Belle Image — PNG, 42ko

      (où c’est vrai on ne choisit pas les séparateurs, mais certains n’ont peut-être pas envie de le faire).

    • Aie aie ! Avec la compat’ ascendante !!!!
      J’ai vu que tu avais déjà commité les modifs... Pour moi ça risque de casser carrément sur plusieurs de mes sites... Car les rédacteurs ont pris depuis des mois l’habitude de mettre <mediaXX|left> comme ils mettaient avant <docXX|left>... Et là c’est le drame ! (ils ne mettent jamais, absolument jamais la variante).
      Certes, ce n’était pas vraiment la spécification que tu donnais mais l’utilisation implicite de media sans argument était pratique (et rapide) pour les rédacteurs.

      S’il y a un appel sans variante, alors vignette est toujours utilisé. Par contre, il y aura maintenant un message d’avertissement dans le privé.

      Par contre, s’ils avaient utilisé <mediaXX|type|right> ils seront redirigés vers la nouvelle variante. A aucun moment ces modèles ont été prévus d’être appelés sans variante puisque l’idée de base est justement de préciser en second argument ce que l’on souhaite. D’où le fait d’avoir développé insérer_modèles pour aider à son utilisation.

      Si vraiment un très très gros problème, je ferai une branche avant/après mais en aucun cas on doit pouvoir être limité pour la création de nouvelles variantes.

      Maintenant, la question est de savoir s’ils utilisent le modèle avec plusieurs paramètres et sans variante ou juste le modèle sans variante et sans paramètre. Si sans variante et sans paramètre, il y aura juste un message d’avertissement. Si pas de variante et les autres paramètres, oui ca va être problématique.

      Qu’appelles-tu un « tout en un » ? C’est l’affichage des 5 infos ? C’est déjà possible avec un <legendeXX|complete> mais pas propre.
      Non, par “tout en un”, je voulais dire ce que j’avais essayé de faire... C’est à dire un modèle qui fournit les infos demandées sur un doc, sans l’image ou l’icône, dans des éléments inline (pour pouvoir être placé n’importe où dans le texte). Et pour demander les infos, il suffit d’utiliser la nomenclature que tu avais mise en place pour les autres modèles media. Ainsi on ne demande pas aux utilisateurs d’apprendre un autre mécanisme. Donc un truc comme :
      <mediaXXX|liensimple|poids|type>
      qui donne :
      Ma Belle Image — PNG, 42ko
      (où c’est vrai on ne choisit pas les séparateurs, mais certains n’ont peut-être pas envie de le faire).

      Tu peux déjà t’amuser avec la variante légende. Elle respecte l’ensemble des arams mais effectivement c’est encapsulé dans un div.

      Je veux bien continuer de réfléchir à une variante lien. Mais il faut qu’elle soit alors inline, sans <p> ni <br />. Donc problème avec le descriptif et incompatibilité avec le paramètre légende. Donc pas si évident que ça.

    • Avant tout merci: pour ta célérité et ta sollicitude ! On a rarement vu un SAD comme ça !

      Maintenant, la question est de savoir s’ils utilisent le modèle avec plusieurs paramètres et sans variante ou juste le modèle sans variante et sans paramètre. Si sans variante et sans paramètre, il y aura juste un message d’avertissement. Si pas de variante et les autres paramètres, oui ca va être problématique.

      C’est exactement le cas ! :-( (et quasiment toujours un titre ou un credit qui traîne).

      Le modèle media était vraiment pratique pour eux puisque:

      1. ils n’avaient plus à essayer de savoir si c’était un doc, ou un img ou un emb.
      2. ils pouvaient rajouter les infos qui leur semblaient nécessaires en fonction du contexte (légendes complètes ou non).
      3. c’était simple et ça fonctionne comme l’ancien doc/img/emb (où on indiquait pas de variante non plus)

      Bon... réfléchissons... Comment garder à la fois la simplicité de ne pas déclarer de variante et la capacité à afficher juste des infos avec des mini modèles ?

      Peut-être tout simplement en changeant les nouveaux mini-modèles en <mediaXXX|info|type> (ou <media_infoXXX|type> ce qui du point de vue du modèle est exactement pareil) à la place de <mediaXXX|type> ? Qu’en penses-tu ?

    • Dans l’immédiat, j’ai déjà annulé tous les changements dans l’attente d’y voir plus clair.

      La grosse, très grosse erreur, a d’avoir fait un modèle media de base pour essayer de réaiguiller les erreurs de syntaxe. Du coup, les mauvaises habitudes ont été prises.

      Cela montre en tout cas que ce n’est pas la bonne. Jamais un modèle media n’aurait du être autorisé sans variante. Cela aurait dû dès le départ afficher dans le privé un message d’erreur.
      C’est pas faute d’avoir développé inserer_modeles justement pour aider les rédacteurs a utilisé la bonne syntaxe.

      Reste que du coup je ne sais que faire. S’il faut s’amuser à trouver deux noms différents pour désigne la même chose, ce n’est pas bon. C’est que quelque chose ne va pas. D’ailleurs, tu as fait un modele media_liensimple et non media_lien.

      Ce qui laisse soit la possibilité d’introduire clairement une rupture de compatibilité, soit de limiter la création de nouvelles variantes.

      De plus il faut aussi garder une certaine simplicité d’utilisation à ces modèles qui sont déjà considérés par certains comme une véritable usine à gaz.

      Bref, on peut envisager éventuellement une variante info à qui on pourrait demander d’afficher ou une plusieurs infos sur un document et éventuellement d’y inclure un lien. Reste à voir comment gérer ça proprement. Si une seule info est demandée, elle doit être renvoyée telle qu’elle. Mais si plusieurs infos sont transmises, il faut alors mettre ça en forme de manière à ce que ce soit sur une seule ligne (que faire alors pour le descriptif, appliquer textebrut??) et si on demande un lien, celui doit-il aller seulement sur le titre ou bien sur l’ensemble ? et si on demande plusieurs infos mais pas le titre ? De plus, doit-on pouvoir personnaliser le titre et/ou le descriptif et/ou les crédits comme c’est aujourd’hui possible pour les autres variantes ?

      Bref ça a probablement besoin de maturer encore un peu...

    • Serait-ce bon dans tous les cas d’ajouter dans l’espace privé un message d’avertissement si aucune variante n’est appelée ?

    • Salut !

      Excuse moi pour la réponse tardive alors que tu as le SAD le plus rapide de l’Ouest (et peut-être aussi de l’Est)...

      Dans l’immédiat, j’ai déjà annulé tous les changements dans l’attente d’y voir plus clair.

      Cool ! Merci !

      La grosse, très grosse erreur, a d’avoir fait un modèle media de base pour essayer de réaiguiller les erreurs de syntaxe. Du coup, les mauvaises habitudes ont été prises.

      Je ne suis pas complètement d’accord avec toi: c’est sûr que des habitudes ont été prises, mais je ne crois pas qu’elles soient si mauvaises. Il n’est illogique d’utiliser le raccourci media sans sa variante. D’ailleurs, c’est ainsi que s’utilisent les raccourcis natifs doc/img/emb (que le raccourci media permet très agréablement de désambiguiser), et c’est ainsi qu’il se présente sous la vignette du document dans la barre latérale des documents joints lors de l’édition d’un article: <mediaXXX>.

      Cela montre en tout cas que ce n’est pas la bonne. Jamais un modèle media n’aurait du être autorisé sans variante. Cela aurait dû dès le départ afficher dans le privé un message d’erreur.
      C’est pas faute d’avoir développé inserer_modeles justement pour aider les rédacteurs a utilisé la bonne syntaxe.

      Je n’ai pas bien compris pourquoi la variante était si fondamentale à tes yeux ? C’est amusant j’ai l’impression que mes utilisateurs et moi même n’avons pas vu le même intérêt dans le plugin que toi son créateur ! :-)

      Pour nous, c’était enfin le moyen de démêler ces histoires d’img/doc/emb... Avant, les utilisateurs ne savaient jamais quel raccourci il fallait mettre en fonction du type de document, ou s’ils voulaient des légendes (et quel type de légendes). Grâce au plugin media c’est fini: quel que soit le type de document joint, on écrit media, et on ajoute les attributs nécessaires pour que la légende qu’on veut s’affiche. Et comble du luxe, on peut même choisir la taille, et un éventuel lien (sans parler de titre=titre différent de celui du doc qui est super pratique quand on utilise un même document dans plusieurs articles).

      D’ailleurs, à ma connaissance, personne parmi les utilisateurs de mes sites n’utilise «insérer modèle» (qui est pourtant installé), car quand on a compris la syntaxe des attributs, c’est plus rapide d’écrire directement <mediaXXX|titre|lien|taille=42|left> que d’utiliser le formulaire (tu remarques que pour te taquiner j’ai mis tous les attributs dans le désordre, et pas de variante. Mais c’est fidèle à ce que font mes utilisateurs).

      Reste que du coup je ne sais que faire. S’il faut s’amuser à trouver deux noms différents pour désigne la même chose, ce n’est pas bon. C’est que quelque chose ne va pas. D’ailleurs, tu as fait un modele media_liensimple et non media_lien.

      Le choix du nom “liensimple” était vite fait pour répondre à une demande urgence, mais pas très réfléchi ! “info” ou “infos” me paraît maintenant plus pertinent.

      Ce qui laisse soit la possibilité d’introduire clairement une rupture de compatibilité, soit de limiter la création de nouvelles variantes.

      De plus il faut aussi garder une certaine simplicité d’utilisation à ces modèles qui sont déjà considérés par certains comme une véritable usine à gaz.

      ??? J’aimerai bien savoir ce qu’on leur reproche !

      Bref, on peut envisager éventuellement une variante info à qui on pourrait demander d’afficher ou une plusieurs infos sur un document et éventuellement d’y inclure un lien. Reste à voir comment gérer ça proprement. Si une seule info est demandée, elle doit être renvoyée telle qu’elle. Mais si plusieurs infos sont transmises, il faut alors mettre ça en forme de manière à ce que ce soit sur une seule ligne (que faire alors pour le descriptif, appliquer textebrut ??) et si on demande un lien, celui doit-il aller seulement sur le titre ou bien sur l’ensemble ? et si on demande plusieurs infos mais pas le titre ? De plus, doit-on pouvoir personnaliser le titre et/ou le descriptif et/ou les crédits comme c’est aujourd’hui possible pour les autres variantes ?

      Bref ça a probablement besoin de maturer encore un peu...

      Je pense qu’il faut limiter l’utilisation du modèle media à l’affichage du document ou du lien vers le document. Dans ce cas, on devrait faire avec “info” comme avec l’icône par exemple. C’est-à-dire que le titre est un lien (comme l’icône est un lien), et les autres infos accompagnent le titre hors du lien (là aussi comme pour la variante ’icône). On peut imaginer de les mettre entre parenthèses, ce qui en satisfera pas tout le monde mais semble quand même plutôt générique. Du genre:

      titre du doc (autres infos)

      Pour le descriptif, c’est une autre paire de manche. Peut-être que quand le descriptif est demandé dans le modèle, on peut passer le modèle dans un type bloc (avec un dt/dd, comme pour les autres variantes), et rester en type inline si le descriptif n’est pas demandé.

      Serait-ce bon dans tous les cas d’ajouter dans l’espace privé un message d’avertissement si aucune variante n’est appelée ?

      Ce serait bon si on considère que le modèle media sans variante c’est mal ! Mais je ne trouve pas ! Les utilisateurs de mes sites trouvent ça très pratique, et je suis d’accord avec eux ! En tout cas, si tu rajoutes un tel avertissement, il faudrait aussi changer l’exemple qui s’affiche dans sous les vignettes lors de l’édition de l’article...

    • c’est ainsi qu’il se présente sous la vignette du document dans la barre latérale des documents joints lors de l’édition d’un article : <mediaXXX>.

      Pour le coup non, on présente bien (cf. capture jointe) les 3 variantes principales.

      Ce qui m’embête avec les modèles appelés sans variante, c’est justement que c’est indéterminé. L’idée de cet ensemble c’est de préciser ce que l’on veut afficher. Mais surtout, on voit bien ensuite les problèmes que cela pose en terme de syntaxe, une variante <mediaXX|titre> devenant tout bonnement impossible alors qu’elle serait à la fois pertinente et dans la logique des variantes de modèles (cf les exemples sur http://www.spip.net/fr_article3454.html).

      Dans la version SVN du trunk (plugin pour SPIP 3), il y maintenantun modèle media_info à tester (avant d’être éventuellement étendu à la v1 et documenté ici). Précision : ce modèle est en test et ne sera peut être pas maintenu. A ne pas utiliser en prod tant qu’une décision finale ne sera pas prise.

      Grosso, le modèle accepte les paramètres suivants :

      • titre (personnalisable)
      • descriptf (personnalisable)
      • credits (personnalisable)
      • type
      • poids
      • mime_type
      • taille (correspondra à largeur x hauteur)
      • hauteur
      • largeur
      • extension
      • date_publi
      • date_maj

      En plus, il peut aussi prendre right/center/left, ainsi que lien et titre_lien.

      Si une seule info est demandée, elle est renvoyée brute (excepté les traitements typos). Ainsi, <mediaXX|info|hauteur> renverra seulement 142 (sans autre mise en forme).

      Si plusieurs infos sont demandées, ces dernière sont mises en forme pour produire quelque chose de compréhensible, restant inline. De plus, si un lien est demandé ainsi que le titre, le lien sera mis sur le titre. Si pas de titre, le lien sera mis sur les infos.

      Exemple : <media3|info|lien|titre=Titre du doc|date_publi|credits|type|poids> produira Titre du doc (7 octobre 2012, par Jojo. PDF - 145.6 ko.)

    • c’est ainsi qu’il se présente sous la vignette du document dans la barre latérale des documents joints lors de l’édition d’un article : <mediaXXX>.

      Pour le coup non, on présente bien (cf. capture jointe) les 3 variantes principales.

      Ah ? ça doit être parce qu’en prod’ je n’utilise pas la dernière version de modèles média (mais la 0.3.5 sur un SPIP 2.1.x). Voir ma capture.

      Ce qui m’embête avec les modèles appelés sans variante, c’est justement que c’est indéterminé. L’idée de cet ensemble c’est de préciser ce que l’on veut afficher. Mais surtout, on voit bien ensuite les problèmes que cela pose en terme de syntaxe, une variante <mediaXX|titre> devenant tout bonnement impossible alors qu’elle serait à la fois pertinente et dans la logique des variantes de modèles (cf les exemples sur http://www.spip.net/fr_article3454.html).

      Oui, ça laisse moins de liberté pour créer des variantes. Mais, y aurait-il des cas où l’on voudrait créer une variante avec le nom d’un des attributs ? Ça ne me semble d’ailleurs pas une très bonne idée si on veut que ça reste compréhensible pour les utilisateurs ! Ex.:


      — alors si tu mets titre en premier ça va faire ça, mais si tu le mets en deuxième ça va faire autre chose. Compris ?
      — heu...

      Je crains que ce genre de variantes créent de la confusion !

      Dans la version SVN du trunk (plugin pour SPIP 3), il y maintenantun modèle media_info à tester (avant d’être éventuellement étendu à la v1 et documenté ici). Précision : ce modèle est en test et ne sera peut être pas maintenu. A ne pas utiliser en prod tant qu’une décision finale ne sera pas prise.

      Grosso, le modèle accepte les paramètres suivants :

      titre (personnalisable)
      descriptf (personnalisable)
      credits (personnalisable)
      type
      poids
      mime_type
      taille (correspondra à largeur x hauteur)
      hauteur
      largeur
      extension
      date_publi
      date_maj

      En plus, il peut aussi prendre right/center/left, ainsi que lien et titre_lien.

      Si une seule info est demandée, elle est renvoyée brute (excepté les traitements typos). Ainsi, <mediaXX|info|hauteur> renverra seulement 142 (sans autre mise en forme).

      Si plusieurs infos sont demandées, ces dernière sont mises en forme pour produire quelque chose de compréhensible, restant inline. De plus, si un lien est demandé ainsi que le titre, le lien sera mis sur le titre. Si pas de titre, le lien sera mis sur les infos.

      Je vais tester ce WE, mais ça semble vraiment super ! Merci !

    Reply to this message

  • 4

    Bonjour,
    Je suis en train d’utiliser la version 4.01 de Media (la dernière ?) qui est pas mal, sur une version 3.0.2 de Spip, mais assez buggée.
    Je signale donc que du coté back office actuellement, lorsqu’on clique sur “Modifier” pour un document ou une image, il y a un erreur “fichier introuvable”.
    Pour corriger : ouvrir /modeles/document_case.html et enlever le “s” en ligne 43 #URL_ECRIREdocument_edit,id_document=#ID_DOCUMENT

    Je n’ai pas reçu activer la partie configuration, si certains ont trouvé, je suis preneur !

    • et en titre de document, on retrouve le titre de l’article et non celui du document (de la table spip_documents)... ça me déplairai pas de corriger proprement, mais je ne comprends pas ce que le script cherche à faire, entre les env et les sql... je vais corriger à la hache, c’est moche

    • en fait, ce qu’il me plait bien dans ce plugin, c’est la possibilité de gérer les tailles des images à partir de la balise , de pouvoir gérer des modèles par extension... c’est possible avec un plugin plus récent ?

    • Bonjour,

      le portage en SPIP 3 n’est pas finalisé. Il a été affiché compatible SPIP 3 un peu trop vite.

      Je n’aurais pas d’accès SVN avant Lundi. Je regarde ça en début de semaine prochaine.

      Cordialement

    • Une nouvelle version pour SPIP 3 est désormais disponible et devrait régler les problèmes rencontrés.

      A tester

      Cordialement

    Reply to this message

  • 5

    bonsoir,
    Le plugin Video demande le plugin Medias qui est impossible à trouver nulle part. L’on me dit que c’st mediatheque... qui ne résout pas le pb..
    merci pour votre aide.

    • Le plugin ayant pour préfixe medias est bien méditahèque (voir Médiathèque) les modèles media ayant pour préfixe media (sans s). je sais que ça peut sembler confusionnant.

      Cordialement

    • bonjour,
      je réitère mes questions posées sur le fil video accessible les 7,9 et 11 juin, restées sans réponses.
      il m’est impossible d’intégrer une vidéo, quelle que soit sa grosseur, même en refaisant exactement les même manœuvres que les vidéos déjà en place. J’ai essayé pratiquement tous les plugins de vidéos et, tous sans exception, si la video se pose dans l’article, ne donnent qu’une image avec un lien pour lire cette video. Et de toute façons, il manque toujours la barre horizontale du lecteur. Avec video accessible, tant que le poids ne dépasse pas 19,... Mo, c’est très bien. Sinon... J’ai tenté un changement de format, avi, flv, mp4, etc, rien n’y fait. Et j’utilise mon FTP cependant. même un serveur indépendant. Rien. De même pour appeler la video, j’ai essayé docXX, imgXX, embXX, toujours sans résultat.

      Où est l’erreur ?
      Merci

      le site, ici
      ce que j’ obtiens aussi:

    • Bonjour,

      tout d’abord sachez que SPIP et les plugins sont développés par des bénévoles qui prennent sur leur temps libre. Dès lors, puisque ces personnes ont également une vie en dehors de SPIP, ils ne sont pas toujours devant leur écran pour assurer un service après-don.

      Concernant des questions de fonctionnement usuel de SPIP, d’utilisation générique des plugins, le meilleur endroit pour poser sa question est d’aller sur la liste de discussion SPIP User. Elle est lue par plus de monde et vous pourrez y trouver une première aide précieuse. Les forums des plugins sur Contrib ont pour vocation à accueillir les problématiques et retours de bugs spécifiques à ce plugin.

      Avant de poster un commentaire, la lecture des deux articles suivants est la bienvenue :

      Ainsi, il est toujours bon quand vous postez un problème, de préciser la version de SPIP, les plugins actifs et leur version. Nous ne sommes pas devins.

      Concernant la limite des documents chargés en upload via un navigateur web, il s’agit d’une limite technique. D’une part, la taille des fichiers peut être limité (de quelques Mo à quelques dizaines de Mo) par la configuration de PHP sur votre serveur. D’autre part, elle peut également être spécifiée dans la configuration de SPIP (dans mes_options.php ou via le plugin Couteau KISS).

      Pour une grosse vidéo, vous devez donc passer par FTP pour la déposer sur votre serveur dans le dossier tmp/upload puis installer le document (quand vous ajoutez un document, les fichiers dans tmp/upload vous sont proposés).

      Concernant les modèles, img est totalement inadapté pour une vidéo. Le modèle doc sert à ajouter une icone du type de doc avec un lien. Vous pouvez passer par le modèle emb qui génère une incrustation via une balise object. Ce modèle de base ne fournit donc pas de lecteur vidéo en flash, et sera interprété différemment selon le navigateur et les lecteurs installés chez le visteur.

      Les modèles media procurent d’autres raccourcis. Mais sachez que <media123|embed> fonctionne par défaut comme le modèle emb natif de SPIP : il ne fournit pas de player vidéo.

      Le plugin Vidéo Accessible vient justement surcharger le modèle emb pour charger les vidéos avec un lecteur flash inclue. C’est donc a priori la bonne solution. Pour le moment, vidéo accessible n’étend pas les modèles media. Les raccourcis du type <media123|embed> ne sont donc pas interprétés par vidéo accessible (on reste donc sur une inclusion classique).

      En vous réferrant à la documentation de ce plugin, vous verrez que vous pouvez personnaliser ou non l’affichage du player.

      Enfin, si j’en crois cette page : http://spi.blh-land.fr/La-victoire-..., le lecteur fonctionne sur votre site (page consultée avec Firefix 4.0.1).

      Cordialement

    • D’abord, merci d’avoir fait diligence.
      Ensuite, loin de moi toute idée de remise en question du travail des uns et des autres et de leur présence sur ce forum, ce n’était pas mon intention de morigéner un tel ou un tel quant à leur rapidité de réponse. Tout au plus, mais JE NE LE FERAI PAS, je pourrais répondre en disant que dès lors qu’on se lance dans un certain travail, fut-il bénévolement, il est quand même souhaitable d’en assumer les inconvénients.
      D’autre part, et là, j’insiste, il est pour le moins curieux de passer une semaine pour mettre une vidéo en ligne, en respectant TOUTES les données constructeurs, sans que pour autant que cela fonctionne correctement - mes 4 vidéos sur les violonistes, de poids bien inférieurs à 20 Mo, restent muettes, sauf une - alors que sur d’autres sites/blogs, en 30 sec, c’est bâclé. Et avec des tailles de centaines de Mo. Pour le commun des mortels, le moins qu’il puisse dire est : étonné!
      A moins d’avoir un ingénieur système-constructeur de sites sous la main, il faut avouer que Spip, s’il est particulièrement intéressant dans beaucoup de domaines, n’est cependant pas à la portée du premier quidam venu cherchant par ci par là, une aide appropriée.
      Pour en terminer avec ce sujet, je m’aperçois qu’en fait, la solution du “vidéo accessible” est assez judicieuse, et que toutes les autres restent en suspend.
      Je vais donc chercher dans les doc de ce plugin.
      Le fait de placer ses videos dans tmp/upload est-il capital, ou les placer dans un autre répertoire à la racine est-il suffisant ?( ce que j’ai fait, selon les conseils de plusieurs internautes.) De même , mon ftp transfère des fichiers de très grosses tailles sur d’autres blogs sans aucun soucis.
      Pour ceux que ça intéresse, voici les renseignements demandés:
      Spip, dernière version,
      Thème, sarkaspip, vitamine,
      plugins, en fichiers joints, ici et , la plupart ne servant pas encore.

      Encore merci pour l’aide reçue, et si je n’ai pas pris ombrage de la réponse, qu’il en soit de même pour les lecteurs de ce fil.

      Bonne soirée. :)

    • Je me réponds à moi-même sur cette particularité des vidéos.
      N’ayant que peu d’articles, j’ai préféré réinstaller spip en y accrochant les plugins indispensables. J’ai donc collé mes videos et vignette sans aucune difficulté. Habitué cependant aux éditeurs de textes comportant au moins les mises en page, couleurs... j’ai installé CKEditor : et en voulant placer une video et image, de nouveau la pagaille. J’ai alors viré cet éditeur et , vous l’avez deviné, tout baigne.
      CKEditor est assez bien pour du texte seulement, car il semble qu’il y ait des incompatibilité avec la gestion des documents.

      .

    Reply to this message

  • 4
    VideoMAN

    je suis sous SPIP 2.1.10 et je viens de tester avec le plugin Insérer Modèles, qui donne accès à de l’aide !
    cependant sans ce dernier, votre plugin à mon sens ne sert à rien...enfin presque lol !
    voici les inconvenients que j’ai enregistré :

    1/ quelques troubles avec porte plume :
    - en mode visulaiser aucune image n’est visble (ni vignette ni icone) quel que soit le mode choisi !
    - finalement le plugin insérer modèles n’insère aucun bouton sur le porte plume ? est-ce normal ?

    2/ insertion de documents (double possibilité...complication) :
    - sans le plugin insérer modèles, l’ajout d’un document, remplace juste docXX par mediaXX et enplus on perd les propositions de position center, left, right (je pense que vous devriez les remettre)...
    - avec le plugin insérer modèles, on obtient en plus du traditionnel formulaire d’ajout de document de médiathèque un autre qui propose d’insérer un modèle, je choisi insérer un document et là j’obtiens une aide qui facilite les choses il est vrai !!
    mais :
    * si on utilise l’ajout habituel de documents plus haut (on retombe exactement dans la situation sans plugin insérer modèles) et c’est pas vraiment pratique ! de plus, aucune adie n’est fournie, ainsi l’assistance n’est pas surchargée sur la boite d’ajout d’un document !
    * un document ajouté par les 2 moyens (habituel) ou media, devient inaccessible à cette belle asistance, si on clique sur modifier
    * je n’ai pas tester l’ajout de zip contenant des images que l’on souhaite dezipper, est-ce que cela marche avec votre solutions ?
    * pensez vous pouvoir donner la main à d’autres plugins qui insèrent des vidéos ? je penses aux deux plugins : vidéos et vidéo accessible ?

    j’espère que mon retour vous sera utile pour améliorer ce plugin.

    merci et bon courage.

    ps: sinon pour le plugin insérer modèles, j’ai installé le plugin fomulaire de contact avancé, ce dernier est alors proposable par le plugin insérer modèles, pourrait on pouvoir hcoisir quel type dinserttion nous acceptons ? si une telle action est possible où se faire le plugin insérer modèles ou bien le plugin qui propose la fonctionnalité ? perso je n’ia pas besoin de pouvoir proposer l’insetio nde formulaire de contact !!

    • 1/ quelques troubles avec porte plume :
      -  en mode visulaiser aucune image n’est visble (ni vignette ni icone) quel que soit le mode choisi !

      Je ne saisi pas très bien votre remarque. Qu’appelez-vous mode visualiser ?

      - finalement le plugin insérer modèles n’insère aucun bouton sur le porte plume ? est-ce normal ?

      Ce plugin insère bien une icône dans le porte-plume, icone pour l’insertion de modèles avec un sous-menu pour les différents modèles pris en charge. Il se peut que vous ne voyez pas ce bouton en raison d’un cache du porte-plume. Pensez à vider le cache de SPIP et le cache de votre navigateur et recharger la page.

      2/ insertion de documents (double possibilité...complication) :
      -  sans le plugin insérer modèles, l’ajout d’un document, remplace juste docXX par mediaXX et enplus on perd les propositions de position center, left, right (je pense que vous devriez les remettre)...

      Vous voulez dire la liste des modèles proposés dans la colonne de gauche ? Elle peut être éventuellement améliorée.

      - avec le plugin insérer modèles, on obtient en plus du traditionnel formulaire d’ajout de document de médiathèque un autre qui propose d’insérer un modèle, je choisi insérer un document et là j’obtiens une aide qui facilite les choses il est vrai !!
      mais :
      * si on utilise l’ajout habituel de documents plus haut (on retombe exactement dans la situation sans plugin insérer modèles) et c’est pas vraiment pratique ! de plus, aucune adie n’est fournie, ainsi l’assistance n’est pas surchargée sur la boite d’ajout d’un document !

      à chacun son travil : médiathèque gère les documents, insérer modèles gère l’insertion de modèles dans les textes.

      * un document ajouté par les 2 moyens (habituel) ou media, devient inaccessible à cette belle asistance, si on clique sur modifier

      Que voulez-vous dire ? Le lien Modifier sous le cadre d’un document concerne les informations relatives à un document, pas l’appel du document dans le texte.

      * je n’ai pas tester l’ajout de zip contenant des images que l’on souhaite dezipper, est-ce que cela marche avec votre solutions ?

      Cela concerne Médiathèque. Avec charger un ZIP avec médiathèque et installer chaque élément du Zip comme documents joints.

      * pensez vous pouvoir donner la main à d’autres plugins qui insèrent des vidéos ? je penses aux deux plugins : vidéos et vidéo accessible ?

      Les modèles media, en particulier <mediaXX|embed>, peuvent être étendus par d’autres plugins. Voir Modèles <media> : documentation Développeur. Voir un exemple : http://zone.spip.org/trac/spip-zone...

      ps : sinon pour le plugin insérer modèles, j’ai installé le plugin fomulaire de contact avancé, ce dernier est alors proposable par le plugin insérer modèles, pourrait on pouvoir hcoisir quel type dinserttion nous acceptons ? si une telle action est possible où se faire le plugin insérer modèles ou bien le plugin qui propose la fonctionnalité ? perso je n’ia pas besoin de pouvoir proposer l’insetio nde formulaire de contact !!

      Le plugin Insérer Modèles se base sur les descriptions YAML fournies par les plugins dans un sous-répertoire modèle. C’est un fonctionnement générique pour différents modèles. Ce YAML en question est donc fourni directement par le plugin. Il n’existe pas de mécanisme actuellement permettant de retirer certains modèles dans la liste des modèles proposés.

    • La version 0.4.1 améliore la présentation des raccourcis qui sont de nouveau clicquable. Maintenant vous verrez :

      Inclusion de l’icône :
      <media175|icone|left>
      <media175|icone|center>
      <media175|icone|right>

      Inclusion de la vignette :

      <media175|vignette|left>
      <media175|vignette|center>
      <media175|vignette|right>

      Inclusion directe :

      <media175|embed|left>
      <media175|embed|center>
      <media175|embed|right>
    • VideoMAN

      Merci de votre vélocité !!

      1/ quelques troubles avec porte plume :
      - en mode visulaiser aucune image n’est visble (ni vignette ni icone) quel que soit le mode choisi !

      Je ne saisi pas très bien votre remarque. Qu’appelez-vous mode visualiser ?

      Ben dans le porte plume, il y a les deux parties (tabs) : editer et voir !
      Avec votre plugin, dans la partie “voir”, je n’obtiens pas la visuel du modèle inséré !(alors que imgXX donne l’image dans le cas d’une image)

      Ce plugin insère bien une icône dans le porte-plume, icone pour l’insertion de modèles avec un sous-menu pour les différents modèles pris en charge. Il se peut que vous ne voyez pas ce bouton en raison d’un cache du porte-plume. Pensez à vider le cache de SPIP et le cache de votre navigateur et recharger la page.

      Ben c’est le cas ! Finalement c’est ok !!

      Vous voulez dire la liste des modèles proposés dans la colonne de gauche ? Elle peut être éventuellement améliorée.

      Oui avant dans le formulaire d’upload de la médiathèque on avait juste (on perdait les <docXX|center>) et vous l’avez corrigé avec la 0.41 (je n’ai pas encore testé !)

      à chacun son travil : médiathèque gère les documents, insérer modèles gère l’insertion de modèles dans les textes.

      Oui à chacun son travail ! mais j’aurai aimé que l’insertion des documents par médiathèque puisse être assistée par votre plugin, je pensais que celui ici allé surcharger et apporter son assistance directement sur la boite de dialogue de médiathèque !
      car avec le formulaire d’upload de médiathèque juste au dessus, on peut aussi insérer des modèles de documents sur le texte (enfin les copier et les utiliser !!)

      * un document ajouté par les 2 moyens (habituel) ou media, devient inaccessible à cette belle asistance, si on clique sur modifier

      Que voulez-vous dire ? Le lien Modifier sous le cadre d’un document concerne les informations relatives à un document, pas l’appel du document dans le texte.

      Oui mais ça aurait été bien quand même de pouvoir recouvrir les infos d’insertion du modèle inséré (via la boite de dialogue aussi)...ainsi comme je le disais la fusion du formulaire d’insertion avec celui de l’ajout d’un document, un peu comme le plugin video accessible pour les vidéos...

      Ce YAML en question est donc fourni directement par le plugin. Il n’existe pas de mécanisme actuellement permettant de retirer certains modèles dans la liste des modèles proposés.

      je pense que ça serait bien de penser à mettre en place un tel mécanisme au sein du plugin insérer modèles ?

      Merci encore de vos efforts !!!

      En fait, ma confusion ua sujet de votre plugin, vient du fait que j’ai cru que ceci allait s’ajouter au formulaire ou boite d’ajout/modification d’un document...

      @+

    • Concernant la visualisation en cours d’écriture, cela fonctionne parfaitement chez moi.

      Un même document peut être inséré de différentes façons dans un même texte.

      Le plugin Vidéo accessible complète les informations propres au document (comme ses sous-titres ou l’audio-description). Il s’agit d’informations qui dépendent du document proprement dit et non de l’insertion du document, même si le modèle du plugin prends ces informations en compte.

      Le plugin Vidéo Accessible n’étend pas les modèles media. Cela peut s’envisager en ajoutant au plugin des modèles media_audio et media_video qui viendraient surcharger les modèles du plugin Modèles Média pour prendre ces éléments en compte. Attention : Vidéo Accessible n’est pas développer sur la Zone : il faut donc soit voir avec l’auteur du plugin Video Accessible soit créer un plugin complémentaire faisant le lien entre les deux.

      Cordialement.

    Reply to this message

  • 4

    Salut !

    Mes utilisateurs (rédacteurs) viennent de tomber sur un petit écueil ergonomique : faire un lien (et juste un lien) vers un document...

    Avant, ils faisaient : [texte du lien->docXXX], car sur la colonne de gauche il était écrit qu’on insère un doc en écrivant <docXXX|position>. Depuis que j’utilise (avec beaucoup de bonheur) les modèles media ils essaient de faire [texte du lien->mediaXXX], car il est écrit <mediaXXX|position> dans la colonne de gauche... Mais ça ne marche pas !

    Ce serait plus pratique si « media » était interprété comme « doc » ou « img » dans les raccourcis typo...

    • euhhh je n’y avais pas pensé.

      Il faudrait tester si en passant par le pipeline pre_typo et en recherchant les chaînes de la forme ->mediaXXX et en les remplaçant par ->docXXX, les liens sont ensuite correctement gérés par SPIP.

    • Mmmh...

      Bonne idée d’agir sur pre_typo... Je vais voir si j’arrive à faire ça quand j’aurai un peu de temps (peut-être en fin de semaine)

      Merci pour ta réponse !

    • En fait, il fallait utiliser le pipeline pre_liens.

      Normalement, réglé avec la version 0.4.0.

    • Merci ! Tu m’as devancé et tant mieux parce que c’est sans doute mieux fait (moi, je m’apprêtais à agir dans pre_propre).

      Merci encore pour ta vélocité !

    Reply to this message

  • 13

    Voici un plugin super qui risque de bien simplifier la vie des rédacteurs.

    J’ai quand même relevé un petit souci: il doit manquer des attribut_html quelque part, car quand j’ai des titres de docs contenant des guillemets droits ("), ça invalide le html de la page avec ce type de code:

    <dt><a href="IMG/png/mon_image.png" class="spip_in" title="blala "dans les guillemets qui tuent"" type="image/png">

    Évidement, le title pose souci !

    Si le souci avait été au niveau des modèles j’aurais pu corriger, mais là c’est dans les balises du plugin et j’ai jeté un œil, ça me dépasse !

    • Quitte à être casse pieds, j’en profite pour te signaler deux autres soucis:

      • Bien que le globale permettant de supprimer les numéros soit présente, les numéros des titres (les rangs) sont tout de même affichés.
      • C’est étrange, mais dans le <dt> du titre et le <dd> de la description il y a un style inline: style='width: px;' avec un attribut css width vide (?)...
    • Pas de souci. C’est comme ça que les bugs sont détectés et corrigés. Normalement la version 0.3.3 devrait corriger les soucis signalés. Peux-tu tester chez toi ?

    • Testé et approuvé ! supprimer_numero: ok; attribut_html: ok.

      Il reste les étranges width vides, mais ça ne gène pas du tout !

      Merci !

    • Ah si hélas je trouve d’autres étrangetés:

      <mediaXXX|largeur=200> m’affiche la légende (alors que |legende n’est pas précisé !) et est un lien vers lui-même (alors que |lien n’est pas précisé non plus)... étrange...

      Le début du modèle media.html me laisse circonspect:

      #SET{legende,#ENV{legende}|sinon{legende}} #SET{lien,#ENV{lien}|sinon{lien}} #SET{taille,#ENV{taille}|sinon{icone}}
      [(#INCLURE{fond=modeles/media_vignette}{legende=#GET{legende}}{lien=#GET{lien}}{taille=#GET{taille}}{env})]

      Que cherches-tu à faire avec la série des #SET au début ? D’après ce que j’y lis tu forces la valeur de #GET{legende} à legende si #ENV{legende} est nul ce qui n’est pas l’effet désiré (idem pour |lien)

      D’ailleurs dans l’#INCLURE, le {env} ne devrait-il pas être placé avant les autres paramètres (sinon il va les écraser) ? C’est à dire que ça ne devrait pas plutôt être:

      [(#INCLURE{fond=modeles/media_vignette}{env}{legende=#GET{legende}}{lien=#GET{lien}}{taille=#GET{taille}})]

      Voire:

      [(#INCLURE{fond=modeles/media_vignette,env}{legende=#GET{legende}}{lien=#GET{lien}}{taille=#GET{taille}})]

      Sans les #SET et les #GET qui vont avec dans l’#INCLURE, le comportement des légendes et des liens redevient normal... Sauf |legende tout seul qui ne marche plus, il faut spécifier (|legende=legende ou |legende=complete).

    • Je vais essayer de creuser cette question des width.

      Pour le second point, si le modèle est appelé sans variante, alors on sélectionne la variante vignette, avec légende et lien. (on fournit un comportement par défaut pour le cas sans variante)

      C’est pour ça que media.html contient ce code. Normalement, on devrait toujours appelé le modèle en lui précisant une variante.

    • Pour les width, je n’ai pas le souci. Est-ce avec un type de modèle particulier ?
      Qu’elle est ta configuration tu plugin (Configuration > Fonctions avancées) ?

    • Dans le même ordre d’idée, si je retire le |sinon{legende} qui force l’affichage des légendes quand #ENV{legende} est nul, le modèle <mediaXXX|titre ne permet pas l’affichage du titre...

      je pense que le souci global vient de la reconnaissance du paramètre “vide” passé au modèle (|legende ou titre sans leur donner explicitement de valeur) qui est reconnu comme nul. Mais il y a la solution quelque part dans ton code, puisque |lien fonctionne sans paramètre (à condition de retirer de media.html: |sinon{lien} qui force l’a création du lien quand #ENV{lien} est nul)

    • Pour les width, je n’ai pas le souci. Est-ce avec un type de modèle particulier ?
      Qu’elle est ta configuration tu plugin (Configuration > Fonctions avancées) ?

      Ah ok, j’avais mal compris la doc ! Merci de ta réponse...

      Tu peux donc ignorer mon autre commentaire (posté dans l’intervalle) !

    • Oups décidément, je m’emmêle le clavier !

      Je reformule mes réponses:

      Pour le second point, si le modèle est appelé sans variante, alors on sélectionne la variante vignette, avec légende et lien. (on fournit un comportement par défaut pour le cas sans variante)

      C’est pour ça que media.html contient ce code. Normalement, on devrait toujours appelé le modèle en lui précisant une variante.

      Ah ok, j’avais mal compris la doc ! Merci de ta réponse...

      Tu peux donc ignorer mon autre commentaire (posté dans l’intervalle) !

      Pour les width, je n’ai pas le souci. Est-ce avec un type de modèle particulier ?
      Qu’elle est ta configuration tu plugin (Configuration > Fonctions avancées) ?

      le width vide c’est avec la config par défaut (je viens de vérifier que les champs ne se sont pas vidés) et un modèle par défaut: <mediaXXX|largeur=150px>

    • Le modèle sans variante a été modifié. (version 0.3.4). Pour plus de simplicité, il se sontente d’appeler la variante vignette.

    • Le modèle sans variante a été modifié. (version 0.3.4). Pour plus de simplicité, il se sontente d’appeler la variante vignette.

      ok, merci ! J’espère que ça ne va pas casser quelque chose chez les autres !

    • Normalement, la question des width devrait être enfin, je l’espère, corrigée.

      Par ailleurs, quelques corrections ont été apportées pour les cas suivant : <media12|legende> (paramètres passés sans variante) ou <media12|lien|icone> (variante passée à la mauvaise position). Le modèle de base devrait normalement régorganiser correctement les variables d’environnement et rediriger vers la bonne variante.

    • Oui tu as réglé tous les problèmes :

      Tout simplement génial: merci !!

    Reply to this message

  • 6

    chez moi, avec spip 2.1.8 et tous les plugins requis installés, ça ne marche pas. Quand je mets une balise de type <media388> dans mon article, j’ai un message d’erreur qui met dit "

    Erreur SQL 1146
    Table 'verlad_chroniquesbleues.spip_medias' doesn't  exist
    SELECT statut FROM spip_medias WHERE id_media=388

    C’est dû à quoi ? Dommage, car le principe du plugin est très intéressant, j’aimerais bien pouvoir l’utiliser !

    • euhhh je ne comprends pas le problème. Il doit manquer des mots à votre message.

      Vous vouliez parler d’un modèle <media12> dans le texte d’un article ? Qu’avez vous précisément mis ?

      Vous l’avez mis dans le texte d’un article ou dans un squelette ?

    • Utilisez <code></code> dans votre message pour que SPIP conserve le code informatique.

    • Oui, désolé, c’est bien un modèle de type < media12 > , ça avait sauté dans mon message.

      Sinon, j’ai vu un truc depuis : apparemment il y a incompatibilité avec un autre plugin, Liens entre contenus. Quand je le désactive, votre plugin fonctionne très bien. Dommage, car liens entre contenus est très utile, il permet de tester les liens internes présents dans l’article. Mais visiblement il ne comprend pas le fonctionnement de la balise media...

    • De quelle version de liens entre contenus s’agit-il ? J’ai les deux dans leur dernière version sur un même site et ça fonctionne correctement.

      Cordialement

      PS : vous devriez passer votre SPIP en 2.1.10

    • J’ai la version 0.26. Je vais faire la mise à jour.

      Passer en spip 2.1.10, je veux bien, mais comme j’ai personnalisé quelques fichiers, j’ai un peu peur du résultat final...

    • Avec la dernière version de Liens entre contenus (0.29), ça marche nickel, merci beaucoup et bravo pour votre travail !

    Reply to this message

  • 3

    Salut Joseph,
    Est ce que le modèle média permet d’éviter les doublons (avec le critère doublon dans le squelette), comme pour doc, img, emb ?
    merci de ce travail.

    • Euhh je ne connais pas cette technique. Il faut donc essayer.

      Mais pour savoir si un document est présent dans un article (rubriques, brèves...), le mieux est d’utiliser le critère {vu}.

      Ainsi, pour sélectionner les documents joints à un article mais qui ne sont pas appelés dans le texte de l’article, on fera :

      <BOUCLE_docs(DOCUMENTS){id_article}{vu=non}>
      ...
      </BOUCLE_docs>

      De la même manière, {vu=oui} permet de sélectionner les documents appelés dans le texte.

    • ha oui je me suis totalement emmêlé le cerveau. Je pensais à la fonction marquer_doublons_docs, ce qui n’a vraiment rien à voir.
      merci de ta réponse.

    • Si la question du modèle sans variante semble trop complexe, on peut simplifier en sélectionnant juste la variante vignette et en laissant le reste du fonctionnement identique.

    Reply to this message

Ajouter un commentaire

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom