[spip-dev] Médoc / Médias responsive mod / 3.2

Dev
1

Je rebondis là dessus. Arno* vient d'ajouter du grain à moudre avec un nouveau plugin qui modifie aussi les comportements des modèles d'images et tente d'améliorer la situation (et qui ajoute des effets visuels / css, mais ce n'est pas le sujet ici).

https://seenthis.net/messages/559818
J'ai commenté https://core.spip.net/issues/3449

Il y a des choses intéressantes et certaines qui recoupent ce qu'on disait également sur un autre sujet :
- suppression de la notion de "portfolio"
- suppression des vignettes d'images cliquables
- titres & légendes sur les images systématiquement s'ils sont renseignés
- possibilité de forcer une largeur

Du coup… qu'est-ce qu'on va mettre dans Médias de 3.2, ça serait bien d'harmoniser un peu ; je commence à m'y perdre avec toutes ces possibilités.

MM.

2

J'ai commenté aussi sur le ticket mais je ne reçois plus aucune notification des tickets de redmine.

C'est que chez moi ?

La conjuration des notifications ?

3

C'était que chez moi.

4

Hello,

5

Sur ce point qui nous embête depuis de longues années, j'ai l'impression qu'il y a un certain consensus pour supprimer la notion de portfolio. IE: on aurait dans le privé, soit des documents images, soit des documents non images.

Comme expliquait Arno*, les "illustrations" «non vues» (ie: non utilisées dans les textes d'articles), et ne s'affichant donc pas sur l'espace public — car n'étant pas "portfolio"), étaient là car à l'époque il était impossible de téléverser des images en dehors des articles, sans les utiliser, or la Médiathèque permet cela maintenant. Pour cette utilisation spécifique des "illustrations", il y a donc une méthode de contournement. Mais peut être que l'usage était détourné pour d'autres applications…

Du coup, est-ce qu'il serait possible d'envisager la "non" migration suivante, tout en supprimant la notion de portfolio :

Option 1 :

- le champ "mode" est conservé (déclaré et créé) dans spip_documents / Medias (sans modification des documents existants)
- tout nouveau document a le mode "document" quelqu'il soit (le cas vignette serait à discuter)
- 2 listes dans l'espace privé : images, et documents (suppression de portfolio donc)
- suppression des {mode=...} sur les boucles des squelettes

Option 2 :

- le champ "mode" n'est plus déclaré / créé dans spip_documents / Medias
- le cas "mode=vignette" serait à migrer vers autre chose (id_parent ?)
- 2 listes dans l'espace privé : images, et documents (suppression de portfolio donc)
- suppression des {mode=...} sur les boucles des squelettes

De la sorte, avec l'option 1 ou 2, les anciens sites qui conserveraient leurs squelettes auraient toujours accès au champ "mode" (il n'est pas supprimé de la bdd lors de la migration). Il pourrait même éventuellement y avoir un plugin qui créerait le champ mode et l'affichage portfolio comme avant (mais bon… hum.)

L'option 1 à l'avantage que la plupart des plugins existants fonctionneraient encore sans créer d'erreur SQL à cause de l'absence du champ "mode").

