[SPIP Zone] r109106 - in _plugins_/roles_documents/trunk

rastapopoulos · Février 24, 2018, 10:32

Ne proposer les rôles de logo et logo_survol que s'il sont activés dans la config, up de z

Details: Connexion · GitLab

Mouais, je trouve que c'est bâtard pour l'instant du coup.

Car justement sur tous les sites où j'avais le plugin rôle, j'avais
exprès *désactivé* les logos de SPIP, puisque je ne veux pas que les
gens puissent ajouter des anciens logos pourris qui vont pas dans la
médiathèque.

Si à terme ce bloc est remplacé (directement par ce plugin) là oui, mais
pour l'instant ça ne va pas du coup.

Par ailleurs, si on remplace ce bloc, faut voir ce que ça fait quand il
existait déjà un logo de l'ancienne méthode, faut quand même pouvoir le
voir et le supprimer. Je ne sais pas comment faire l'autre plugin de phenix.

M'enfin le mieux à mon avis ça serait une moulinette d'update qui
migrerait les anciens logos (sauf celui du site évidemment) vers la
médiathèque, en supprimant le patate1234.png au fur et à mesure.

--
RastaPopoulos

Michel_Bystranowski · Février 24, 2018, 12:12

Hello,

Le samedi 24 février 2018 à 11:32 +0100, RastaPopoulos a écrit :

Par ailleurs, si on remplace ce bloc, faut voir ce que ça fait quand
il
existait déjà un logo de l'ancienne méthode, faut quand même pouvoir
le
voir et le supprimer. Je ne sais pas comment faire l'autre plugin de
phenix.

Tu parles du plugins logos_roles ? Il gère ce problème en surchargeant
l'API chercher_logo pour qu'elle retourne en priorité les logos
enregistrés avec l'ancienne méthode. Par contre, dès qu'on remplace un
ancien logo, il est enregistré comme document, et on efface l'ancien
patate1234.png.

M'enfin le mieux à mon avis ça serait une moulinette d'update qui
migrerait les anciens logos (sauf celui du site évidemment) vers la
médiathèque, en supprimant le patate1234.png au fur et à mesure.

Il y a une moulinette pour faire ça dans logos_roles, ça se fait via le
formulaire de configuration. On peut choisir les objets éditoriaux que
l'on veut migrer.

Je me demande si logos_roles et roles_documents ne se marchent pas un
peu sur les pieds ici. Peut-être qu'il serait mieux de les fusionner ?
Ou alors que roles_documents ne s'occupe pas des logos ?
Ça serait pas mal d'éclaircir les rôles (ha!) de ces deux plugins,
sinon on risque de coder deux fois la même chose. Est-ce que « Rôles de
documents » se limite à activer les rôles sur les documents, ou est-ce
qu'il a aussi vocation à remplacer le système de logos ?

bystrano

rastapopoulos · Février 24, 2018, 12:45

Le 24/02/2018 à 13:12, Michel Bystranowski a écrit :

Est-ce que « Rôles de
documents » se limite à activer les rôles sur les documents, ou est-ce
qu'il a aussi vocation à remplacer le système de logos ?

Ah mon avis les deux, et c'est le cas déjà depuis le tout début puisque
le plugin déclare depuis sa création les rôles logo et logo_survol, sans
avoir à sur-découper en moult sous-plugins.

Sachant que le but dès l'origine c'est qu'à terme ça doit fournit dans
la dist, en plugin à part, ou même directement dans Médias. Puisque cela
fait des années que l'on dit qu'à terme les logos doivent être des
documents de la médiathèque (même si après il y a des interfaces dédiées
qui les affiche séparément, mais au niveau technique que ce soit bien
pareil).

--
RastaPopoulos

Michel_Bystranowski · Février 24, 2018, 3:04

Le samedi 24 février 2018 à 13:45 +0100, RastaPopoulos a écrit :

Le 24/02/2018 à 13:12, Michel Bystranowski a écrit :
>
> Est-ce que « Rôles de
> documents » se limite à activer les rôles sur les documents, ou
> est-ce
> qu'il a aussi vocation à remplacer le système de logos ?
Ah mon avis les deux, et c'est le cas déjà depuis le tout début
puisque
le plugin déclare depuis sa création les rôles logo et logo_survol,
sans
avoir à sur-découper en moult sous-plugins.

