Albums 3

Publié le : 8 août 2014 – Dernière modification le 21 décembre 2021 – par tcharlss – 344 commentaires

English, français
1
2
3
4
5
52 votes

Le plugin « Albums » évolue dans une version 3 pour SPIP 3.

Avant d’effectuer une mise à jour depuis la version 1 ou 2, consultez les notes sur la rétro-compatibilité. Les modèles, notamment, on reçut quelques changements pour la bonne cause.

En préambule, une courte vidéo de présentation.
Si vous rencontrez des difficultés pour la lecture, rendez vous sur medias.spip.net où le fichier source est téléchargeable.

Évolutions

  • v3.6.0 : permet de réordonner les documents des albums par glisser-déposer

Des albums, pour quoi faire ?

Dans sa première version, le plugin permettait d’insérer des galeries d’images au fil du texte, dans les articles.

Depuis la version 2, les albums sont des objets éditoriaux à part entière, aussi la portée du plugin est plus générale : il sert à la gestion de groupes de documents.

⇒ Des groupes de documents

Un album, c’est donc un conteneur pour une série de documents.
Précisons le bien, si le terme « album » évoque des albums d’images, il peut contenir tout type de document : images, bandes-son, vidéos et autres.
Un même document peut appartenir à plusieurs albums : toutes sortes de combinaisons sont envisageables.

Les albums sont des groupes de documents

⇒ Albums et documents liés à un objet

En SPIP 3, les documents liés à un objet sont présentés sous forme de 3 groupes : « illustrations », « portfolio » et « documents ». Leur finalité est expliquée dans cet article, mais retenons qu’il s’agit d’une séparation arbitraire pensée pour les articles.
Dans cette documentation, on va se référer à ces documents comme des documents « individuels », par opposition au documents regroupés au sein d’albums.

Les documents individuels et les albums sont indépendants et n’ont pas d’incidence l’un sur l’autre : on peut continuer à gérer les documents individuels comme avant.
En pratique, vous avez le choix au moment d’ajouter des documents à un objet : ils peuvent être ajoutés individuellement, ou regroupés au sein d’albums.

Albums et documents liés
Documents individuels et regroupés aux seins d’albums

Installation & configuration

L’installation se fait comme n’importe que plugin.
2 tables vont être ajoutées : spip_albums et spip_albums_liens.

Des plugins supplémentaires doivent être installés si vous souhaitez bénéficier du formulaire qui permet de personnaliser les balises <album> à insérer dans le texte. Il s’agit de dépendances optionnelles.

Une fois l’installation effectuée, un passage sur la page de configuration est ensuite nécessaire. Elle est constituée de 2 onglets.

⇒ Onglet « options »
L’option principale permet de définir sur quels objets les albums pourront être ajoutés.
2 autres options permettent de proposer un titre par défaut lorsqu’on ajoute un nouvel album à un objet, et d’activer le déplacement de documents par cliquer-glisser.

⇒ Onglet « outils »
Un formulaire permet de migrer des articles en albums.
Il est prévu dans le cas où l’on se servait d’articles comme de pseudo albums, et se charge de créer des vrais albums à l’identique à partir de ceux-ci.

Utilisation

Les albums peuvent être autonomes ou liés à d’autres objets éditoriaux.

⇒ Dans le cas d’albums autonomes, on les créera depuis la barre d’outil rapide ou depuis la page des albums, comme n’importe quel objet éditorial.

⇒ Dans le cas d’albums liés à des objet éditoriaux, leur gestion est assez similaire à celle des documents : on peut gérer les albums depuis la fiche d’un objet ou lorsque celui-ci est en cours d’édition.

Gestion des albums sur la fiche d’un objet

Sur la fiche d’un objet éditorial, les albums font suite aux documents. L’interface permet d’ajouter de nouveaux albums ou des albums existants, d’éditer leur texte et de manipuler leurs documents.

Albums et documents liés
1) documents « individuels » 2) documents regroupés au sein d’albums

⇒ Ajouter des albums

Le bouton « Ajouter un album » fait apparaître un formulaire proposant deux méthodes [1] :

Créer et remplir un nouvel album. Titre et descriptif sont optionnels : laissé vide, le titre sera rempli à posteriori avec « Nouvel album N° X ».

Choisir un ou plusieurs albums existants : on peut parcourir la liste, ou rentrer directement les numéros des albums.

Ajouter un album à un objet éditorial
1) Créer et remplir un nouvel album 2) Choisir un ou plusieurs albums existants

⇒ Editer un album sur place

Les albums peuvent être édités sur place. Pour l’édition complète (gestion des auteurs, des mots-clés etc.), on se rendra sur leur fiche.

Editer le texte : une icône apparaît au survol du header, elle permet d’afficher le formulaire d’édition du titre et du descriptif.

Ajouter des documents : un lien situé en bas fait apparaître le formulaire d’ajout de documents.

Manipuler les documents : les boutons d’édition apparaissent au survol de chaque document.

Il est également possible, sous certaines conditions, de déplacer des documents entre albums par cliquer-glisser.

Édition rapide d’un album
1) Editer titre et descriptif 2) Ajouter des documents 3) Modifier les documents

⇒ Retirer des albums

Pour retirer un album, cliquer sur le bouton qui apparaît au survol, en bas de chaque album.
Lorsqu’il y a plusieurs albums, un bouton présent à la fin de la liste permet de tous les retirer d’un coup.

Gestion des albums lors de l’édition d’un objet

Pendant l’édition d’un objet, la gestion des albums s’opère au même endroit que celle des documents, dans la colonne de gauche.
Quand l’objet peut recevoir à la fois des documents et des albums, un menu permet de basculer entre les deux.

Albums et documents lors de l’édition d’un objet
1) Gestion des documents 2) Gestion des albums