L'option 2 à l'avantage de clarté (le mode disparait réellement sur les nouveaux sites), mais possiblement des squelettes vont râler lors de la migration ({mode=xxx} n'existerait pas).

L'inconvénient est justement… qu'il n'y a pas de migration des documents anciens en mode "image", vers quelque chose d'autre…

Est-ce que c'est une solution possible de migration cela ? ou pas du tout une bonne solution ?

MM.

6

Du coup… qu'est-ce qu'on va mettre dans Médias de 3.2, ça serait bien
d'harmoniser un peu ; je commence à m'y perdre avec toutes ces
possibilités.

Oui mais clairement, comme déjà dit par d'autres, il y a une différence entre :
- debug ou harmonisation : quand j'appelle tel modèle, seul ou avec tels paramètres, je DOIS savoir à quoi m'attendre, et que ce soit TOUJOURS la même chose qui s'affiche
- ajout de fonctionnalités

Le modèle <media> était tout autant une proposition qui faisait aussi les deux, et il faut à mon avis aussi le prendre en compte, dans ce qu'il proposait. Son nom différent n'était là que dans le but de ne rien casser à l'existant, mais si on commence à vraiment modifier les modèles par défaut de Médias, on peut très bien décider d'intégrer des choses de ce que fait <media> mais dans <doc> ou autre.

D'ailleurs au passage, un des points-clés du plugin <media> était qu'il ne fallait PAS qu'il y ait X modèles différents pour insérer les documents de spip_documents. On doit avoir un seul modèle en tête, ce qui est plus simple pour les utilisateurices, ce qui fait qu'illes savent toujours comment l'insérer. Ensuite illes peuvent "affiner" leur affichage en ajoutant plus ou moins de paramètres, mais par défaut ils n'ont rien à se rappeler sur quel modèle utiliser.

On peut par exemple considérer que ce serait bien de toujours utiliser <doc1234>, dans l'interface (même si les autres modèles seraient toujours là pour compat). C'est une possibilité, à discuter en tout cas.

Autre point dans les fonctionnalités manquantes (mais qui peut clairement être considérer comme un bug) : dans l'interface il y a un champ "Crédits" tout autant remplissable que les autres, et il n'est pas affiché par les (ou LE) modèle ! Ce n'est absolument pas normal pour les utilisateurices. 100% des gens qui le remplissent se demandent pourquoi ensuite cette info n'est affichée nulle part, parmi les gens chez qui j'ai fait des sites. Cela doit s'afficher avec titre et descriptif.

Pour ce qui est d'afficher ou pas ce dernier point (titre + descriptif + crédit), je pense qu'il faut toujours pouvoir ne pas les afficher. Par contre il est possible de considérer qu'on doit toujours les afficher par défaut ! Mais dans ce cas il faudrait un paramètre pour les retirer (du genre |legende=non). Et si ce n'est pas par défaut, il faut que leur affichage soit explicite, pas suivant des choix implicites (donc

7

RastaPopoulos a écrit le 13/01/2017 à 00:54 :

Autre point dans les fonctionnalités manquantes (mais qui peut
clairement être considérer comme un bug) : dans l'interface il y a un
champ "Crédits" tout autant remplissable que les autres, et il n'est pas
affiché par les (ou LE) modèle ! Ce n'est absolument pas normal pour les
utilisateurices. 100% des gens qui le remplissent se demandent pourquoi
ensuite cette info n'est affichée nulle part, parmi les gens chez qui
j'ai fait des sites. Cela doit s'afficher avec titre et descriptif.

Sur le principe, d'accord.
Mais dans le cas des documents distants, crédit est automatiquement rempli avec une URL ce qui donnerait un affichage "spécial"/bizarre.

D'autre part (je sais, c'est mal), j'ai profité sur un site que ce champ ne soit pas affiché pour y stocker une autre information (un ordre d'affichage en l’occurrence).
Je suppose que je ne suis pas le seul à avoir pensé à utiliser ainsi un champ non affiché par SPIP...
==> un define dans mes_options pour ne pas afficher les crédits par défaut ?

8

Hop,

On peut par exemple considérer que ce serait bien de toujours utiliser
<doc1234>, dans l'interface (même si les autres modèles seraient
toujours là pour compat). C'est une possibilité, à discuter en tout cas.

C'est justement ce que propose le plugin medoc :slight_smile:

Autre point dans les fonctionnalités manquantes (mais qui peut
clairement être considérer comme un bug) : dans l'interface il y a un
champ "Crédits" tout autant remplissable que les autres, et il n'est pas
affiché par les (ou LE) modèle ! Ce n'est absolument pas normal pour les
utilisateurices. 100% des gens qui le remplissent se demandent pourquoi
ensuite cette info n'est affichée nulle part, parmi les gens chez qui
j'ai fait des sites. Cela doit s'afficher avec titre et descriptif.

Oui, cf le ticket "roadmap" à ce sujet sur lequel je n'arrive pas à remettre la main ce matin (chelou).