Ajout du retaillage coté client #issue_4538 #4865

Merged
marcimat merged 7 commits from issue_4538 into master 1 month ago
tofulm commented 3 months ago
Collaborator

refs #4538

refs #4538
tofulm added 6 commits 3 months ago
2400d9f1c8 WIP - debut d'ajout du resize sur le client.
1c2996d09c Ajout de la configuration pour les 3 champs :

Bonjour,

Pourquoi une configuration et pas simplement tenir compte des constantes existantes :

Ce qui pose au passage la question de que faire si _LOGO et _IMG n'ont pas les mêmes valeurs...

Bonjour, Pourquoi une configuration et pas simplement tenir compte des constantes existantes : - https://www.spip.net/fr_article4645.html _IMG_MAX_WIDTH - https://www.spip.net/fr_article4646.html _IMG_MAX_HEIGHT - https://www.spip.net/fr_article5451.html _LOGO_MAX_WIDTH - https://www.spip.net/fr_article5452.html _LOGO_MAX_HEIGHT Ce qui pose au passage la question de que faire si _LOGO et _IMG n'ont pas les mêmes valeurs...
Poster
Collaborator

l'interet de ne pas s'appuyer sur les constantes, c'est de pouvoir garder le retaillage coté serveur mais pas coté client, comme actuellement.

l'interet de ne pas s'appuyer sur les constantes, c'est de pouvoir garder le retaillage coté serveur mais pas coté client, comme actuellement.

Mais quel intérêt d'avoir deux fois retaillage différent du coup ? Si le truc a déjà été retaillé côté client (quand le client sait le faire) bah pas besoin de le faire côté serveur, et inversement si ça n'a pas marché côté client, ya le serveur en fallback… Si on décide qu'on veut pas plus de 2500px de large maximum pourquoi est-ce qu'on ne voudrait pas que ce soit fait côté client dès lors que le client sait le faire ?

Je ne vois pas pourquoi, dans quel cas, on voudrait désactiver l'un ou l'autre : soit on veut des tailles max, soit pas, peu importe la (les) méthode.

Mais quel intérêt d'avoir deux fois retaillage différent du coup ? Si le truc a déjà été retaillé côté client (quand le client sait le faire) bah pas besoin de le faire côté serveur, et inversement si ça n'a pas marché côté client, ya le serveur en fallback… Si on décide qu'on veut pas plus de 2500px de large maximum pourquoi est-ce qu'on ne voudrait pas que ce soit fait côté client dès lors que le client sait le faire ? Je ne vois pas pourquoi, dans quel cas, on voudrait désactiver l'un ou l'autre : soit on veut des tailles max, soit pas, peu importe la (les) méthode.
Owner

à l'heure actuelle (tant que tous les tests et cas d'usages ne sont pas faits) ça permet de pouvoir débrayer le retaillage côté client en cas de problème ponctuel : en ne mettant aucune valeur dans les champs largeur et hauteur, bigup fonctionne en "legacy"

à l'heure actuelle (tant que tous les tests et cas d'usages ne sont pas faits) ça permet de pouvoir débrayer le retaillage côté client en cas de problème ponctuel : en ne mettant aucune valeur dans les champs largeur et hauteur, bigup fonctionne en "legacy"
Owner

Autre point à considérer : la modification d'une constante peut ne pas être à la portée du webmestre (pas d'accès en écriture sur le serveur, pas les compétences pour créer un mes_options.php, pas la possibilité d'installer le plugin Couteau Kiss pour gérer...)

Et tant qu'on y est de discuter, on peut aussi poser la question dans l'autre sens : si le webmestre configure Bigup avec des limites de taille, ne faudrait il pas les utiliser aussi pour le retaillage en PHP ? (en priorité sur les constantes ?)

Autre point à considérer : la modification d'une constante peut ne pas être à la portée du webmestre (pas d'accès en écriture sur le serveur, pas les compétences pour créer un `mes_options.php`, pas la possibilité d'installer le plugin Couteau Kiss pour gérer...) Et tant qu'on y est de discuter, on peut aussi poser la question dans l'autre sens : si le webmestre configure Bigup avec des limites de taille, ne faudrait il pas les utiliser aussi pour le retaillage en PHP ? (en priorité sur les constantes ?)

