[spip-dev] Bug Spip3RC ?

Christian_Marget · Mai 8, 2012, 7:01

Bonsoir,

J'ai commencé à tester Spip 3 RC sur un site d'essai (chez Free, PHP 5 activé). Pas de pb pour créer des articles sans document associé mais quand j'ai voulu insérer des photos j'ai eu des soucis :

- j'ai d'abord chargé une première photo, elle a bien été placée sous IMG/jpg/ mais dans la page de l'article je n'ai pas de code de document (doc1 ou img1)

- dans la foulée, j'ai essayé de télécharger plusieurs photos d'un coup (plusieurs sélectionnées, puis bouton "Téléverser"), ça a l'air de se faire mais là encore, pas de codes de documents. Pas non plus de bouton permettant de les ajouter au portfolio... Vérification faite dans IMG/jpg/, ces photos n'ont pas été chargées

- nouvel essai avec une photo unique. Elle est bien chargée dans IMG/jpg/ mais toujours pas de code ou autre indication pour l'insérer dans l'article

- j'ai enregistré l'article. Surprise : la page ne contient plus que le bandeau de gauche, la colonne principale ne s'affiche pas (cf. image jointe)

- en prévisualisation, l'article apparaît bien avec titre et contenu texte mais pas de photo ou portfolio, ce qui n'est qu'à moitié étonnant.

- si je vais voir dans la médiathèque, le seul affichage que je puisse obtenir est JPG(2).

J'ai retesté avec un nouvel article en ne téléchargeant qu'une seule image, même résultat. J'ai aussi essayé de charger une image directement depuis la médiathèque : j'ai la réponse "le fichier a bien été chargé" (et il est dans IMG/jpg/). Par contre, le tableau global m'indique "Aucune image"...

C'est un bug ou j'ai raté quelque chose ?

Christian Marget

klaus · Mai 14, 2012, 11:44

Je confirme l'observation que la médiathèque fait des trucs bizarres.

Dans un site test migré d'un SPIP 2.1.13 la médiathèque (/ecrire/?exec=documents) affiche Images/Bandes-son/Séquences à zéro.

Tous les documents sont répertoriés sous "Autres".

Pourquoi? Comment changer ca? Est-ce qu'on peut ignorer ce comportement ou risque-t-il de provoquer d'autres problèmes?

Merci, klaus++

klaus · Mai 14, 2012, 12:17

Comme décrit dans mon message du 11. mai avec le sujet "retour d'expérience mise à jour SPIP 2.1.13 -> SPIP 3.0.0-rc [19292]" j'ai fait exprès comme si on ne m'avais jamais rien expliqué sur SPIP, alors j'ai tout laissé en place et j'ai uniquement copié les fichiers de SPIP3 par dessus l'ancienne installation.

Tous les détails se trouvent ds ce message.

k++

klaus · Mai 14, 2012, 12:26

Non :
cd /_spip-v3.0.0-rc
svn up
cd /www/mondomaine/web
cp -Rv /_spip-v3.0.0-rc/* ./
rm -Rv /www/mondomaine/web/cache/*
pourtant c'est pareil, pas de doc classifié Images, Bandes-son ou Séquences

klaus++

guytarr · Mai 14, 2012, 12:26

Ce bug est corrigé depuis par http://zone.spip.org/trac/spip-zone/changeset/61001

cerdic · Mai 14, 2012, 12:39

Tu es repassé après dans la page des plugins pour avoir la mise à jour qui répare tes documents ?

rastapopoulos · Mai 14, 2012, 1:14

Euh même si ça n'a pas de rapport avec le bug de base, ça ça n'a jamais été une méthode correcte pour mettre à jour, si je ne m'abuse. C'est complètement aléatoire et ça laisse plein de saletés un peu partout.

Normalement, quand ce n'est pas en SVN, faudrait juste garder ce qui est fixe : IMG et config. Tout supprimer, et mettre les fichiers de la nouvelle version. N'est-il pas ?

klaus · Mai 14, 2012, 1:24

Maintenant je suis passé par la page des plugins.

J'ai cette version de Medias :

2.7.23 - test
Gestion des médias dans SPIP
Plugin actif
Plugin verrouillé
Gestion des médias de SPIP
par Collectif SPIP
Crédits Cédric Morin, Romy Duhem-Verdière pour la médiathèque
Version : 2.7.23 SVN [61273]
Répertoire : plugins-dist/medias/

klaus++

cerdic · Mai 14, 2012, 1:28

ok, donc c'est pas réparé.
Possible d'avoir un accès à la base en phpmyadmin ?

klaus · Mai 14, 2012, 1:41

Mais oui, bien sûr que ce n'est pas très propre.
Je m'y suis pris comme ca, parce que je pars du
principe qu'il y a pas mal de gens qui vont s'y prendre
comme ca - et n'est-ce pas cette méthode aussi qui est utilisée quand tu lances spip_loader.php ?

Normalement, quand ce n'est pas en SVN, faudrait juste garder ce qui est
fixe : IMG et config. Tout supprimer, et mettre les fichiers de la
nouvelle version. N'est-il pas ?

Je vois un problème avec la multitude de fonctions que rajoutent les divers plugins. Il faudrait expliquer aux auteurs des plugins et aux utilisateurs comment faire pour pouvoir en garder autant que possible.

Ou tu modifies le système de sauvegarde afin qu'il prenne en compte les plugins aussi (je vois que c'est fait en partie pour la bdd) ou tu crées et documentes un procédé pour chaque plugin (YAML ?).

Pour l'instant je suis assez content des résultats de cette migration, parce tout marche sauf ce pépin avec Medias et l'incompatibilité entre l'ancien plugin fullcalendar et l'agenda/calendrier SPIP3 qui reprend le code fullcalendar sans afficher les modeles individuels fullcalendar.

Alors félicitations à tous les auteurs de SPIP3, tant qu'il n'y aura pas de doc officielle je viendrai vous poser plein de questions à propos du nouveau calendrier

k++

klaus · Mai 14, 2012, 2:27

Je viens de changer de version SPIP3 RC
svn switch svn://trac.rezo.net/spip/branches/spip-3.0

ensuite mise à jour de la bdd [19268/19268] et mise à jour automatique "Installation du plugin Medias MAJ 1.2.0 . . Installation réussie"

La médiathèque affiche maintenant :
Images (4413)
Bandes-son (76)
Séquences (322)
Autres (500)

Les "Autres" sont
HTML (3) |
PDF (473) |
PowerPoint (1) |
RTF (5) |
VGWORT (2) |
Word (11) |
Zip (5) |

Super, c'est parfait.
merci Cédric,
klaus++

Christian_Marget · Mai 20, 2012, 11:43

Bonsoir

J'ai envoyé il y a une quinzaine de jours un rapport d'erreur sur un bug qui se produisait lorsque j'associais des images à mes articles sous Spip 3RC : le texte de ces articles disparaissait de l'espace privé, et la médiathèque n'affichait aucune info sur les images.

Sans grande réponse à ce jour, je me suis repenché sur ce problème et trouvé la cause : les images étaient trop grosses pour le calcul de vignette par GD2, et c'est probablement ça qui faisait planter l'affichage.

En fouillant un peu plus, j'ai vu qu'il y avait en fait un problème lors de la configuration du réducteur de vignettes. Mon site est hébergé par Free et dispose donc de GD2. Pas de pb pour sélectionner GD2, par contre l'affichage de taille maxi des images dépend de la version de Spip :
- sous 2.0 pas de pb, j'ai un bargraphe qui me dit 2,2 Mo.
- sous 3.0, rien : un Iframe contenant un <head> vide et un <body> vide
- sous 2.1, au lieu de la taille maxi des images, j'ai droit à un "bout" de page Free. En fait, c'est la méthode de calcul de la taille maxi qui chez Free n'aboutit pas : ce qui s'affiche, tronqué par la taille de l'Iframe, c'est une page d'erreur envoyée par Free, avec le titre suivant (merci Firebug).
<title>Free.fr - Pages personnelles: Trop de slots demandes</title>

L'erreur constatée sous Spip 3 (3.0.0 maintenant) est donc que Spip charge mes images sans prendre garde à leur taille et plante en essayant de les réduire en vignettes. Si je désactive la génération automatique de vignettes, le téléversement se fait sans pb, l'affichage dans l'espace privé est normal et la médiathèque fonctionne correctement, elle affiche même les grosses images, réduites en taille "medium".

Par contre, même si l'option "Ne pas générer de miniatures des images" est sélectionnée, le portfolio affiche (donc calcule) des vignettes. Résultat : si j'inclus une grosse image dans le portfolio d'un article, le calcul de vignette plante et l'article ne s'affiche pas. J'ai une page vide <html><head></head><body></body></html>.

D'où plusieurs questions de ma part :
- qu'est-ce qu'on peut faire contre ce problème de taille maxi chez Free ? a-t-il déjà été signalé ?
- pourquoi a-t-on abandonné la méthode de calcul de Spip 2.0 ?
- peut-on forcer dans la base une valeur de taille maxi, par phpMyAdmin ? Si oui comment (syntaxe) ? Est-ce que cela éviterait le plantage ?

Christian

P.S. Si ça peut aider, voilà un extrait de ce que Firebug me montre dans le contenu de l'Iframe, à la place de la taille maxi d'images :
<script type="text/javascript"
src="http://rta.criteo.com/dis/rtt.js?networkId=1636&cookieName=cto_alice&rnd=45362458133&varName=crtg_content"

async="">Échec du chargement de la source pour:
http://rta.criteo.com/dis/rtt.js?networkId=1636&cookieName=cto_alice&rnd=45362458133&varName=crtg_content</script>

Et quand je clique sur cette ligne "script", voilà le code qui m'est retourné :
crtg_content = '';
function writeCtoCookie(){
document.cookie='cto_alice=' + escape(crtg_content)+ '; path=/;
expires=Wed, 20 Jun 2012 00:46:22 GMT; ';
}
writeCtoCookie();

cerdic · Mai 21, 2012, 8:12

Hello,

Bonsoir

J'ai envoyé il y a une quinzaine de jours un rapport d'erreur sur un bug qui se produisait lorsque j'associais des images à mes articles sous Spip 3RC : le texte de ces articles disparaissait de l'espace privé, et la médiathèque n'affichait aucune info sur les images.

Sans grande réponse à ce jour, je me suis repenché sur ce problème et trouvé la cause : les images étaient trop grosses pour le calcul de vignette par GD2, et c'est probablement ça qui faisait planter l'affichage.

En fouillant un peu plus, j'ai vu qu'il y avait en fait un problème lors de la configuration du réducteur de vignettes. Mon site est hébergé par Free et dispose donc de GD2. Pas de pb pour sélectionner GD2, par contre l'affichage de taille maxi des images dépend de la version de Spip :
- sous 2.0 pas de pb, j'ai un bargraphe qui me dit 2,2 Mo.
- sous 3.0, rien : un Iframe contenant un <head> vide et un <body> vide
- sous 2.1, au lieu de la taille maxi des images, j'ai droit à un "bout" de page Free. En fait, c'est la méthode de calcul de la taille maxi qui chez Free n'aboutit pas : ce qui s'affiche, tronqué par la taille de l'Iframe, c'est une page d'erreur envoyée par Free, avec le titre suivant (merci Firebug).
<title>Free.fr - Pages personnelles: Trop de slots demandes</title>

L'erreur constatée sous Spip 3 (3.0.0 maintenant) est donc que Spip charge mes images sans prendre garde à leur taille et plante en essayant de les réduire en vignettes. Si je désactive la génération automatique de vignettes, le téléversement se fait sans pb, l'affichage dans l'espace privé est normal et la médiathèque fonctionne correctement, elle affiche même les grosses images, réduites en taille "medium".

Par contre, même si l'option "Ne pas générer de miniatures des images" est sélectionnée, le portfolio affiche (donc calcule) des vignettes. Résultat : si j'inclus une grosse image dans le portfolio d'un article, le calcul de vignette plante et l'article ne s'affiche pas. J'ai une page vide <html><head></head><body></body></html>.

D'où plusieurs questions de ma part :
- qu'est-ce qu'on peut faire contre ce problème de taille maxi chez Free ? a-t-il déjà été signalé ?

La taille maxi de calcul des images est lié à la mémoire PHP disponible. Il n'y a rien a y faire, c'est une contrainte imposée par l'hébergeur.

- pourquoi a-t-on abandonné la méthode de calcul de Spip 2.0 ?

Parce qu'elle était beaucoup plus lourde provoquant N hits avec accès à la base de données pour chaque.
Il est paradoxal que la nouvelle méthode qui repose sur une dichotomie (donc moins de hits) et n'écrit en base de donnée qu'à la fin du test ne marche pas.
Sans doute la faute aux redirections 302 successives...

- peut-on forcer dans la base une valeur de taille maxi, par phpMyAdmin ? Si oui comment (syntaxe) ? Est-ce que cela éviterait le plantage ?

Oui il suffit d'ajouter dans mes_options.php :

define('_IMG_GD_MAX_PIXELS',2000000);

pour limiter par exemple le calcul des images à celles qui font moins de 2 millions de pixels (les autres seront ignorées ou réduites en css uniquement, selon les filtres images utilisés.

Cédric

Christian_Marget · Mai 21, 2012, 9:52

Merci pour cette réponse.

- qu'est-ce qu'on peut faire contre ce problème de taille maxi chez Free ? a-t-il déjà été signalé ?

La taille maxi de calcul des images est lié à la mémoire PHP disponible. Il n'y a rien a y faire, c'est une contrainte imposée par l'hébergeur.

Je me suis mal exprimé : je ne parlais pas ici de la limitation de taille mais du problème de détection.

- peut-on forcer dans la base une valeur de taille maxi, par phpMyAdmin ? Si oui comment (syntaxe) ? Est-ce que cela éviterait le plantage ?

Oui il suffit d'ajouter dans mes_options.php :
define('_IMG_GD_MAX_PIXELS',2000000);
pour limiter par exemple le calcul des images à celles qui font moins de 2 millions de pixels (les autres seront ignorées ou réduites en css uniquement, selon les filtres images utilisés.

Merci. Je viens de tester et ça fonctionne impec. J'ai pu rétablir la génération des vignettes et ça ne plante plus, le fonctionnement est normal : les vignettes sont calculées pour les "petites" images, et pour les grosses elles sont simplement calculées par le navigateur qui reçoit chaque image entière et l'affiche en format réduit.

Bon, la contrepartie, c'est que ça rame pour afficher les miniatures des grosses images mais rien d'anormal à cela.