Bonjour,
Il semble qu'avec Media Wiki, la génération des miniatures des images téléchargées pose problème.
> Erreur lors de la création de la miniature :
> Error code: -1
En effet je rencontre le même soucis qu'ici .
Cependant je ne me satisfais pas du contournement proposé : télécharger des images plus petites.
Le dysfonctionnement s'observe même avec des images 500x500 pxls.
J'ai également crée un sujet sur le forum de MediaWiki (ici) .
La première réponse mentionne un autre fil concernant le même soucis sur de l'hébergement OVH.
J'ai essayé de jouer avec les paramètres de Wikimedia suivant :
> $wgImageMagickConvertCommand = "/usr/bin/convert";
> $wgUseImageResize = true;
> $wgUseImageMagick = true;
> $wgMaxShellMemory = 307200;
> $wgGenerateThumbnailOnParse = true;
> $wgMaxImageArea
Sans succès.
Dans la page MediaWiki permettant de télécharger un fichier, il est indiqué par défaut :
> Taille maximale du fichier : 64 Mio
Il me semble donc que cela relève de limitations dues à l’implémentation de ImageMagick en environnement mutualisé.
Auriez-vous une piste ?
Bonjour,
Quel environnement utilisez vous ?
L'environnement stable est conseillé.
https://docs.ovh.com/fr/fr/web/hosting/modifier-lenvironnement-dexecution-de-mon-hebergement-web/#comment-modifier-l-environnement-d-execution
De mon coté, j'avais eu le problème, je ne sais plus du tout ce que j'ai fait, mais en tous cas ça marche aujourd'hui, ouf 
https://drivrsdu.fr/dicof/w/index.php/Accueil
Je n'ai même plus rien de particulier dans le LocalSettings à ce sujet… je pense que ça c'était résolu par l'environnement OVH qui est maintenant "stable PHP 7.1".
Bon courage.
Media wiki 1.28 n'est pas officiellement compatible avec php 7.1…
Je rencontre le même problème. L'avez-vous résolu?
J'ai essayé de faire à la main la commande du serveur. J'ai trouvé que j'ai dû ajouter des ' autour de la commande -set comment 'File source: …' pour que cela marche.
@ChristopheM2 : Pourriez-vous décrire d'avantage ce que vous avez fait ?
Je suis en PHP 5.6.36 (fpm-fcgi) et MediaWiki 1.27.4 et cette erreur persiste.
Le présent message ayant été soit disant «signalé aux modérateurs par plusieurs utilisateurs», sans aucun motif plus précis, puis "caché" pour une raison que j'ignore, je le résume à sa plus simple expression en espérant qu'il en sera pas de nouveau censuré. Mon seul objectif était seulement de rechercher une solution de manière coopérative avec ceux d'entre nous qui rencontrent ce problème, connu et récurrent chez OVH depuis au moins 2010.
Pour résumer au maximum le long message précédent, qui a été "signalé" puis "caché" peut-être à cause de sa longueur:
En deux mots et dans mon cas particulier, après deux jours de tests, je pense que le problème ne vient pas tant de ImageMagick en général que de la commande envoyée par $wgImageMagickConvertCommand = "/usr/bin/convert" (telle que définie dans LocalSettings.php) qui soit ne fonctionne pas du tout, soit ne parvient pas à écrire dans le répertoire de mes images.
D'après un spécialiste que j'ai contacté, ceci peut être dû à une question de droits d'accès et/ou aux ressources limitées des hébergements mutualisés, insuffisantes pour faire tourner correctement ImageMagick.
Hope this helps
https://community.ovhcloud.com/t/47782
inutile de multiplier les messages…
Bonjour kyodev
Désolé d'avoir multiplié les messages.
En fait, chez moi imagemagick fonctionne très bien. Je l'ai vérifié en le faisant fonctionner dans une page php différente.
J'ai plutôt l'impression que le problème vient de ce qu'il n'a pas le droit d'écrire dans le repertoire /wiki/images/thumb mais je ne sais pas trop comment m'en assurer. J'ai envoyé un ticket à ce sujet.
Bien sincèrement.
Après une semaine de grosses galères, je viens enfin de recevoir une réponse claire du support OVH. Un poil gênée et alambiquée, mais enfin claire:
Les vignettes MediaWiki ne peuvent pas fonctionner correctement sur leurs hébergements mutualisés (en tout cas à l'heure actuelle et pour ce que j'ai enfin pu comprendre) car une partie des imagick classes (les plus gourmandes en ressources, je suppose, mais je ne suis pas un pro) n'est pas activée dans les configurations partagées et que ces configurations ne sont pas modifiables sur les hébergements mutualisés. La seule solution chez OVH est de passer à un hébergement dédié.
Tout ça est au fond assez compréhensible, vue la différence de prix et de ressources utilisées (Dans certains cas, MediaWiki peut générer et écrire vraiment beaucoup de vignettes). Ça aurait juste pu être dit plus vite et plus franchement, mais au moins, maintenant, c'est clair.
Donc 2 solutions:
1) Soit passer à un hébergement dédié.
2) Soit se contenter de l'existant et générer les vignettes en local avant de les uploader en ftp. C'est un peu galère si on le fait entièrement à la main, mais je vais continuer à explorer cette voie car rédiger un petit script pour automatiser tout ça ne me semble pas insurmontable.
1/ dédié?.. cherche un peu pas besoin
2/ avec GD ? il ne sait pas gérer mediawiki?
ceci dit, pas de webp chez Ovh avec GD
Merci Kyodev, tu as raison, je ne vais pas passer à un dédié, ce serait quand même un peu trop cher pour un simple problème de quatre pauvres vignettes sur un wiki perso! ;-D
Par contre, je vais peut-être passer à la gamme "pro" dans mon mutualisé, parce que cet hébergement là est en " perso" et je n'ai même pas d'accès SSH, c'est franchement galère quand un truc ne fonctionne pas, du coup.
Le mec d'OVH m'a dit que ça ne changera rien à mon problème parce que les hébergement "perso" et "pro" sont configurés pareil et que ces configs ne sont pas modifiables. Mais ça me permettra peut-être de contourner le problème plus facilement.
Pour GD et webP, je ne maîtrise pas assez. Je finirai par demander l'aide d'un développeur pro si je ne m'en sors pas tout seul, mais je ne pense pas que ça change grand chose: Parce que pour ce que je vois après tous les essais que j'ai fait jusqu'ici, Imagick et Mediawiki fonctionnent parfaitement. C'est juste que pour une raison que j'ignore, Mediawiki ne parvient pas à les écrire dans le bon répertoire sur les hébergements mutualisés (en tout cas sur les deux où j'ai fait l'essai).
perso=pro=performance…
tous ça c'est des mutus
les quotas changent
mais attention, si accès ssh à partir de pro, c'est tellement bridé que ça peut être rédhibitoire
et un dev ne pourra rien contre les limitations mises en place par Ovh
OK Merci. Je vais déjà essayer de comprendre de plus près la cause du problème.
Je suis de plus en plus persuadé que c'est un bête problème de droits avec la commande:
/usr/bin/convert
J'ai su résoudre ce genre de trucs dans le temps jadis, mais j'ai sérieusement perdu la main depuis. Faut juste que je trouve le temps de m'y remettre.
A+
> une partie des imagick classes n'est pas activée dans les configurations partagées et que ces configurations ne sont pas modifiables sur les hébergements mutualisés.<br /><br />je parie pas cher sur ta réussite...<br />après si tu veux essayer, je t'ouvre un accès ssh sur un pro<br />```text<br />(php/7.2/production/stable64) ~ $ /usr/bin/convert --version<br />Version: ImageMagick 6.8.9-9 Q16 i586 2018-11-11 http://www.imagemagick.org<br />```<br />fais signe en privé
Super, merci, c'est vraiment sympa.
Mais ça va pas être la peine, je suis encore sur une fausse piste!
J'ai regardé en mettant des scripts dans du php, c'est pas pratique pratique (!) mais ça marche et tu as raison, ça n'a pas l'air de venir de là non plus:
ls -l /usr/bin/convert
lrwxrwxrwx 1 root root 25 Mar 11 14:06 /usr/bin/convert -> /etc/alternatives/convert
ls -l /etc/alternatives/convert
lrwxrwxrwx 1 root root 20 Mar 11 14:06 /etc/alternatives/convert -> /usr/bin/convert-im6
ls -l /usr/bin/convert-im6
lrwxrwxrwx 1 root root 55 Nov 11 19:21 /usr/bin/convert-im6 -> ../lib/i386-linux-gnu/ImageMagick-6.8.9/bin-Q16/convert
ls -l /usr/lib/i386-linux-gnu/ImageMagick-6.8.9/bin-Q16/convert
-rwxr-xr-x 1 root root 5580 Nov 11 19:21 /usr/lib/i386-linux-gnu/ImageMagick-6.8.9/bin-Q16/convert
Je continue à sécher, du coup!
TROUVÉ!!!
Enfin, pas trouvé l'explication du problème hélas, car c'est manifestement très au-delà de mes compétences.
En revanche, j'ai trouvé en relisant https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Error_creating_thumbnail_Error_code:_-1 ceci quelqu'un qui avait le même problème il y a 3 ans et qui l'avait résolu tout bêtement en désactivant purement et simplement l'utilisation de ImageMagick par Mediawiki!
Pour cela, il suffit de modifier le paramètre correspondant dans LocalSettings.php:
`$wgUseImageMagick = false;`
Dans mon cas en tout cas, ça marche et je n'en demande pas plus! J'espère que ça aidera celles et ceux qui passeraient par ici.
Bonne fin de WE!
Merci, @ChristopheD53 ! Pareil ici, et ta solution a fonctionné. Il faudrait presque pouvoir la proposer à MediaWiki pour le rajouter à leur page d'aide.