Et du coup tu verrais un intérêt à intégrer une partie de logos_roles
dans roles_document, dans la mesure où ça va dans ce sens ?

Je pense à la surcharge de inc/chercher_logo.php que je fais dans
logos_roles, qui ne fait qu'étendre l'API existante pour permettre de
trouver les logos enregistrés comme documents.

Il y a aussi la surcharge du critère {logo} pour qu'il utilise cette
API au lieu de la ré-implémenter dans son coin comme c'est actuellement
le cas dans le core.
Et enfin, la surcharge de action/editer_logo.php pour utiliser les
rôles.

Ces trois surcharges me semblent utiles dès que l'on veut utiliser les
rôles pour les logos. Elles permettent de faciliter la compat avec les
plugins existants, il leur suffit d'utiliser l'API habituelle de SPIP
pour les logos et tout fonctionnera pareil.
Pour moi ça aurait du sens qu'elles soient dans roles_documents, parce
que je vois mal dans quel cas on voudrait utiliser ce plugin tout en
refusant d'avoir de la cohérence dans les APIs.

Après, pour le reste des fonctionnalités de logos_roles, c'est vrai que
c'est différent. Le fait de créer facilement de nouveaux types de logos
et d'avoir l'interface qui va avec est effectivement autre chose. Je
comprend bien qu'on peut vouloir utiliser les rôles de document sans
pour autant vouloir tout ça en plus.

Qu'en penses-tu ?

--
bystrano

rastapopoulos · Février 24, 2018, 4:50

Le 24/02/2018 à 16:04, Michel Bystranowski a écrit :

Et du coup tu verrais un intérêt à intégrer une partie de logos_roles
dans roles_document, dans la mesure où ça va dans ce sens ?

Je pense à la surcharge de inc/chercher_logo.php que je fais dans
logos_roles, qui ne fait qu'étendre l'API existante pour permettre de
trouver les logos enregistrés comme documents.

Il y a un pipeline dans quete_logo pour ça normalement et Rôles de
documents l'utilise déjà. #LOGO_PATATE va déjà chercher le bon
spip_documents avec le rôle logo.

Il y a aussi la surcharge du critère {logo} pour qu'il utilise cette
API au lieu de la ré-implémenter dans son coin comme c'est actuellement
le cas dans le core.
Et enfin, la surcharge de action/editer_logo.php pour utiliser les
rôles.

Il faut que {logo} marche avec les documents joints oui.

Qu'en penses-tu ?

Et il faut surtout que ça surcharge l'interface dans sa boite dédiée à
droite avec le form pour ne pas qu'il y ait de confusion et que les gens
ne s'y perde pas.

Et la migration.

Et ça devrait être bon.

Le truc qui n'y rentra pas, c'est effectivement le fait de déclarer des
nouveaux "types" de logo, ça c'est vraiment une nouvelle fonctionnalité
supplémentaire.

--
RastaPopoulos

Michel_Bystranowski · Février 24, 2018, 7:15

Le samedi 24 février 2018 à 17:50 +0100, RastaPopoulos a écrit :

Le 24/02/2018 à 16:04, Michel Bystranowski a écrit :
> Et du coup tu verrais un intérêt à intégrer une partie de
> logos_roles
> dans roles_document, dans la mesure où ça va dans ce sens ?
>
> Je pense à la surcharge de inc/chercher_logo.php que je fais dans
> logos_roles, qui ne fait qu'étendre l'API existante pour permettre
> de
> trouver les logos enregistrés comme documents.
Il y a un pipeline dans quete_logo pour ça normalement et Rôles de
documents l'utilise déjà. #LOGO_PATATE va déjà chercher le bon
spip_documents avec le rôle logo.

Sauf qu'actuellement, ce pipeline n'est utilisé que pour les balises
#LOGO_*, ça ne fonctionne pas avec l'API inc/chercher_logo, qui ne fait
que regarder dans le dossier IMG/ : https://core.spip.net/projects/spip
/repository/entry/spip/ecrire/inc/chercher_logo.php#L38
Cette fonction est pourtant utilisée un peu partout dans le core, et
dans plein de plugins.
En fait il faudrait faire une surcharge de chercher_logo plus simple
que dans logos_roles. On devrait juste prendre en compte le pipeline
quete_logo, et laisser les plugins faire tout le reste dans ce
pipeline, non ?

>
> Il y a aussi la surcharge du critère {logo} pour qu'il utilise
> cette
> API au lieu de la ré-implémenter dans son coin comme c'est
> actuellement
> le cas dans le core.
> Et enfin, la surcharge de action/editer_logo.php pour utiliser les
> rôles.
Il faut que {logo} marche avec les documents joints oui.
>
> Qu'en penses-tu ?
Et il faut surtout que ça surcharge l'interface dans sa boite dédiée
à
droite avec le form pour ne pas qu'il y ait de confusion et que les
gens
ne s'y perde pas.

L'interface à gauche, tu veux dire ? D'après mes tests, avoir une
fonction chercher_logo qui fonctionne fait 90% du travail
Après, le plus confusant pour moi c'est qu'on puisse choisir plusieurs
documents comme logo, alors qu'au final il n'y en a jamais qu'un seul
par objet…

--
bystrano

nicod · Février 24, 2018, 7:22

Le 24/02/2018 à 17:50, RastaPopoulos a écrit :

Et il faut surtout que ça surcharge l'interface dans sa boite dédiée à
droite avec le form pour ne pas qu'il y ait de confusion et que les gens
ne s'y perde pas.

Et la migration.

Ça c'est ce que tu prévois pour roles_documents ?

Pour l'instant, le fait que les logos y soient déclarés comme rôle me freine dans son utilisation, ça apporte beaucoup de complication, cf entre autre les autres mails de tcharlss aussi (doublons dans la boucle document).

Ou le fait que plusieurs documents peuvent avoir le rôle de logo.
C'est lié à la conception du plugin roles, mais ça me parait bloquant.

Quant à la surcharge de la boite dédiée aux logos (à gauche, pas à droite ^^), penser à garder la compat avec bigup.
Mais je crois qu'il surcharge tous les forms d'upload de manière générique.

Le truc qui n'y rentra pas, c'est effectivement le fait de déclarer des
nouveaux "types" de logo, ça c'est vraiment une nouvelle fonctionnalité
supplémentaire.

Les types de logos seraient simplement des rôles en fait.
Est ce qu'il faudrait les regrouper dans un groupe "types de logos" ?
Ça ne me paraît pas nécessaire.

Bon, il y a d'autres plugins qui trainent aussi, comme Logos Multiple (en externals), à voir peut être s'il y a une synergie à trouver.

--
nicod_

nicod · Février 24, 2018, 10:49

Le 24/02/2018 à 20:15, Michel Bystranowski a écrit :

Après, le plus confusant pour moi c'est qu'on puisse choisir plusieurs
documents comme logo, alors qu'au final il n'y en a jamais qu'un seul
par objet…

Exactement.
C'est pourquoi je trouve dommage d'avoir déclaré par défaut le role logo tant que tout le reste de la mécanique de remplacement de logos historiques n'est pas terminée.
En l'état c'est juste un POC, je ne le mettrais pas dans les mains de rédacteurs.

--
nicod_

rastapopoulos · Février 25, 2018, 1:06

Le 24/02/2018 à 20:15, Michel Bystranowski a écrit :

Sauf qu'actuellement, ce pipeline n'est utilisé que pour les balises
#LOGO_*, ça ne fonctionne pas avec l'API inc/chercher_logo, qui ne fait
que regarder dans le dossier IMG/ : https://core.spip.net/projects/spip
/repository/entry/spip/ecrire/inc/chercher_logo.php#L38
Cette fonction est pourtant utilisée un peu partout dans le core, et
dans plein de plugins.
En fait il faudrait faire une surcharge de chercher_logo plus simple
que dans logos_roles. On devrait juste prendre en compte le pipeline
quete_logo, et laisser les plugins faire tout le reste dans ce
pipeline, non ?

Je n'avais même pas tilter ce truc là.

Clairement s'il y a deux endroits, deux API différentes qui font la même
chose c'est-à-dire pour chercher un logo, c'est encore une de ces
incohérences dont SPIP a le secret.

Du coup il faut trouver un moyen d'uniformiser dès le noyau, et même
perso je considère ça comme un bug. Tu peux faire un ticket d'anomalie à
mon avis, si ça n'existe pas encore.

L'interface à gauche, tu veux dire ? D'après mes tests, avoir une
fonction chercher_logo qui fonctionne fait 90% du travail
Après, le plus confusant pour moi c'est qu'on puisse choisir plusieurs
documents comme logo, alors qu'au final il n'y en a jamais qu'un seul
par objet…

Oui, il y en a qu'un seul prioritaire, et dans la colonne ça ne demande
que des images aussi.

Mais par exemple on a un site où le document principal ("logo" est
vraiment un très mauvais mot, et c'est jacotte qui avait fait la
remarque à Toulouse en 2015 aussi) peut être un texte, un son, une vidéo
(et on se démerde, mais pas avec #LOGO, pour générer le bon aperçu dans
les listes de contenus). Donc là si on nous force à mettre que des
images avec ce rôle ça va pas forcément (mais bon ok on peut toujours
utiliser un autre rôle ajouté pour ça en plus).

Ya une différence entre comment c'est fait techniquement, et comment on
a interfacé ça humainement. C'est clair qu'au niveau interface ce plugin
n'est pas encore terminé. Mais il est utilisable quand même, et avoir
plusieurs logos n'est pas super grave, yen a toujours un qui est bien
pris au final (c'est pas un "pas logo" qui serait pris pour l'image
principale dans l'accueil, les listes, etc, c'est bien un de ceux
"logo", donc ça ne produit rien de mauvais dans le site, tout va bien).

Ce qui n'empêche pas de continuer à améliorer l'interface.

--
RastaPopoulos

rastapopoulos · Février 25, 2018, 1:12

Le 24/02/2018 à 20:22, nicod_ a écrit :

Ça c'est ce que tu prévois pour roles_documents ?

Voui, en fait le fait de pouvoir enfin, après tant d'année à en parler,
avoir des logos venant de la médiathèque, réutilisables et tout, c'est
la raison principale de la création de ce plugin !

Donc évidemment ça peut aussi servir à d'autres choses en ajoutant
d'autres rôles, mais on compte bien continuer d'utiliser et d'améliorer
pour les logos (et migrer les anciens).

Pour l'instant, le fait que les logos y soient déclarés comme rôle me
freine dans son utilisation, ça apporte beaucoup de complication, cf
entre autre les autres mails de tcharlss aussi (doublons dans la boucle
document).

Ou le fait que plusieurs documents peuvent avoir le rôle de logo.
C'est lié à la conception du plugin roles, mais ça me parait bloquant.

Comme dit dans l'autre mail, ça peut parfois être gênant, mais bloquant
je ne vois pas de cas. Car dans la partie public c'est bien un des
documents assigné "logo" qui sera utilisé (donc qui aurait été choisi
volontairement), donc ça ne produira rien d'horrible non plus, sauf cas
rare.

Mais clairement l'interface est loin d'être terminée et il faut
améliorer encore oui oui.

Quant à la surcharge de la boite dédiée aux logos (à gauche, pas à
droite ^^), penser à garder la compat avec bigup.
Mais je crois qu'il surcharge tous les forms d'upload de manière générique.

Oui, c'est ce que je disais à phenix cet aprèm, nous on veut absolument
que ça reste bien compatible avec bigup, t'inquiète.

Les types de logos seraient simplement des rôles en fait.
Est ce qu'il faudrait les regrouper dans un groupe "types de logos" ?
Ça ne me paraît pas nécessaire.

Oui c'est ce que je disais, ça ça ne rentre pas dans le "scope" du
plugin central, c'est d'autres utilisations.

--
RastaPopoulos

Michel_Bystranowski · Février 25, 2018, 7:08

Le samedi 24 février 2018 à 20:22 +0100, nicod_ a écrit :

Le 24/02/2018 à 17:50, RastaPopoulos a écrit :
>
> Et il faut surtout que ça surcharge l'interface dans sa boite
> dédiée à
> droite avec le form pour ne pas qu'il y ait de confusion et que les
> gens
> ne s'y perde pas.
>
> Et la migration.
Ça c'est ce que tu prévois pour roles_documents ?

Pour l'instant, le fait que les logos y soient déclarés comme rôle
me
freine dans son utilisation, ça apporte beaucoup de complication, cf
entre autre les autres mails de tcharlss aussi (doublons dans la
boucle
document).

Ou le fait que plusieurs documents peuvent avoir le rôle de logo.
C'est lié à la conception du plugin roles, mais ça me parait
bloquant.

Mon avis sur la question est que même si les logos sont encodés en tant que documents avec un role logo*, les notions de document et de logo doivent être traités dans deux interfaces différentes, à gauche les logos, et en bas les documents.

Ça rends l'interface plus cohérente et familière, mais pas que ! C'est essentiel pour la rétro-compatibilité, si ce système doit un jour être intégré dans SPIP.

Mon raisonnement est que si l'on veut utiliser les documents comme logos, on doit faire en sorte que les boucles documents ne sortent pas les documents qui ne sont que des logos. Sinon, les boucles documents actuellement dans la nature vont toutes se mettre à sortir des logos, et il faudra repasser sur tous les squelettes écrits ces 10 dernières années…

Avec un tel système, toutes les boucles documents qui n'utilisent pas le critère {role} fonctionnent comme avant, et pour les nouveaux squelettes on peut utiliser ce critère pour les avoir.

Une fois qu'on a fait cette modif, les logos ne sortent pas dans la boucle document en bas de page, et il n'y a alors pas de confusion. Un document est soit un logo (à gauche), soit un document (en bas), soit les deux (les deux).

Pour faire plus court, je suis pour que ça soit fait comme dans le plugin logos_roles

Tout ceci y est déjà implémenté, il faudrait juste surcharger le select des rôles pour qu'il ne propose plus de rôles de logos.

Quant à la surcharge de la boite dédiée aux logos (à gauche, pas à
droite ^^), penser à garder la compat avec bigup.
Mais je crois qu'il surcharge tous les forms d'upload de manière
générique.

Je ne connaissais pas bigup (bien caché sur gitlab), je vais y jeter un
œil…

> Le truc qui n'y rentra pas, c'est effectivement le fait de déclarer
> des
> nouveaux "types" de logo, ça c'est vraiment une nouvelle
> fonctionnalité
> supplémentaire.
Les types de logos seraient simplement des rôles en fait.
Est ce qu'il faudrait les regrouper dans un groupe "types de logos" ?
Ça ne me paraît pas nécessaire.

La solution que je propose est que les rôles dont le nom commence par
"logo" soient traité comme des rôles "techniques" et qu'il ne soient
pas proposés dans l'interface standard de sélection de rôles.

--
bystrano

eric_tonton · Février 25, 2018, 10:12

Hello,

Je suis tombé un peu par hasard sur ce plugin il y a quelques jours et je trouve que c’est un belle idée à intégrer à SPIP dans une prochaine version.
J’ai relu cet échange et j’ai quelques remarques:

nicod · Février 25, 2018, 1:20

Le 25/02/2018 à 02:06, RastaPopoulos a écrit :

Après, le plus confusant pour moi c'est qu'on puisse choisir plusieurs
documents comme logo, alors qu'au final il n'y en a jamais qu'un seul
par objet…

Oui, il y en a qu'un seul prioritaire, et dans la colonne ça ne demande
que des images aussi. >
Mais par exemple on a un site où le document principal ("logo" est
vraiment un très mauvais mot, et c'est jacotte qui avait fait la
remarque à Toulouse en 2015 aussi) peut être un texte, un son, une vidéo
(et on se démerde, mais pas avec #LOGO, pour générer le bon aperçu dans
les listes de contenus). Donc là si on nous force à mettre que des
images avec ce rôle ça va pas forcément (mais bon ok on peut toujours
utiliser un autre rôle ajouté pour ça en plus).

Une seule image, c'est le fonctionnement historique.
Et même si le terme n'est pas le bon, même si c'est une des particularités du vocabulaire de SPIP (comme les "squelettes"), je crois pas qu'il ne faut pas casser à ça et bien garder cette fonctionnalité d'une image unique qui représente/illustre un objet, utilisable selon son mode d'affichage (en résumé, en liste, sur la page complète).

On parle bien de gérer les logos comme des documents, pas de les supprimer, ça doit donc bien rester une image unique par objet.

Ton cas me parait très particulier, ça sort du fonctionnement normal / standard, donc effectivement à gérer avec des rôles.

avoir
plusieurs logos n'est pas super grave, yen a toujours un qui est bien
pris au final (c'est pas un "pas logo" qui serait pris pour l'image
principale dans l'accueil, les listes, etc, c'est bien un de ceux
"logo", donc ça ne produit rien de mauvais dans le site, tout va bien).

Pas d'accord. En l'état, si plusieurs images ont le rôle logo, comment le rédacteur sait à coup sûr celui qui sera utilisé sur le public ?
Je n'ai pas regardé dans le source mais c'est lequel qui remonte, par date ? par num titre ? par rang_lien ?

Ça ne produit rien de "mauvais", mais c'est confusionnant.

--
nicod_

nicod · Février 25, 2018, 1:25

Le 25/02/2018 à 08:08, Michel Bystranowski a écrit :

Mon avis sur la question est que même si les logos sont encodés en tant que documents avec un role logo*, les notions de document et de logo doivent être traités dans deux interfaces différentes, à gauche les logos, et en bas les documents.

Ça rends l'interface plus cohérente et familière, mais pas que ! C'est essentiel pour la rétro-compatibilité, si ce système doit un jour être intégré dans SPIP.

Exactement, ce qui les rendrait donc uniques de par l'interface.
Et quand on ajoute un logo*, le code pourrait en plus supprimer un éventuel document avec le même role logo* déjà existant, par souci d'intégrité des données.

Mon raisonnement est que si l'on veut utiliser les documents comme logos, on doit faire en sorte que les boucles documents ne sortent pas les documents qui ne sont que des logos. Sinon, les boucles documents actuellement dans la nature vont toutes se mettre à sortir des logos, et il faudra repasser sur tous les squelettes écrits ces 10 dernières années…

Ça me parait évident et indispensable.

La solution que je propose est que les rôles dont le nom commence par
"logo" soient traité comme des rôles "techniques" et qu'il ne soient
pas proposés dans l'interface standard de sélection de rôles.

Pourquoi pas.

--
nicod_

Michel_Bystranowski · Février 25, 2018, 2:15

Le dimanche 25 février 2018 à 02:06 +0100, RastaPopoulos a écrit :

Le 24/02/2018 à 20:15, Michel Bystranowski a écrit :
>
> Sauf qu'actuellement, ce pipeline n'est utilisé que pour les
> balises
> #LOGO_*, ça ne fonctionne pas avec l'API inc/chercher_logo, qui ne
> fait
> que regarder dans le dossier IMG/ : https://core.spip.net/projects/
> spip
> /repository/entry/spip/ecrire/inc/chercher_logo.php#L38
> Cette fonction est pourtant utilisée un peu partout dans le core,
> et
> dans plein de plugins.
> En fait il faudrait faire une surcharge de chercher_logo plus
> simple
> que dans logos_roles. On devrait juste prendre en compte le
> pipeline
> quete_logo, et laisser les plugins faire tout le reste dans ce
> pipeline, non ?
Je n'avais même pas tilter ce truc là.

Clairement s'il y a deux endroits, deux API différentes qui font la
même
chose c'est-à-dire pour chercher un logo, c'est encore une de ces
incohérences dont SPIP a le secret.

En cherchant un peu sur core.spip.net, je tombe sur ce commit https
://core.spip.net/projects/spip/repository/revisions/23039

Et donc il y a bien deux api qui font la même chose, il faut choisir.

En y regardant de plus près, chercher_logo n'appelle pas quete_logo, et
vit sa vie sans dépendre de rien, alors que quete_logo commence par
appeler chercher_logo : https://core.spip.net/projects/spip/repository/
entry/spip/ecrire/public/quete.php#L417
Du coup, la source initiale est chercher_logo, non ? Si on veut changer
le fonctionnement des logos à la racine, il faut surcharger
chercher_logo, et quete_logo suivra, pas besoin du pipeline.

--
bystrano

tcharlss · Février 25, 2018, 4:06

À la question « est-ce qu’il faudrait fusionner tout ou partie du plugin logo_roles » : oui.
Depuis le début, on voulait que le plugin prenne en charge complètement les logos (c’est dans le readme).
Fonctionnellement c’est déjà le cas, même s’il reste des choses à régler , dont la partie interface qui n’est clairement pas finie.

Les autres plugins peuvent l’étendre pour des utilisations spéciales (des rôles de logo en plus pour du RWD, et que sais-je…).

J’avais fait des mockups il y a un certain temps pour voir ce à quoi l’interface pourrait ressembler : Il faut donc surcharger le formulaire de logo pour utiliser l’ajout de document avec les rôles, qu’il n’y ait pas d’ambiguité dans l’interface, je suis tout à fait d’accord. Ça empêchera effectivement les utilisateurs d’ajouter 2 fois le même rôle de logo. Je me dis qu’on peut aussi faire l’économie de la vérification des doublons de rôles de logo si c’est rendu impossible via l’interface. Par contre je ne suis pas sûr de l’implémentation choisie par logos_roles pour ce formulaire editer_logo. À mon avis il faut réutiliser au maximum les choses du plugin medias, notamment son formulaire d’ajout de document. Il y a déjà tout dedans : les différentes méthodes d’upload (extensibles), les vérifs, etc. Il y aurait juste en plus un sélecteur pour choisir le rôle (s’il y a plusieurs rôles de logo disponibles). Et quand un logo est présent, il faut réutiliser le modèle document_desc.html pour l’afficher. Dans cette liste, je suis d’accord aussi, il ne faut pas afficher les documents avec un rôle de logo. Pour ça je pense qu’on peut reprendre le pipeline pre_boucle de logos_roles. Et il faut retirer également les rôles de logo du mini formulaire d’édition de rôle. J’avais pensé à identifier les rôles de logos directement au moment de la déclaration des rôles (dans declarer_tables_objets_sql), mais la règle "si le nom commence par « logo » me semble plus simple effectivement.

tcharlss · Février 25, 2018, 10:16

J’ai commencé un prototype pour le formulaire d’édition de logo qui se base entièrement sur joindre_documents de médias.
Il y a encore pas mal de détails à régler, mais en gros ça fonctionne bien. Les plugins style massicot et cie fonctionnent sans avoir rien à faire de particulier du coup.
Pour bigup ça ne passe pas par contre, il faut voir comment il procède pour insérer sa saisie dans le bloc d’ajout de document (si c’est via recupérer_fond, en js ou je ne sais quoi).

rastapopoulos · Février 25, 2018, 11:48

Le 25/02/2018 à 15:15, Michel Bystranowski a écrit :

Du coup, la source initiale est chercher_logo, non ? Si on veut changer
le fonctionnement des logos à la racine, il faut surcharger
chercher_logo, et quete_logo suivra, pas besoin du pipeline.

Mais non, tu vois bien justement dans le commit que j'avais commencé par
mettre le pipeline dans chercher_logo et qu'il a été *retiré* car ça
posait problème. Je ne sais plus le détail mais il me semble que c'est
justement parce que ça modifiait le formulaire, et que donc on pouvait
se retrouver avec une image qui ne venait pas des "vrais" logos mais
associée au formulaire de ces vrais logos, donc aucune cohérence.

Là quete_logo et le pipeline qui permet de l'augmenter, c'est pour
chercher le logo d'où qu'il vienne, avec les #LOGO*

--
RastaPopoulos

cerdic · Février 26, 2018, 10:29

Il y a pas 2 APIs, il y a une API avec 2 couches.

Donc dans chercher_logo on cherche le vrai logo, celui qui a été explicitement désigné comme tel, et donc ça concerne l’édition du logo
C’est là qu’on doit en effet enrichir pour chercher dans IMG/xxx(on|off).(jpg|png|gif) et/ou dans spip_documents avec le role logoon/logooff.

Le pipeline quete_logo vient par dessus, ensuite, et n’est utilisé que pour l’affichage par les balises #LOGO_*
Il permet d’implémenter des fallbacks du style « Si aucun logo n’a été explicitement uploadé mais qu’on a une image jointe dont la taille me convient, je la prends à la place pour ne pas laisser l’espace vide »
Ce genre de comportement fallback est souhaitable sur certains sites, et sur d’autre non. Il n’a pas vocation à être une généralité.

Les 2 étages ont donc leur justification, ça n’est pas un bug, et rien ne sert de râler, il suffit juste de prendre le temps de regarder et réfléchir.

Belle journée à tous,

--
Cédric

On 26 févr. 2018 à 00:48 +0100, RastaPopoulos <rastapopoulos@spip.org>, wrote:

Le 25/02/2018 à 15:15, Michel Bystranowski a écrit :
> Du coup, la source initiale est chercher_logo, non ? Si on veut changer
> le fonctionnement des logos à la racine, il faut surcharger
> chercher_logo, et quete_logo suivra, pas besoin du pipeline.

Mais non, tu vois bien justement dans le commit que j'avais commencé par
mettre le pipeline dans chercher_logo et qu'il a été *retiré* car ça
posait problème. Je ne sais plus le détail mais il me semble que c'est
justement parce que ça modifiait le formulaire, et que donc on pouvait
se retrouver avec une image qui ne venait pas des "vrais" logos mais
associée au formulaire de ces vrais logos, donc aucune cohérence.

Là quete_logo et le pipeline qui permet de l'augmenter, c'est pour
chercher le logo d'où qu'il vienne, avec les #LOGO*

--
RastaPopoulos

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

cerdic · Février 26, 2018, 10:43

On 24 févr. 2018 à 21:32 +0100, Michel Bystranowski <bystrano@gmx.ch>, wrote:

Il y a aussi la surcharge du critère {logo} pour qu'il utilise cette
API au lieu de la ré-implémenter dans son coin comme c'est actuellement
le cas dans le core.

Oui mais non, l’implémentation faite dans le plugin est totalement irréaliste d’un point de vue performance.

Le critère {logo} actuel est déjà une catastrophe en terme de performance sur les gros sites, car il fait un preg_files pour touver tous les fichiers IMG/arton.(gif|png|jpg), et construit un tableau sur cette base qu’il passe en suite à la requete sous forme sql_in()

J’ai déjà du a plusieurs reprises supprimer ce critère de boucles articles car il prenait plusieurs secondes, et bidouiller pour m’en tirer autrement.

Avec l’implémentation faites dans

c’est pire : si on a 30000 articles en base, on va itérer sur ces 30000 articles pour vérifier 1 par 1 si ils ont un logo pour construire un tableau PHP que l’on fournit ensuite à SQL dans un sql_in()

Si dans le plugin on garde la double possibilité des logos fichiers et des logos documents, la seule implémentation acceptable c’est de faire un OR entre ce que fait le critère actuel du core (avec le preg_files) et une condition SQL basée sur un LEFT JOIN (ou une sous-requete) sur spip_documents_liens.

Dans un plugin ça parait en effet délicat de dire « ok je migre tous les fichiers logo en document » car du coup le plugin devient non desinstalable (ou alors on a perdu tous les logos et on se retrouve avec plein de documents en plus).
Ou alors ça peut-être une fonction que l’on déclenche via la page de configuration du plugin et qui une fois lancée pose une meta pour dire « on a plus à gérer les logos-fichiers » et permet alors de simplifier certaines choses, comme ce critère logo qui deviendrait enfin utilisable.

Par contre en évolution du core il me semble qu’il sera indispensable de migrer tous les logos en document d’office et de basculer sur ce nouveau mode de gestion des logos.

Sur le fond de tout le thread je suis d’accord avec le fait que l’implémentation technique est indépendante de l’interface et que cela doit se faire en conservant le formulaire d’edition du logo situé en colonne de gauche, même si celui-ci doit/peut ensuite évoluer, indépendamment.

--
Cédric