Bah c'est justement tout l'objet de la question, faut pas inventer des configs si elles existent déjà et qu'elles veulent bien dire la même chose, que c'est vraiment pour le même besoin (peu importe les choix techniques derrière, mais même besoin côté utilisateur).

Et généralement c'est l'inverse : les constantes sont toujours prioritaires et si elles sont définis on n'affiche pas de form de config (ou disabled), et inversement si vide là on permet parfois de les configurer par interface.

Mais pour chaque besoin (et donc là en l'occurence celui de la taille max des images) il faut se demander si c'est un choix de l'hébergeur ou un choix éditorial des admins ?

D'aucun pourrait considérer que les tailles max sont bien uniquement un choix des webmestres qui installent/hébergent, car c'est eux qui sont censés faire correspondre ce qui sera stocké à long terme (dans IMG) et les capacités en disque ou CPU de là où est le site (càd que si pas machine de guerre, on veut stocker à long terme des images plus petites à la fois pour les octets que pour moins avoir de chauffe quand il faut recadrer/retailler dans les squelettes, par rapport à des images de 10Mo).
Et que donc c'est pas du tout un choix éditorial des admins.

(C'est à débattre hein, je donne des arguments dans un sens)

Bah c'est justement tout l'objet de la question, faut pas inventer des configs si elles existent déjà et qu'elles veulent bien dire la même chose, que c'est vraiment pour le même besoin (peu importe les choix techniques derrière, mais même besoin côté utilisateur). Et généralement c'est l'inverse : les constantes sont toujours prioritaires et si elles sont définis on n'affiche pas de form de config (ou disabled), et inversement si vide là on permet *parfois* de les configurer par interface. Mais pour chaque besoin (et donc là en l'occurence celui de la taille max des images) il faut se demander si c'est un choix de l'hébergeur ou un choix éditorial des admins ? D'aucun pourrait considérer que les tailles max sont bien uniquement un choix des webmestres qui installent/hébergent, car c'est eux qui sont censés faire correspondre ce qui sera stocké à long terme (dans IMG) et les capacités en disque ou CPU de là où est le site (càd que si pas machine de guerre, on veut stocker à long terme des images plus petites à la fois pour les octets que pour moins avoir de chauffe quand il faut recadrer/retailler dans les squelettes, par rapport à des images de 10Mo). Et que donc c'est pas du tout un choix éditorial des admins. (C'est à débattre hein, je donne des arguments dans un sens)
Poster
Collaborator

Proposition / refléxion :

Si :
les constantes : _IMG_MAX_WIDTH ou _IMG_MAX_HEIGHT sont présntes
et la coche Générer automatiquement les miniatures des images => est cochée (car c'est elle qui permet le retaillage coté serveur)
Alors dans le formulaire de config de bigup, on affiche simplement à titre informatif ces valeurs qui seront donc utilisées. Mais non modifiable

Sinon :
on affiche les inputs pour choisir un width et height

Proposition / refléxion : Si : les constantes : _IMG_MAX_WIDTH ou _IMG_MAX_HEIGHT sont présntes et la coche Générer automatiquement les miniatures des images => est cochée (car c'est elle qui permet le retaillage coté serveur) Alors dans le formulaire de config de bigup, on affiche simplement à titre informatif ces valeurs qui seront donc utilisées. Mais non modifiable Sinon : on affiche les inputs pour choisir un width et height

"et la coche Générer automatiquement les miniatures des images => est cochée"
attention le piège, il me semble de mémoire que cette case n'a rien à voir avec les images elles-mêmes et toutes leurs transformations. Ça ne vaut normalement QUE pour les miniatures (d'où le label) qu'on voit dans l'admin à priori.

Que ce truc soit coché ou pas, SI ya une lib d'image, ça doit pouvoir travailler dessus, c'est sans rapport avec cette case (là ici on parle pas de miniatures mais du retaillage des images sources directement qui seront gardées en base).

"et la coche Générer automatiquement les miniatures des images => est cochée" attention le piège, il me semble de mémoire que cette case n'a rien à voir avec les images elles-mêmes et *toutes* leurs transformations. Ça ne vaut normalement QUE pour les miniatures (d'où le label) qu'on voit dans l'admin à priori. Que ce truc soit coché ou pas, SI ya une lib d'image, ça doit pouvoir travailler dessus, c'est sans rapport avec cette case (là ici on parle pas de miniatures mais du retaillage des **images sources** directement qui seront gardées en base).

J'ai fait quelques essais avec cette version issue_4538 sur un SPIP 4.2-dev du jour en php 8.1.8
Avec des images au départ de plus de 7Mo et de dimensions 4896x3672 j'ai demandé
Largeur 1920
Hauteur 1200
et au départ je n'ai pas touché à la valeur par défaut de qualité.
Ca marche déjà bien !

L'image est bien réduite
image
Mais comme je trouvais que 775ko c'était encore un peu beaucoup j'ai cherché à jouer sur la compression. Avec la même image que je mette en "qualité" 0.8, 1 ou 0.1 le poids de l'image reste inchangé

Par ailleurs avec cette version de php j'ai un warning et un deprecated dans l'affichage dans la liste des plugins dans SVP lorsque je clique sur "plus d'infos"
Warning
Undefined array key "... wie der Name schon sagt ..." in /home/jack31/www_rumeur/ecrire/src/Texte/Collecteur/Multis.php on line 204
Deprecated
str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/jack31/www_rumeur/plugins-dist/textwheel/typographie/en.php on line 42
J'ai fait quelques essais avec cette version issue_4538 sur un SPIP 4.2-dev du jour en php 8.1.8 Avec des images au départ de plus de 7Mo et de dimensions 4896x3672 j'ai demandé Largeur 1920 Hauteur 1200 et au départ je n'ai pas touché à la valeur par défaut de qualité. Ca marche déjà bien ! L'image est bien réduite ![image](/attachments/4c6b4ad5-2706-4d22-abd4-c53095404845) Mais comme je trouvais que 775ko c'était encore un peu beaucoup j'ai cherché à jouer sur la compression. Avec la même image que je mette en "qualité" 0.8, 1 ou 0.1 le poids de l'image reste inchangé Par ailleurs avec cette version de php j'ai un warning et un deprecated dans l'affichage dans la liste des plugins dans SVP lorsque je clique sur "plus d'infos" Warning : Undefined array key "... wie der Name schon sagt ..." in /home/jack31/www_rumeur/ecrire/src/Texte/Collecteur/Multis.php on line 204 Deprecated : str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/jack31/www_rumeur/plugins-dist/textwheel/typographie/en.php on line 42
9.6 KiB
tofulm added 1 commit 3 months ago
Poster
Collaborator

petit test avec la qualité de 0.1 et 0.9
image

Ca fonctionne bien maintenant

petit test avec la qualité de 0.1 et 0.9 ![image](/attachments/e83182ce-2c3f-42bd-a760-1a03d94937ce) Ca fonctionne bien maintenant

Merci c'est impeccable, d'ailleurs maintenant avec la valeur de compression par défaut 0.8 la taille de l'image est réduite presque de moitié par rapport à mes premiers essais. Et avec 0.1 ça tombe à environ 10% comme on pourrait s'y attendre (83ko contre 775ko)

Un détail, chez moi pour que le changement de valeur de compression soit pris en compte il faut fermer l'article en rédaction et le ré-ouvrir.

Concernant les warnings et deprecated je vais ouvrir un autre ticket dans bigup ce n'est pas directement lié à cette évolution.

Merci c'est impeccable, d'ailleurs maintenant avec la valeur de compression par défaut 0.8 la taille de l'image est réduite presque de moitié par rapport à mes premiers essais. Et avec 0.1 ça tombe à environ 10% comme on pourrait s'y attendre (83ko contre 775ko) Un détail, chez moi pour que le changement de valeur de compression soit pris en compte il faut fermer l'article en rédaction et le ré-ouvrir. Concernant les warnings et deprecated je vais ouvrir un autre ticket dans bigup ce n'est pas directement lié à cette évolution.
Owner