⇒ Ajouter, éditer et retirer les albums

On gère les albums de la même façon que lorsqu’on se trouve sur la fiche de l’objet : même formulaire pour ajouter des documents, mêmes possibilités pour éditer les albums et manipuler leur documents.


⇒ Insertion des balises <album> dans le texte

Les albums insérés dans le texte au moyen de la balise <albumX> seront automatiquement associés à l’objet : ce comportement est similaire à celui des balises <doc>, <img> et <emb> des documents.

Un formulaire permet de personnaliser les balises de chaque album : choix de la variante, alignement, paramètres des modèles, etc.

Important : pour bénéficier de cette fonctionnalité, des plugins supplémentaires doivent être installés. Consultez la section sur l’installation.

Personnaliser la balise d’un album
En mode édition, un formulaire permet de personnaliser la balise de chaque album en vue de l’insérer dans le texte.

Les modèles

L’apparence, la structure et certains paramètres évoluent par rapport aux versions 1 et 2. Consultez les notes sur la rétro-compatibilité.

2 modèles « album » sont proposés : le modèle de base est une vue en vignettes, complété d’une variante avec une vue en liste.
Par défaut, ces 2 modèles produisent un affichage minimaliste : titre, descriptif, et autres éléments "superflus" ne sont pas affichés à moins d’utiliser les paramètres adéquats (détaillés plus bas).
De même, la feuille de style chargée sur le site public ne contient que le strict minimum.

Ces 2 modèles ne prétendent pas répondre à tous les cas de figure. Les usages possibles sont trop vastes pour être tous pris en compte par un modèle générique : listes de lecture audio ou vidéo, diaporamas, etc.
Pour vos besoins spécifiques, ajoutez des variantes du modèle.

⇒ Modèle <album> : vue en vignettes

Modèle album par défaut : vue en vignettes

Ce modèle est prévu pour afficher des séries d’images : les documents sont affichés sous forme de vignettes cliquables.
Il est basé sur Tiny Typo, la base CSS de Romy Têtue.
Les images peuvent être retaillées et recadrées pour obtenir un affichage uniforme, par défaut elles sont retaillées selon une hauteur de 100 pixels.

La structure HTML de base est la suivante (avec #HTML5 activé) :

<figure class="album vignettes figure">
    <ul>
        <li>
            <a href="#"><img src="..."></a>
        </li>
    </ul>
    <figcaption>...</figcaption>
</figure>

⇒ Modèle <album|liste> : vue en liste

Modèle album, variante sous forme de liste

Cette variante affiche les documents sous forme d’une simple liste. Elle est donc adaptée à tout type de documents.

La structure HTML de base est la suivante :

<div class="album liste">
    <ul class="spip">
        <li>
            <a href="#">...</a>
        </li>
    </ul>
</div>


⇒ Paramètres des modèles

Paramètres communs aux 2 modèles
Paramètre Description
titre « oui » pour afficher le titre
N’importe quelle chaîne pour un titre personnalisé.
balise_titre Pour encapsuler le titre dans une balise, sans les chevrons.
→ strong, h4, etc.
descriptif « oui » pour afficher le descriptif
par Tri des documents, défaut : « titre »
→ date, titre, media, fichier, extension, taille
media Pour restreindre à un type de document
→ image, file, audio, video
Paramètres propres à la variante « vignettes »
Paramètre Description
largeur Largeur maximale des vignettes
hauteur Hauteur maximale des vignettes, défaut : 100 (pixels)
recadrer « oui » pour recadrer les images
label « oui » pour afficher le titre de chaque document
Paramètres propres à la variante « liste »
Paramètre Description
metas « oui » pour afficher les infos complémentaires de chaque fichier, ou une liste d’éléments séparés par des virgules :
→ extension, taille, dimensions


⇒ Ajouter des modèles

Pour que vos propres variantes du modèle soient prises en compte par le formulaire de personnalisation des balises, il faut créer un fichier YAML en plus du squelette HTML.

Ce fonctionnement est inspiré par celui du plugin Insérer Modèles : chaque fichier YAML décrit le modèle et ses paramètres, sous forme de saisies. La syntaxe est identique, avec toutefois 2 éléments supplémentaires :

  • alias : nom de la variante
  • description : description de la variante (optionnelle)

Pour assurer la compatibilité avec le plugin cité plus haut, 4 paramètres sont obligatoires : modele, id_modele, id_album et variante.
Les 3 premiers étant identiques pour toutes les variantes, ils sont regroupés dans un fichier inc-yaml/album-compat.yaml qu’il suffit d’inclure.

Pour les saisies, une option supplémentaire config permet d’avoir comme valeur par défaut un réglage stocké dans la table spip_meta.
Dans l’idée, config:'truc' revient à faire 'defaut'=>lire_config('truc') en php.

Exemple : Imaginons un plugin fournissant une variante « diaporama ».
Ce modèle accepterait entre autre un paramètre vitesse dont la valeur par défaut serait enregistrée dans une méta du plugin. Le squelette HTML serait nommé album_diaporama.html et le fichier YAML album_diaporama.yaml.
Ce dernier ressemblerait à ça :

nom: 'un album (diaporama)'
logo: 'prive/themes/spip/images/album-24.png'
icone_barre: 'album-diaporama.png'
alias: 'Diaporama'
parametres:
  - 'inclure:inc-yaml/album-compat.yaml'
  -
    saisie: 'hidden'
    options:
      nom: 'variante'
      defaut: 'diaporama'
  -
    saisie: 'input'
    options:
      nom: 'vitesse'
      config: 'plugin/vitesse'
  - le reste des saisies...

En cas de doute, vous pouvez prendre la variante « liste » comme référence.

Albumothèque

Albumothèque

L’albumothèque est l’équivalent de la médiathèque, pour les albums.

Les filtres situés dans la colonne de gauche sont prévus pour sélectionner les albums en fonction de leurs documents et de leurs liaisons avec les objets : articles, auteurs, mots-clés etc. Attention, il ne s’agit pas de menus, mais bien de filtres : un clic pour activer, un autre pour désactiver.

Des champs avec autocomplétion permettent de trouver un objet précis.
Par exemple, pour afficher les albums liés à un article en particulier, il faut cliquer sur l’icône à droite du filtre « articles », puis rentrer les premières lettres du titre ou son numéro : les articles correspondants vont apparaître dans une liste déroulante, cliquer sur un résultat va mettre à jour la liste des albums.
La fontion d’autocomplétion ne va chercher que les objets ayant un lien avec les albums.

Albumothèque : filtres
Des champs avec autocomplétion permettent de trouver les objets liés aux albums.

Déplacer des documents entre albums par cliquer-glisser

Il est possible de déplacer les documents entre albums par cliquer-glisser. L’option doit être activée dans la page de configuration, et vous devez y avoir l’autorisation.

Gardez en tête qu’il s’agit d’une fonctionnalité un peu expérimentale !

Lorsqu’on entame le déplacement d’un document, les albums pouvant recevoir celui-ci sont surlignés d’une bordure verte, il suffit d’y relacher le document. Dès qu’un document à été déplacé, un formulaire apparaît en bas de la liste pour enregistrer les modifications. On peut cependant effectuer plusieurs déplacement d’affilée avant de les enregistrer.

Notez qu’il est possible de manipuler également les documents « individuels » liés aux objets.

Déplacer des documents entre albums par cliquer-glisser
1) Effectuer un ou plusieurs déplacements 2) Valider avec le formulaire qui apparaît en bas

