après création d’une nouvelle rubrique, l’administrateur a voulu lui attacher un logo.
Se trompant de fichier, il a pris un fichier d’environ 900ko
ce qui a pris un certain temps et planté le téléchargement
Jusque là rien que de très habituel
Cependant, après cet incident
accès à la nouvelle rubrique : la page est incomplète et n’affiche plus rien après le bloc infos
la navigation dans les autres rubriques est aussi perturbée
la page d’accueil du site web affiche un grand désert blanc
ça a pris quelque temps avant de trouver :
migration à la nouvelle version de spip (sans grand espoir j’avoue)
vérification de toutes les tables de la base (tout ok)
… finalement, c’est par FTP, en supprimant le fichier logo de la rubrique (/IMG/rub31.jpg) que tout est rentré dans l’ordre comme par miracle.
Pas envie ni le temps de reproduire le truc, mais si c’est reproductible, ça vaudrait le coup de prévoir un filet de protection…
Oui, c'est un problème que je croise parfois. Mais je doute que ce soit lié à SPIP.
- Sur l'Herbier, on charge des grosses et lourdes captures d'écran en logo d'article. Et ça se passe très bien.
- Sur exactement le même site, mais en local, ça m'a pété l'espace privé, exactement comme tu le décris. Mais sans endommager l'affichage du site public.
- Sur un autre site, on a des pages blanches en front dès qu'on charge une image (logo ou doc). Il n'est plus possible d'éditer le logo ou l'image et seule la suppression par FTP du fichier rétablit le site. Je ne me souviens plus si l'espace privé en souffre davantage. La solution a été de brider l'upload, encore plus que dans ma trousse : https://github.com/tetue/tetue_trousse/blob/master/tetue_trousse_options.php
- Rien à signaler sur d'autres sites à gros médias.
salut,
pour moi c’est arrivé plusieurs fois que des rédacteurs mettent des images trop grosses et ça plante le site de la manière que tu décris, parfois une page blanche… il faut aller sur le serveur pour juste réduire l’image (que ce soit un logo ou un doc)
la dernière fois avec une image de 6Mo…
mais la première erreur n’est-elle pas de ne pas mettre de frein (en limitant la taille des images téléchargées, cf. couteau kiss par exemple) ?
Pas envie ni le temps de reproduire le truc, mais si c'est
reproductible, ça vaudrait le coup de prévoir un filet de protection...
C'est reproductible à tous les coups : c'est GD2 qui plante sans rendre la main à php quand il essaye de redimensionner une image trop grosse, et du coup spip ne peut rien y faire.
J'ai réussi des fois à ravoir un site en configurant pour redimensionner les images par ImageMagick au lieu de GD2, mais il faut qu'il soit installé (si je me souviens bien il plante aussi, mais de manière moins violente, ce qui fait que l'image est simplement laissée telle quelle).
En principe il y a un filet, quand on configure le redimensionnement il teste la taille maximale d'image qu'il arrive à redimensionner. Mais des fois les mailles sont un peu trop lâches ...
On peut par exemple rajouter ceci dans le fichier mes_options.php :
if (!defined(’_LOGO_MAX_SIZE’)) define(’_LOGO_MAX_SIZE’,100); // Poids max des logos
if (!defined(’_IMG_MAX_SIZE’)) define(’_IMG_MAX_SIZE’,3000); // Poids max des images
Puisque l'interface d'activation GD2 affiche bien la taille max possible,
ne seait-il pas possible d'ajouter automatiquement la génération des
define dans un spip_mes_options.php (automatiquement placé dans extensions pour ne pas briser les fonctionnements actuels ?):
if (!defined('_LOGO_MAX_SIZE')) define('_LOGO_MAX_SIZE',xxGD2); // Poids max des logos
if (!defined('_IMG_MAX_SIZE')) define('_IMG_MAX_SIZE',xxGD2); // Poids max des images
Ça n'est pas le problème : lorsqu'une image a une taille supérieure à la limite détectée, SPIP a le bon goût de s'en apercevoir et de ne pas tenter une opération qui va échouer.
Le problème est que cette limite est un peu optimiste et il arrive qu'une image plante avec une taille inférieure à la limite calculée.
Une décote de 10% sur le calcul a été appliqué dans SPIP3, a voir si cela va mieux en pratique.
Effectivement, c'est encore plus efficace...
Bravo !
Yx
PS mais qu'il est difficile, si l'on n'est pas core-dev
de trouver toutes ces subtilités dans notre SPIP.
Merci aux experts de continuer à nous y instruire !
Le poids une fois décompressé...
est-ce que le rédacteur moyen connaît ça pour les documents qu'il téléverse ?
Si c'est en décompressé, c'est une fonction linéaire du nombre de pixels (32 bits ou 4 octets par point ?).
L'utilisateur connaissant la taille en pixels de son image, pourquoi ne pas clairement limiter en pixels ??
Il saurait alors la vérifier, la réduire, ...
C'est la taille en nombre de Px qui compte dans l'histoire, le poids n'a rien à y faire.
"Ben oui, c'est qu'est-ce que j'dis" ! (c) Pause Café 1981
Alors pourquoi limite-t-on les rédacteurs par leurs images en *ko* ?? _LOGO_MAX_SIZE - SPIP
Surtout si SPIP vérifie la taille (le poids) a posteriori du chargement ??
Il y a les constantes _LOGO_MAX_WIDTH et _LOGO_MAX_HEIGHT aussi, non ?
La taille limitée en poids d'une image, pour moi administrateur, à l'avantage de limiter l'utilisation de mon espace d'hébergement.
L'attrait : empêcher un rédacteur de charger les photos sorties tout droit de son APN à 16 millions de pixels…
dès que quelqu'un aura écrit l'intitulé exact qui convient pour
définir ce terme (taille ?, poids ?, volume ?), son expression
(kilo-octets ?, kilo-pixels ?, méga-pixels_divisés_par_1024 ?)
et que ce sera compréhensible par le commun des rédacteurs qui
n'a sous les yeux qu'un fichier avec une taille/poids indiquée
en octets, nul doute que ce sera intégré à la doc.