"et la coche Générer automatiquement les miniatures des images => est cochée"
attention le piège, il me semble de mémoire que cette case n'a rien à voir avec les images elles-mêmes et toutes leurs transformations. Ça ne vaut normalement QUE pour les miniatures (d'où le label) qu'on voit dans l'admin à priori.

Dans la doc de _IMG_MAX_xxx ça dit que si apparemment :

Si l’image est trop grande :

  • si l’option ’Générer automatiquement les miniatures des images’ a été activée, SPIP recadre l’image à la taille maximum autorisée.
  • si l’option ’Générer automatiquement les miniatures des images’ n’est pas activée, SPIP refusera l’image

Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait.

> "et la coche Générer automatiquement les miniatures des images => est cochée" attention le piège, il me semble de mémoire que cette case n'a rien à voir avec les images elles-mêmes et toutes leurs transformations. Ça ne vaut normalement QUE pour les miniatures (d'où le label) qu'on voit dans l'admin à priori. Dans [la doc de _IMG_MAX_xxx](https://www.spip.net/fr_article4645.html) ça dit que si apparemment : > Si l’image est trop grande : > > * si l’option ’Générer automatiquement les miniatures des images’ a été activée, SPIP recadre l’image à la taille maximum autorisée. > * si l’option ’Générer automatiquement les miniatures des images’ n’est pas activée, SPIP refusera l’image Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait.

Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait.

Alors oui clairement l'explication ne convient pas/plus !

> Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait. Alors oui clairement l'explication ne convient pas/plus !
Owner

Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait.

cf spip/spip#5390 donc... (merci pour le ticket :) )

> Si c'est bien le cas, faudrait revoir le wording de cette option d'ailleurs, ça indique pas clairement ce que ça fait. cf https://git.spip.net/spip/spip/issues/5390 donc... (merci pour le ticket :) )
tofulm added 1 commit 3 months ago
tofulm added 1 commit 3 months ago
829fe05737 Configuration de la largeur / hauteur / qualité :
Poster
Collaborator

Maintenant, la configuration prend en compte la presence des constantes _IMG_MAX_WIDTH et _IMG_MAX_HEIGHT et utilise _IMG_GD_QUALITY pour pour la qualite de compression.

Si les constantes sont presentes :
image

Si les constantes sont absentes :
image

Attention, pour les tests, la qualité n'est plus comprise en 0 et 1 mais 0 et 100 comme celle de _IMG_GD_QUALITY

Maintenant, la configuration prend en compte la presence des constantes _IMG_MAX_WIDTH et _IMG_MAX_HEIGHT et utilise _IMG_GD_QUALITY pour pour la qualite de compression. Si les constantes sont presentes : ![image](/attachments/f7795cef-0e28-407d-85ab-78295be96dd8) Si les constantes sont absentes : ![image](/attachments/0da67b2e-740f-4b9d-99da-8be59ada99ad) Attention, pour les tests, la qualité n'est plus comprise en 0 et 1 mais 0 et 100 comme celle de _IMG_GD_QUALITY

Ça a l'air cool !

Ça a l'air cool !
Owner

Sinon, je n'arrive pas à trouver s'il y a des valeurs par défaut qui sont proposées. Tout ce que je trouve, ce sont des valeurs dans les exemples de spip.net, ou dans les copies d'écran ci-dessus.

Et ce qui me chiffonne, c'est que toutes ces valeurs sont invraisemblablement basses, comme si on faisait encore du Web comme en 2000, et comme si SPIP n'avait pas des outils de redimensionnement des images.

Je vois des exemples de valeurs à 500 pixels, et encore 600 pixels dans la plus récente copie d'écran. Je pense qu'il ne faut surtout pas conseiller de faire tourner un site avec de telles valeurs. Même 1024 pixels c'est très peu.

Un écran d'iPhone 4, sorti en 2010, c'est déjà une largeur de 640 pixels et une hauteur de 960 pixels.

Le problème des images trop petites, car taillées pour une époque donnée et une maquette donnée, c'est que ça pourrit complètement les possibilités d'évolution du site. Quand je reprends un site Web, et que toutes les images font 600 pixels, je suis vraiment vraiment emmerdé, parce qu'il n'y a pas grands chose à faire pour le faire évoluer avec une maquette moderne.

Alors dans 5 ans…

=> D'où ma suggestion de commencer à donner des exemples et des valeurs par défaut correspondant à un site moderne et qui pourra évoluer facilement, en prenant bien en compte (voire en promouvant?) le fait que SPIP a des fonctions de traitement des images qui servent exactement à ça.

Perso mes recommendations pour les sites que je fais, c'est d'essayer de travailler avec des images qui font 2400 pixels dans leur plus grande dimension.

Sinon, je n'arrive pas à trouver s'il y a des valeurs par défaut qui sont proposées. Tout ce que je trouve, ce sont des valeurs dans les exemples de spip.net, ou dans les copies d'écran ci-dessus. Et ce qui me chiffonne, c'est que toutes ces valeurs sont invraisemblablement basses, comme si on faisait encore du Web comme en 2000, et comme si SPIP n'avait pas des outils de redimensionnement des images. Je vois des exemples de valeurs à 500 pixels, et encore 600 pixels dans la plus récente copie d'écran. Je pense qu'il ne faut surtout pas conseiller de faire tourner un site avec de telles valeurs. Même 1024 pixels c'est très peu. Un écran d'iPhone 4, sorti en 2010, c'est déjà une largeur de 640 pixels et une hauteur de 960 pixels. Le problème des images trop petites, car taillées pour une époque donnée et une maquette donnée, c'est que ça pourrit complètement les possibilités d'évolution du site. Quand je reprends un site Web, et que toutes les images font 600 pixels, je suis vraiment vraiment emmerdé, parce qu'il n'y a pas grands chose à faire pour le faire évoluer avec une maquette moderne. Alors dans 5 ans… => D'où ma suggestion de commencer à donner des exemples et des valeurs par défaut correspondant à un site moderne et qui pourra évoluer facilement, en prenant bien en compte (voire en promouvant?) le fait que SPIP a des fonctions de traitement des images qui servent exactement à ça. Perso mes recommendations pour les sites que je fais, c'est d'essayer de travailler avec des images qui font 2400 pixels dans leur plus grande dimension.
Poster
Collaborator

ces copies d'écrans, sont le résultats de tests, et c'est plus parlant avec des valeurs basses. Elles ne sont pas destinées à de la documentation ;-)

ces copies d'écrans, sont le résultats de tests, et c'est plus parlant avec des valeurs basses. Elles ne sont pas destinées à de la documentation ;-)
tofulm added 1 commit 3 months ago
75a5903176 Si on regarde le code, pour activer le retaillage coté serveur il faut :
Poster
Collaborator

Si on regarde le code, pour activer le retaillage coté serveur il faut :

  • activer la generation des vignettes
    ET
  • avoir au moins 1 constante presente _IMG_MAX_WIDTH ou _IMG_MAX_HEIGHT

75a5903176

Si on regarde le code, pour activer le retaillage coté serveur il faut : - activer la generation des vignettes ET - avoir au moins 1 constante presente _IMG_MAX_WIDTH ou _IMG_MAX_HEIGHT https://git.spip.net/spip/bigup/commit/75a5903176211c3a63f3b9936fdc6c89f18ab7c1
tofulm changed title from WIP ajout du retaillage coté client #issue_4538 to Ajout du retaillage coté client #issue_4538 3 months ago
cy.altern approved these changes 3 months ago
Jack31 approved these changes 3 months ago

Cette évolution me semble aussi importante que l’amélioration de l'interface privée en 4.0
Ca serait bien que ce soit dans la prochaine release et même en 4.1

Parce que sinon il faut continuer à expliquer aux gens comment réduire les images avant, et ils oublient une fois sur deux.

Cette évolution me semble aussi importante que l’amélioration de l'interface privée en 4.0 Ca serait bien que ce soit dans la prochaine release et même en 4.1 Parce que sinon il faut continuer à expliquer aux gens comment réduire les images avant, et ils oublient une fois sur deux.

Euh bah non @jack31 comme expliqué dans ce thread même, quand tu actives les limites de taille max (largeur OU hauteur), bah ton SPIP va les retailler dès la source et donc sans apprendre à tes rédacs à retailler, et ça sera bien enregistré en 2500px max de largeur dans IMG ensuite. Sans cette fonctionnalité ça le fait déjà, côté serveur (et comme c'est un par un, et qu'ensuite ça reste à l'infini avec la bonne réduc dans IMG ça va très bien déjà).

Euh bah non @jack31 comme expliqué dans ce thread même, quand tu actives les limites de taille max (largeur OU hauteur), bah ton SPIP va les retailler **dès la source** et donc sans apprendre à tes rédacs à retailler, et ça sera bien enregistré en 2500px max de largeur dans IMG ensuite. Sans cette fonctionnalité ça le fait déjà, côté serveur (et comme c'est un par un, et qu'ensuite ça reste à l'infini avec la bonne réduc dans IMG ça va très bien déjà).

Attention la valeur par défaut est restée à 0.8 pour le champ "Qualité" au lieu de 85 attendu maintenant dans formulaires/configurer_bigup.html

#SET{name,client_quality}#SET{obli,''}#SET{defaut,0.8}#SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}}

Attention la valeur par défaut est restée à 0.8 pour le champ "Qualité" au lieu de 85 attendu maintenant dans formulaires/configurer_bigup.html `#SET{name,client_quality}#SET{obli,''}#SET{defaut,0.8}#SET{erreurs,#ENV**{erreurs}|table_valeur{#GET{name}}}`
tofulm added 1 commit 2 months ago
marcimat added 4 commits 2 months ago
0c3fbfe197 feat: Redimensionnement des images téléversées depuis le navigateur
53fcc58851 feat: Configuration du redimensionnement des images côté navigateur
bbc51a1d7d feat: Le retaillage utilise la configuration pour SPIP, si définie.
Owner

Je me suis permis de rebaser / fixup / éditer les messages de commit.

Je me suis permis de rebaser / fixup / éditer les messages de commit.
Owner

Je me demande s’il ne faudrait pas conditionner

$scripts[] = 'lib/load_image/load-image.all.min.js';

Plutôt que de charger systématiquement 26Ko de plus de JS ?

Je me demande s’il ne faudrait pas conditionner ```php $scripts[] = 'lib/load_image/load-image.all.min.js'; ``` Plutôt que de charger systématiquement 26Ko de plus de JS ?
marcimat added 3 commits 2 months ago
f692392a20 feat: Redimensionnement des images téléversées depuis le navigateur
68fab05ad1 feat: Configuration du redimensionnement des images côté navigateur
e697acf3ef feat: Le retaillage utilise la configuration pour SPIP, si définie.
marcimat approved these changes 2 months ago
marcimat left a comment
Owner

A priori, ça fonctionne, c’est déjà bien :)

A priori, ça fonctionne, c’est déjà bien :)
marcimat added 1 commit 2 months ago
7ed707b0e0 fix(ui): Ajouter une icone sur le formulaire de config de bigup.
Poster
Collaborator

Je me demande s’il ne faudrait pas conditionner

$scripts[] = 'lib/load_image/load-image.all.min.js';

Plutôt que de charger systématiquement 26Ko de plus de JS ?

C'est une bonné idée !

Un question qui reste en suspend, pour l'instant, est l'activation automatique du retaillage. Pour l'instant, je l'ai activé seulement si une constante _IMG_MAX_XXX est présente. Je ne tiens pas compte de la global create_preview qui elle, est indispensable pour activer le retaillage coté serveur.
Je pense que ce n'est pas necessaire.
Qu'en pensez vous ?

> Je me demande s’il ne faudrait pas conditionner > > ```php > $scripts[] = 'lib/load_image/load-image.all.min.js'; > ``` > > Plutôt que de charger systématiquement 26Ko de plus de JS ? > C'est une bonné idée ! Un question qui reste en suspend, pour l'instant, est l'activation automatique du retaillage. Pour l'instant, je l'ai activé seulement si une constante _IMG_MAX_XXX est présente. Je ne tiens pas compte de la global `create_preview` qui elle, est indispensable pour activer le retaillage coté serveur. Je pense que ce n'est pas necessaire. Qu'en pensez vous ?
Owner
  1. c'est très cool !

  2. Je crois qu'il reste un questionnement sur les constantes : pour le recadrage côté serveur on a aussi des constantes réservées aux logos : _LOGO_MAX_WIDTH et _LOGO_MAX_HEIGHT.

S'il fallait les prendre en compte aussi dans bigup ça compliquerait pas mal la config. Est-ce qu'on aurait pas intérêt à les déprécier dans le core au passage ? Maintenant que les logos sont des documents comme les autres, il y a vraiment un intérêt à avoir des constantes séparées ?

1) c'est très cool ! 2) Je crois qu'il reste un questionnement sur les constantes : pour le recadrage côté serveur on a aussi des constantes réservées aux logos : [\_LOGO_MAX_WIDTH](https://www.spip.net/fr_article5451.html) et [\_LOGO_MAX_HEIGHT](https://www.spip.net/fr_article5452.html). S'il fallait les prendre en compte aussi dans bigup ça compliquerait pas mal la config. Est-ce qu'on aurait pas intérêt à les déprécier dans le core au passage ? Maintenant que les logos sont des documents comme les autres, il y a vraiment un intérêt à avoir des constantes séparées ?
Owner

Pour l'instant, je l'ai activé seulement si une constante _IMG_MAX_XXX est présente. Je ne tiens pas compte de la global create_preview qui elle, est indispensable pour activer le retaillage coté serveur.

A mon avis l'activation de la génération des vignettes et l'activation du retaillage (côté navigateur ou serveur) sont 2 choses différentes et il faut arrêter des les confusionner.
Je suis pour ne pas tenir compte de la globale create_preview dans le retaillage.

Pour mémoire, on retombe (partiellement) sur le problème soulevé par spip/spip#5390

> Pour l'instant, je l'ai activé seulement si une constante _IMG_MAX_XXX est présente. Je ne tiens pas compte de la global `create_preview` qui elle, est indispensable pour activer le retaillage coté serveur. A mon avis l'activation de la génération des vignettes et l'activation du retaillage (côté navigateur ou serveur) sont 2 choses différentes et il faut arrêter des les confusionner. Je suis pour ne pas tenir compte de la globale `create_preview` dans le retaillage. Pour mémoire, on retombe (partiellement) sur le problème soulevé par https://git.spip.net/spip/spip/issues/5390
Owner
  1. Je crois qu'il reste un questionnement sur les constantes : pour le recadrage côté serveur on a aussi des constantes réservées aux logos : _LOGO_MAX_WIDTH et [_LOGO_MAX_HEIGHT]

S'il fallait les prendre en compte aussi dans bigup ça compliquerait pas mal la config. Est-ce qu'on aurait pas intérêt à les déprécier dans le core au passage ? Maintenant que les logos sont des documents comme les autres, il y a vraiment un intérêt à avoir des constantes séparées ?

ha ha ! tu as démasqué tofulm : tel que codé pour l'instant, le retaillage côté navigateur considère que ces 2 constantes seront dépréciées d'ici pas longtemps :)

A mon avis, vu l'évolution des logos, il serait logique de les dépréciers pour la 4.2...

> 2) Je crois qu'il reste un questionnement sur les constantes : pour le recadrage côté serveur on a aussi des constantes réservées aux logos : [\_LOGO_MAX_WIDTH](https://www.spip.net/fr_article5451.html) et [\_LOGO_MAX_HEIGHT] > > S'il fallait les prendre en compte aussi dans bigup ça compliquerait pas mal la config. Est-ce qu'on aurait pas intérêt à les déprécier dans le core au passage ? Maintenant que les logos sont des documents comme les autres, il y a vraiment un intérêt à avoir des constantes séparées ? ha ha ! tu as démasqué tofulm : tel que codé pour l'instant, le retaillage côté navigateur considère que ces 2 constantes seront dépréciées d'ici pas longtemps :) A mon avis, vu l'évolution des logos, il serait logique de les dépréciers pour la 4.2...

A mon avis, vu l'évolution des logos, il serait logique de les dépréciers pour la 4.2...

Effectivement, la taille max des logo peut être commune avec celles des images.

Par contre, en termes de direction artistique (clien d'œuil à ARNO), pouvoir avoir une taille minimum des logos différente de celle des images, c'est bien.

> A mon avis, vu l'évolution des logos, il serait logique de les dépréciers pour la 4.2... Effectivement, la taille max des logo peut être commune avec celles des images. Par contre, en termes de direction artistique (clien d'œuil à ARNO), pouvoir avoir une taille **minimum** des logos différente de celle des images, c'est bien.
tofulm added 2 commits 2 months ago
tofulm added 2 commits 2 months ago
tofulm added 1 commit 2 months ago
a46c3efe08 correction, c'est bien _IMG_MAX_WIDTH ou _IMG_MAX_HEIGHT et non et
tofulm added 1 commit 2 months ago
70537d53da feat: on charge la lib load-image seulement si le retaillage est activé
tofulm added 1 commit 2 months ago
tofulm added 1 commit 2 months ago
0bb4e68899 feat: on charge la lib load-image seulement si le retaillage est activé
tofulm added 1 commit 2 months ago
tofulm added 1 commit 2 months ago
tofulm added 1 commit 2 months ago
tcharlss approved these changes 2 months ago
tcharlss left a comment
Owner

neat !

neat !
marcimat added 6 commits 1 month ago
34fe2395b9 feat: Redimensionnement des images téléversées depuis le navigateur
ac95b72155 feat: Configuration du redimensionnement des images côté navigateur
6c18da83ef feat: Le retaillage utilise la configuration pour SPIP, si définie.
97f4c1dd58 fix(ui): Ajouter une icone sur le formulaire de config de bigup.
d434ef2d06 feat: on charge la lib load-image seulement si le retaillage est activé
marcimat approved these changes 1 month ago
marcimat added 1 commit 1 month ago
Owner

En rapport avec les préconisations d’@arno on pourrait peut être compléter la phrase actuelle

Si largeur et/ou hauteur sont renseignées, les images seront redimensionnées par le navigateur avant envoi sur le serveur

Par par exemple

Si largeur et/ou hauteur sont renseignées, les images seront redimensionnées par le navigateur avant envoi sur le serveur. Il est conseillé de conserver une taille minimale suffisante (par exemple 2400px) pour satisfaire les besoins graphiques actuels et ultérieurs du site.

QQc comme ça ?

En rapport avec les préconisations d’@arno on pourrait peut être compléter la phrase actuelle > Si largeur et/ou hauteur sont renseignées, les images seront redimensionnées par le navigateur avant envoi sur le serveur Par par exemple > Si largeur et/ou hauteur sont renseignées, les images seront redimensionnées par le navigateur avant envoi sur le serveur. Il est conseillé de conserver une taille minimale suffisante (par exemple 2400px) pour satisfaire les besoins graphiques actuels et ultérieurs du site. QQc comme ça ?
marcimat merged commit 8165765af4 into master 1 month ago
marcimat deleted branch issue_4538 1 month ago
Owner

J’envoie déjà ça !

J’envoie déjà ça !

Reviewers

cy.altern approved these changes 3 months ago
Jack31 approved these changes 3 months ago
tcharlss approved these changes 2 months ago
marcimat approved these changes 1 month ago
The pull request has been merged as 8165765af4.
Sign in to join this conversation.
No Milestone
No Assignees
8 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.