Boucles & critères

⇒ Critère {orphelins}

Le critère {orphelins} permet de sélectionner les albums sans lien avec un objet éditorial (on qualifiait ces albums « d’autonomes » plus haut).

⇒ Jointures

Les albums ont une jointure automatique pour tous les objets (cf. déclaration de la base).

Dès qu’un qu’un id_xxx est présent dans l’environnement, on peut donc sélectionner les albums liés à l’objet sans avoir à faire de jointure explicite avec la table de liens :
<BOUCLE_albums(ALBUMS){id_xxx}>

Attention, pour {id_auteur}, le comportement est différent :

  • <BOUCLE_albums(ALBUMS){id_auteur}> sélectionne les albums de l’auteur (d’après la table spip_auteurs_liens).
  • <BOUCLE_albums(ALBUMS){objet=auteur}{id_objet=#ID_AUTEUR}> sélectionne les albums liés à l’auteur (d’après la table spip_albums_liens).


⇒ Sélectionner les albums en fonction de leurs documents

En faisant une jointure avec la table spip_documents, on peut utiliser certains critères des documents :
<BOUCLE_albums(ALBUMS documents){documents.critere=xxx}>
Quelques exemples avec les critères les plus utiles :

  • {documents.media IN image,audio} : albums contenant des images ou des bandes-sons.
  • {documents.id_document=x} : albums contenant le document n°x.
  • {documents.titre LIKE %truc%} : albums contenant des documents dont le titre ou le nom de fichier comprend le terme « truc ».
  • {documents.extension == mp3|ogg|oga} : albums contenant des fichiers mp3 ou ogg audio.
  • {documents.taille > 1000000} : albums contenant des documents d’une taille supérieure à 1Mo [2].

Autorisations

Voici comment sont définies certaines autorisations particulières (les administrateurs complets peuvent tout faire).

  • Modifier un album : il faut être auteur de l’album et avoir le droit de modifier tous les objets auquel l’album est lié.
  • Ajouter un album à un objet : il faut que l’objet soit activé dans les options, et avoir le droit de le modifier.
  • Déplacer des documents entre albums : il faut que l’option soit activée, et dans le contexte d’un objet, avoir le droit de modifier tous les albums liés.
  • Supprimer un album : il faut qu’il soit vide, inutilisé et non publié.

Rétro-compatibilité

Modèles

La syntaxe de la version 1, qui avait disparu de la version 2, est à nouveau supportée dans cette version : <album|id_article=x> et <album|id=x,y,z>

La structure du modèle de base a changé, afin notamment de respecter l’usage des balises <figure> et <figcaption> en HTML5.

Visuellement, quelques altérations ont eu lieu :
-  par défaut, les titres sont cachés.
-  le titre et le descriptif du modèle de base passent en bas.

Changement de quelques paramètres :
-  vignettes & liste : titraille est supprimé
-  vignettes & liste : balise_titraille est déprécié au profit de balise_titre
-  liste : infos est déprécié au profit de metas

Divers

-  Le critère {contenu} apparu dans la version 2 est supprimé : on peut utiliser à la place le critère {documents.media == x} avec une jointure (ALBUMS documents) pour un résultat similaire.
Voir la section sur les jointures.

Paramétrage fin par les constantes

-  Constante _ALBUMS_TITRE_COURT : si vous insérez define('_ALBUMS_TITRE_COURT','oui'); dans votre mes_options.php, le titre des images sous les images sera réduit à leur titre et n’incluera pas les indications techniques.

Notes

[1] Techniquement, le formulaire « ajouter_album » est une fusion des formulaires « editer_album » et « ajouter_document »

[2] 1000000 octets = 975ko, mais on ne va pas chipoter


La version 2 du plugin est documentée ici.
Elle a en quelque sorte servi de transition entre la version 1 et la présente version, qui est la version « correcte » pour SPIP 3. La branche 2 n’est plus amenée à évoluer, et ne recevra que des corrections de bugs.
D’ailleurs, n’hésitez pas à signaler les bugs de la version 2 sur ce forum, en précisant bien quelle version est concernée.

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

95 discussions

  • 2
    Aude

    Bonjour

    Je viens de migrer un site de 3.0.16 en 3.0.17, et j’en ai profité pour migrer le plugin album aussi. Ca fonctionne correctement (une fois que j’ai compris que la taille par défaut des vignettes était prise en compte à ce niveau là : j’avais mis 500px pour une autre utilisation dans le site, du coup je suis redescendu à 100 px pour avoir les vignettes les unes à côté des autres... après avoir trifouillé pour mon code css pendant 1 heure pour comprendre d’où ça venait !).
    Bref, j’ai une question mais je ne sais pas si mediabox ou albums qui est concerné : Quand je clique sur une des vignettes pour afficher la photo, j’ai dessous le Titre de la photo, son extension (JPEG en l’occurence), son poids et sa taille en px.
    Je ne souhaiterai avoir que le titre (le reste n’intéresse personne en fait).
    Où est-ce que je peux paramétrer cela ?

    Merci d’avance pour la réponse !

    • tcharlss

      Bonjour,

      ça tombe bien une option a été rajoutée il y a quelques jours exactement pour ça.
      Dans mes_options.php, ajouter :

      define('_ALBUMS_TITRE_COURT',false);

      Cela dit, on pourrait peut-être faire l’inverse : par défaut afficher la version courte, et la version complète en passant une option _ALBUMS_TITRE_LONG par ex. À voir.

    • Aude

      Bonjour Tchariss

      merci pour ta réponse rapide, t’es au top ;-)

      Ca marche nickel !
      Sauf que pour moi il faut que je mette define(’_ALBUMS_TITRE_COURT’,true) ;
      pour activer le titre court du coup.

    Répondre à ce message

  • CVD75013

    Bonjour,
    J’ai modifié le document doc.html que j’ai rajouté en surcharge dans squelettes/contenu pour que mediabox m’indique uniquement le titre du document ce qui fonctionne très bien si le document se trouve dans porte folio mais si il se trouve dans album, il me rajoute le type et la taille de l’image.

    Étant novice en spip, c’est certainement très simple mais je ne vois pas où intervenir.
    Si quelqu’un a une idée, merci d’avance.

    Répondre à ce message

  • 3
    Edgie

    Bonjour,

    J’utilise Albums 3.3.9 sous SPIP 3.0.5.
    Les photos des albums apparaissent sur le site publique sous forme de liste

    <li> et <ul>

    mais je souhaiterais voir ces photos alignées les unes à côté des autres.
    Comment faire ?

    Merci de votre réponse.
    Cordialement

    • tcharlss

      Bonjour,
      S’il s’agit des albums joints à un article, mais non insérés dans le texte, c’est fait exprès. Ils sont censés s’afficher comme les documents-joints, donc sous forme de liste.
      S’il s’agit d’albums insérés dans le texte, là affectivement il y a un problème.
      Il y a une URL où on peut voir ça ?

    • tcharlss

      (après avoir vu l’URL)

      On dirait que la feuille de style des albums n’est pas chargée. Possible que la balise #INSERT_HEAD_CSS ne soit pas présente dans vos squelettes. Si c’est voulu, il faut insérer la feuille de style des albums à la main : <link rel='stylesheet' type='text/css' media='all' href='[(#CHEMIN{css/albums.css})]' />

    • Edgie

      Super !
      J’ai rajouté : <link rel='stylesheet' type='text/css' media='all' href='[(#CHEMIN{css/albums.css})]' /> dans mon head.html et cela fonctionne parfaitement !
      Merci :-)

    Répondre à ce message

  • 3
    Laurent207

    Bonjour,

    Je viens d’installer SPIP 3.0.17, Albums 3.3.9, YAML 1.5.2 et saisies 2.2.0. Tous les plugins ont été installé via l’installation automatique.

    Après avoir, créé un album et publié ce dernier en ligne, je clique sur « voir en ligne », ce qui a pour effet d’ouvrir un nouvel onglet (http://www.e-joutes.fr/eeg/spip.php?album1&var_mode=calcul)

    Là j’obtiens une erreur 404 avec un tableau dans le coins indiquant :
    1 Erreur(s) dans le squelette
    Aucun squelette album.html n’est disponible...

    Il ne me manque pas un truc ?

    • tcharlss

      Bonjour,
      Pour l’instant le plugin ne propose pas de squelette pour la page albums, il faudrait donc soit enlever ce lien de prévisualisation, soit ajouter le squelette adéquat.
      C’est ajouté dans la todolist, merci pour le retour.

    • Laurent207

      Autant pour moi, j’ai trouvé, il suffit d’écrire : <album1|titre=oui|descriptif=oui|label=oui>
      Un petit exemple dans la doc sera sympa pour ceux qui ne connaisse pas spip ça pourrai aider ^^.

      J’arrive à peut prêt à ce que je veux mais le titre et le descriptif s’affiche en bas, sous les photo. Est-il possible de les afficher avant ?

    • tcharlss

      Oui c’est possible avec position_legende=top. Ce n’est pas encore dans la doc, il faut que je mette celle-ci à jour.

    Répondre à ce message

  • Laurent207

    Bonjour,

    Je trouve ce plugin très bien, mais une fois que je veux cliquer sur « voir en ligne » (après avoir publié en ligne l’album), j’obtiens :
    Aucun squelette album.html n’est disponible...

    SPIP 3.0.17
    Albums 3.3.9
    YALM 1.5.2
    Saisie 2.2.0

    Mon site est encours de constrution, il est en ligne sur un environnement de test avant migration.
    http://www.e-joutes.fr/eeg/spip.php?album1&var_mode=calcul

    Répondre à ce message

  • 4
    christiand.

    Bonjour,

    J’utilise Albums qui est très bien pour replacer des documents par rapport au texte mais je n’arrive pas à faire que les docs -ici des images- apparaissent dans un ordre donné.

    D’ailleurs, je ne sais pas trop bien quel est l’ordre car les photos ne sont pas présentées en ordre chronologique mais un peu en vrac.

    Il y a une solution ?

    Merci d’avance pour vos réponses.

    Christian

    • tcharlss

      Bonjour,

      Par défaut les documents d’un album sont classés par type de media (image | audio | video etc.), puis par titre / nom de fichier. On peut changer ce tri au moyen du paramètre par, les valeurs possible sont id_document | titre | fichier | media | mode | extension | taille.

      Mais pour être clair, pour l’instant il n’y a pas vraiment de possibilité d’ordonner manuellement les documents d’un album. On pourrait être tenté de faire par=titre et de numéroter les titres des documents : 1.document x, 2. document y, etc. mais comme un même document peut être utilisé dans plusieurs albums ce n’est pas une solution viable.

      Il est prévu de pouvoir définir leur position manuellement par glisser-déposer, comme le fait le plugin mosaïque.
      Un jour proche !

    • christiand.

      Merci pour ta réponse, Tcharlss.

      Ca donnerait ça : <albumxx | par=titre |> ?

    • tcharlss

      Oui c’est ça. Enfin, pour être exact : <albumxx|par=titre> (pas d’espace ni de « | » à la fin).

    • christiand.

      Merci Tcharlss pour ta réponse et ces précisions.

      Mais ça ne marche pas. Les images restent dans cet ordre qui n’est pas le bon. J’ai essayé de mettre <albumxx|doc12282|doc12283|doc12284>, ce sont les noms des images, mais rien n’y fait. Spip garde son ordre qui n’est pas le bon...

    Répondre à ce message

  • 21
    Sylvain

    Bonjour,

    j’ai un soucis avec la version 3.3.1 (SPIP 3.0.17), suite à la mise à jour de quelques sites qui étaient précédemment sous :

    • Album 2.2.13
    • SPIP 3.0.13

    En fait dans les albums photos contenant des documents (images) assez ancien, les vignettes ne se génèrent pas, j’ai simplement l’icone JPEG (spip) par défaut.
    J’ai par exemple un cas assez révélateur, un album avec 5 docs (dont 2 anciens) et seul les docs récents ont leur vignette générée. Les autres ont simplement l’icone JPEG.

    Je ne vois pas d’où viens l’erreur (vidé les cache, regardé les logs, GD2 ok), et je n’arrive pas à reproduire cela sur mon site de dev/test (les documents étant récents).
    Dans le backoffice les vignettes sont bien là.
    Ce sont des sites qui dates (si ça peut aider) SPIP 1.9 et même plus vieux.
    Et qui peut-être n’ont pas suivit une ancienne mise à jour importante concernant la structure des document ?

    En l’état je vais « patcher » cela en copiant le modèle « album.html » dans mon « squelette/modeles »
    ou je remplace la vignette :

    [(#GET{src}|balise_img{#GET{titre_document_long},vignette}|inserer_attribut{aria-hidden,true})]

    pas ce qu’il y avait dans l’ancien modèle :

    [(#LOGO_DOCUMENT
	|image_reduire{#ENV{largeur,0},#ENV{hauteur,85}}
	|inserer_attribut{class,spip_logos}
	|inserer_attribut{alt,#GET{titre}}
)]

    PS : note aux devs, si je peux aider, mettre un squelette spécifique pour tester ou autre, hésitez pas.

    Merci d’avance,
    — 
    Sylvain

    • tcharlss

      Bonsoir,
      Et pour les images jointes aux articles (portfolio/documents joints), ça fait pareil ?
      L’option « Générer automatiquement les miniatures des images » dans les options avancées est toujours activée ?
      Peux-tu essayer [(#FICHIER|image_reduire{100,100})] dans ton squelette pour voir si ça fonctionne ?

    • Sylvain

      Hello,

      merci pour ton retour rapide, oui la génération des vignettes et GD2 sont bien activés

      j’ai pu extraire sur un site de test des éléments pour reproduire « le bug »
      http://test.agilium.net/TEST-852

      avec donc dans le modèle album.html les 3 types de vignettes, pour chaque document :

      • l’original [(#GET{src} (...)
      • l’ancien [(#LOGO_DOCUMENT|image_reduire (...)
      • le [(#FICHIER|image_reduire (...)

      puis 2 albums :

      • avec que des anciens docs (très anciens surement émis sous SPIP 1.8)
      • avec des anciens et nouveaux docs

      Je t’ai mis tout le détails dans la page, là on a tous les cas de figure

      Conclusion : seuls ces anciens documents posent problème. D’où ma supposition ces docs datent d’avant la refonte des docs dans SPIP, je crois lors de l’arrivé du plugin par défaut « Medias » (je crois).

      Merci d’avance.

    • Sylvain

      Une idée ?

    • tcharlss

      Bonjour,
      Cool la page de tests, ça c’est du retour de bug !
      Je pense finalement avoir une petite idée de l’origine du problème.
      Dans la dernière itération du modèle, on fait le test suivant : si le document est une image on affiche une miniature, sinon on affiche juste l’icône du document. Pour ça on se repose sur la balise #MEDIA qui peut avoir la valeur image, audio, video ou document. Il y a des chances que cette balise soit vide pour les anciens documents issus de SPIP 1.8, et du coup le test échoue.

      Que renvoie [(#MEDIA|print)] pour les anciens documents ?

    • Sylvain

      bien vue !

      http://test.agilium.net/TEST-852

      ça renvoi «  ? »

    • tcharlss

      Ok, c’était donc ça, c’est remédiable facilement. Est-ce que #EXTENSION retourne quelque chose pour les anciens documents ?

    • tcharlss

      Hop, ça devrait être fixé dans la 3.3.2. Merci pour les retours

    • Sylvain

      Oui #EXTENSION retourne « jpg »

    • Sylvain

      avec la mise à jour 3.3.2 ... c’est pas bon ?!
      toujours le problème de vignette pour les anciens doc

      et au recalcule de la page il indique 2 erreurs du modèle :

      1 	Filtre ) non défini	   /  	   /  	0
2 	Argument manquant dans la balise SET	plugins/auto/albums/v3.3.2/modeles/album.html	_documents_album	120
    • tcharlss

      Très certainement un problème de cache.
      Essaye avec un var_mode=calcul (chez moi, 2 fois d’affilée).

    • Sylvain

      non, bin non ... ça fait plus de 10 ans que j’utilise SPIP.

      J’ai bien sur tout tenté, y compris vidé le cache « Images calculées automatiquement ».

    • tcharlss

      Ouuuups, la boulette ! J’avais oublié un « } » dans la dernière m.a.j.
      Tout devrait être réparé dans la 3.3.3.

    • Sylvain

      plus d’erreur de squelette

      mais toujours le problème de vignette pour les anciens doc

    • tcharlss

      Est-ce que tu peux me faire un retour avec ce squelette stp ? http://spip.pastebin.fr/39210 (à placer dans squelettes/modeles).
      Ou encore mieux, faire un screen d’une ligne d’un ancien document dans phpmyadmin.

    • Sylvain

      Oui ! c’est ce que je te demandais au tout début :-p

      Là, ça me semble plus clair :
      http://test.agilium.net/TEST-852

      merci encore hin :-)

    • tcharlss

      Mmmmh, bizarre tout ça. Déjà je ne parviens pas à reproduire le bug chez moi.
      Et puis dans le retour, si #MEDIA ou sql_getfetsel renvoie quelque chose, alors #GET{media} devrait aussi renvoyer quelque chose, ce qui n’est pas pourtant le cas.

      Je vais avoir besoin d’une ligne phpmyadmin pour y voir plus clair : peux-tu exporter une ligne d’un document fautif, dans la table spip_documents, au format YAML stp ?

    • tcharlss

      Et un autre squelette de débug au cas où : http://spip.pastebin.fr/39212

    • Sylvain

      squelette mise à jour
      http://test.agilium.net/TEST-852

      et le YAML

      %YAML 1.1
---
# base.spip_documents
-
  id_document: 185
  id_vignette: 0
  titre: "le lac 60"
  date: "2009-04-17 11:25:38"
  descriptif: ""
  fichier: "jpg/le_lac_60.jpg"
  taille: 72892
  largeur: 500
  hauteur: 335
  mode: "image"
  distant: "non"
  maj: "2015-03-25 10:25:52"
  statut: "publie"
  date_publication: "1970-01-01 01:00:00"
  brise: 0
  credits: ""
  media: "?"
  extension: "jpg"
...

      Encore une fois, je soupçonne qu’une mise à jour de SPIP n’a pas correctement mis à jour ces anciens docs.
      Genre un saut de version trop important, car ces sites n’étaient plus mis à jour depuis longtemps, et ne pouvais pas faire des mises à jour successives 1.9 -> 2.x -> 3.x

    • tcharlss

      Aaaaah, mais la valeur de media est littéralement « ? » chez toi ? Ok, tout s’explique. Je pensais que tu avais changé l’affichage au niveau du squelette en cas de champ vide, du coup j’avais mal interprété les retours.
      En tout cas ça me semble étrange de se retrouver avec cette valeur dans ce champ, en cas d’erreur de mise à jour il devrait être laissé vide.
      Bref, on doit pouvoir contourner ce problème, peux-tu me confirmer si les vignettes sont bien là sur le squelette suivant ? http://spip.pastebin.fr/39214
      Si c’est ok je reporterai sur le plugin.

    • tcharlss

      Merci pour les tests et les retours !

    Répondre à ce message

  • 17
    flouvel

    Bonjour,
    Sauf erreur de ma part,
    un rédacteur ne peut modifier un album publié dont il est l’auteur (normal, c’est ainsi pour les article aussi),
    malgré que l’album soit dans un espace wiki déclaré par le plugin autorité (alors que là, c’est possible pour article, et aussi pour un objet éditoriale simple que j’ai créé avec la fabrique)
    Est-ce que vous voyez le moyens de résoudre cela ?
    (je voudrais que les rédacteurs puissent modifier les albums, qu’ils en soient auteur ou non)

    • flouvel

      ps. en fait cela semble assez logique, albums passant par une table liens pour inclusion. De même que documents. J’ai oublié de vérifier si les rédacteurs pouvais modifier les documents. Je vois ça.

    • flouvel

      oui, un rédacteur peut modifier les documents,
      -  s’il en est l’auteur d’un article publié si le plugin autorité le permet (coché : Auteur modifie article, chaque rédacteur peut modifier les articles publiés dont il est l’auteur)
      -  même s’ils n’en est pas l’auteur si l’article est dans espace wiki défini par autorité.
      Logique.

      Dans le cas général (plugin autorité désactivé) pour un album publié et ses documents un rédacteur ne peut rien faire. Normal, idem pour article.
      -  dans espace wiki défini par autorité un rédacteur peut modifier un album publié et les documents qu’il contient seulement s’il en est l’auteur ?...
      -  (il n’y a pas dans autorité d’option à cocher Auteur modifie album, chaque rédacteur peut modifier les albums publiés dont il est l’auteur)

      Bref et en Ccl° après ma surprise, de constater que les albums ne suivaient pas les règles du plugin autorités (comme l’aurait fait le portfolio), je pense que c’est assez normal : ça doit être à définir dans le plugin autorité ...

      désolé du dérangement ! mais si vous pouvez me confirmer que je me casse pas la tête pour rien.

    • tcharlss

      Bonjour,

      Merci pour les retours sur le plugin autorité, je ne l’utilise pas et ne l’avais donc pas pris en compte. Mais j’imagine qu’il est assez populaire, donc profitons en pour l’intégrer.
      Le plugin prend en charge les objets natifs de SPIP : articles, rubriques, forums, etc. À ma connaissance, il n’y a pas de mécanisme pour prendre en charge les autres objets, c’est pour ça qu’ils n’apparaissent pas dans le formulaire de configuration.

      Pour les albums, en général les autorisations (à ajouter, modifier, supprimer...) suivent la logique de celle des documents.
      Jusqu’à présent, pour avoir le droit de modifier un album, il fallait :
      -  soit être l’auteur, et avoir le droit de modifier tous les objets liés
      -  soit être administrateur complet

      Un nouveau cas de figure a été ajouté pour tenir compte des secteurs wiki :
      -  n’importe qui peut modifier un album utilisé une seule fois et lié à un rubrique ou un article situé dans un secteur wiki/ouvert.

      A tester dans la version 3.0.18, publiée demain.

    • flouvel

      super ! merci.

    • flouvel

      Bonjour,
      maintenant si on essaye de créer un nouvel album (quelque soit nos droits) : Ajouter un album, Titre qcq , Enregistrez => on a le message en rouge : Indiquez un fichier !
      Il semble qu’il faille maintenant absolument aussi joindre un document pour pouvoir enregistrer un nouvel album. C’est voulu ? (pas pratique pour notre besoin ...)

    • tcharlss

      Oui, c’est voulu. Le formulaire d’ajout d’albums récupère les vérifications du formulaire d’ajout de documents, d’où le message d’erreur en cas d’absence de doc.
      Cela dit on pourrait peut-être se passer de cette vérification, ça reste à voir.
      Dites m’en plus, dans quel cas de figure avez-vous besoin d’ajouter des albums vides ?

    • flouvel

      Dans tous les cas de figure, les albums sont créés pour pouvoir y ajouter des photos ;
      notre site

    • tcharlss

      En ce qui concerne l’ajout d’album à un objet, l’usage a un peu changé depuis la version 2.
      -  Avant, ça se faisait en 2 étapes : il fallait d’abord enregistrer l’album, et ensuite lui ajouter des documents. L’album étant de fait vide pendant un court moment, il fallait l’autoriser.
      -  Maintenant, ça se fait en 1 seule étape : on remplit -si on veut- titre et descriptif, on choisit les documents, et on enregistre. Donc il n’y a pas de raison que l’album soit vide, et pas de raison de l’autoriser.

      A moins qu’il y ait des cas de figure où l’on ait besoin d’ajouter des albums vides, mais dans ce cas il faut m’expliquer pourquoi.

    • flouvel

      Il y a peu avec la version 3 cela pouvait se faire en 2 étapes, les qcq utilisateurs de notre sites procédaient ainsi et n’ont donc pas compris pourquoi la création de l’album leur était maintenant refusée. Peut être que dans le formulaire de création de l’album il faudrait ajouter une petite note à côté de Documents : « vous devez téléverser au moins un document ».

      Pourquoi préférerions nous pouvoir ajouter des albums vides est dû à nos habitudes, notre pratique (l’escalade de blocs à Fontainebleau). Des grimpeurs ouvrent de nouvelles voies ou signalent des voies en faisant des relevés topographiques et décrivant ces voies, leur emplacement. D’autres grimpeurs avec ces informations iront parcourir les voies décrites et prendre des photos.
      Donc ne vous cassez pas la tête. Si ce ’besoin’ n’est pas partagé par d’autres, je signalerai juste dans notre mode d’emploi avec la petite note précédente d’attacher la photo [pas de photo] n°x et ça le fera ;

    • flouvel

      J’ai oublié de vous parler de cela : on ne peut publier les albums qu’on a créés (et les modifier sauf si on en est l’auteur. un rédacteur avait créé un album pour un autre, et du coup ne pouvait plus le modifier). Je pense que pour régler cela, dans un espace wiki, il faudrait de même ajouter la gestion des albums au plugin autorité ? (si c’est vraiment plus du côté Album qu’Autorité qu’il est le plus judicieux d’agir)
      Actuellement bien que soit coché sur autorité : ouvrir la publication — au-delà des administrateurs : aux rédacteurs du site , les albums ne sont pas pris en compte.

    • tcharlss

      En ce qui concerne la création d’albums vides, pour l’instant il y a 2 comportements légèrement différents, ce qui peut en effet porter à confusion :
      -  les nouveaux albums indépendants peuvent être vides (quand on les crée depuis la barre d’outils rapides ou sur la page des albums).
      -  les nouveaux albums associés aux objets ne peuvent pas être vides (quand on les crée sur la page d’un objet).
      Bon, je pense qu’autoriser la création d’albums vides dans touts les cas ne mange pas de pain, et ça unifiera le comportement. Je verrais ça dans la prochaine mise à jour.

      Pour le 2e point, je ne reproduis pas le problème (ou alors j’ai pas tout compris :p).
      J’ai une rubrique déclarée comme espace wiki, configurée comme suit :
      Voulez-vous ouvrir ce wiki — au-delà des administrateurs : ☑ aux rédacteurs du site.
      Un rédacteur ajoute un nouvel album à cette rubrique.
      → l’album est publié d’office.
      → Les autres rédacteurs on bien le droit de le modifier.

    • tcharlss

      Donc, le 1er point est « corrigé » (je mets des guillemets !) dans la version 3.0.19.
      Pour le 2e point, j’attends + d’infos.

    • flouvel

      1er point ok. j’ai màj vers 3.0.19
      2e point ok aussi ! (dsl j’avais oublié màj Autorité sur mon serveur test)
      merci.

    • flouvel

      Désolé, mes rédacteurs m’ont fait remarquer qu’il y avait toujours un problème :
      si l’album est lié à une brève dans un espace wiki ils ne peuvent le modifier.
      À prendre en compte dans albums_autorisations.php ?

      (sur notre site l’album est lié non à une brève mais à un circuit, nouvel objet éditorial que j’ai créé. mais, j’ai vérifié, avec une brève il en est de même. j’ai bein essayé d’ajouter breve mais pas d’id_secteur dans breve)

    • tcharlss

      Effectivement ça ne prenait en compte que les rubriques et les articles, pas les autres types d’objets. Maintenant, du moment que l’objet lié possède un champ id_secteur ça devrait être bon : cf. r86435.
      A moins que j’ai tout cassé, surprise dans la version 3.0.20
      Merci du retour en tout cas.

    • flouvel

      À priori ça ne marche pas. On peut modifier une brève dans un espace wiki mais pas son album. Le problème me semble être qu’il n’y a pas de champ id_secteur pour les brèves (pour mon objet ’circuit’ non plus mais là ce n’est pas un problème, je peux l’ajouter)
      Mais, euh.. ! on ne peut pas ajouter de document à une brève ! alors pourquoi s’embêter à vouloir y ajouter des albums ! ;-)

    • tcharlss

      On va y arriver !
      Je n’utilise jamais les brèves, effectivement il n’y a pas de champ id_secteur.
      Donc on regarde aussi si l’objet possède un champ id_rubrique, ce qui nous permet de retrouver le champ id_secteur, et donc d’obtenir l’autorisation.
      Guettez la prochaine mise à jour, ça devait marcher avec les brèves (et avec votre objet circuit en ajoutant un champ id_rubrique ou id_secteur).

      Sinon, on peut ajouter des documents aux brèves en les cochant dans le menu configuration > contenu du site > documents joints.

    Répondre à ce message

  • 3
    Mathieu

    Les plugins saisies, YAML et vérifier sont devenus obligatoires depuis quelques jours. Est-ce vraiment le cas ? Si j’en crois le commentaire sur cette modification c’est uniquement pour nredre certaines fonctionnalités plus visibles : http://zone.spip.org/trac/spip-zone/browser/_plugins_/albums/trunk/paquet.xml?rev=88152
    Ca m’embête un peu ayant toujours tenté de réalisé mes sites SPIP avec le moins de plugins possibles, j’étais bien content que Album me laisse le choix de les utiliser ou pas. :(

    • tcharlss

      Oui j’étais assez partagé sur le fait de rendre obligatoire ces 3 plugins, mais j’ai vraiment l’impression que beaucoup de gens passaient à côté du formulaire pour insérer des balises, qui simplifie bien les choses. Enfin, j’ai pas de chiffres, c’est juste mon sentiment.
      Ça me semble un moindre mal, car saisies et vérifier sont utilisés par plein d’autres plugins, YAML sans doute moins par contre.

      En fait idéalement, cette fonctionnalité devrait être confiée au plugin Insérer Modèles qui sert précisément à ça, mais il faudrait auparavant effectuer quelques changements sur le plugin.

      Donc pour l’instant, pas d’avis définitif, on peut toujours revenir dessus si besoin.

    • tcharlss

      Bon, finalement je suis revenu dessus pour l’instant, ce sont à nouveau des dépendances optionnelles avec la 3.3.2.
      Peut-être qu’à un moment, on mettra le plugin Insérer Modèles en dépendance obligatoire avec les modifs nécessaires intégrées, mais on en est pas encore là.
      Merci pour ton retour en tout cas.

    • Mathieu

      Super, merci !
      Bon l’autre « solution » serait d’intégrer les plugins saisies, YAML et vérifier à la « dist » :D

    Répondre à ce message

  • 3
    flouvel

    Bonjour,
    j’ai fait une màj, depuis, je crois, on ne peut plus modifier les albums d’un espace wiki ?...

    2° suggestion d’un petit détail de confort si possible :
    quand on ajoute un album celui ci est créé. Message : « L’album N° xxx a été ajouté », et il rejoint la liste des albums déjà créés, immédiatement accessible au-dessus ... sauf s’il y en a 150, car alors il se retrouve en fin de pagination (faut juste le savoir).
    s’il était possible d’ajouter un lien vers l’album dans le message « L’album N° xxx a été ajouté »
    (nos albums sont toujours modifiés après création : mots clés, géotagués, ...)

    • flouvel

      2e chose : bien qu’un rédacteur ne puisse modifier l’album ni y ajouter document, il peut détacher l’album (et sans sommation !).
      (bizarre, tout marchait impec jusqu’à il y a peu)

    • flouvel

      euh ! excusez pour le dérangement, j’étais repassé à la version 2, je sais pas pourquoi ni comment ? (en faisant une mise à jour avec le couteau suisse ??... peut être tout autre chose ...)

      reste donc juste la suggestion du "petit détail" si possible facile :
      ajouter un lien sur l’album dans le message : « L’album N° xxx a été ajouté »

    • tcharlss

      Quelques petits changements dans la prochaine maj suite à tes remarques :
      -  tri des albums du plus récent au plus ancien, plus pratique
      -  pagination par 10 au lieu de 5
      -  quand on ajoute un album, un lien dans le message mène à l’ancre de l’album en cours. Si l’album n’est pas visible parcequ’il y a une pagination en cours, le lien est ineffectif, mais c’est mieux que rien. on verra comment améliorer ça.
      -  quant aux problèmes de wiki et cie : ouf ! j’ai eu des sueurs froides un moment, là.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom