Page MenuHomePhabricator

GIF and PNG images are not displayed
Closed, ResolvedPublic


GIF and PNG images are note displayed. See by example :

If you use [[Image:Vikidia 16px.gif|left]] or another parameters, mediawiki
doesn't display it.

But, we cas see it on

On LocalSettings.php, we have the following parameter :

To enable image uploads, make sure the 'images' directory

is writable, then set this to true:

$wgEnableUploads = true;

$wgUseImageResize = false;

$wgUseImageMagick = true;

$wgThumbnailScriptPath = "$wgScriptPath/thumb.php";

il faudra tester (inspir? de - Dake)

Les 4 lignes pr?c?dentes ont ?t? ajout?es ou modifi?es le 28 juillet 2007

$wgFileExtensions = array('png','jpg','svg','jpeg','ogg','doc','xls','gif','mp3','sxc','pdf','nse');

$wgImageMagickConvertCommand = "/usr/bin/convert";

$wgAllowTitlesInSVG = true;

If you want to use image uploads under safe mode,

create the directories images/archive, images/thumb and

images/temp, and make them all writable. Then uncomment

this, if it's not already uncommented:

#$wgHashedUploadDirectory = false;

If you have the appropriate support software installed

you can enable inline LaTeX equations:

$wgUseTeX = true;

$wgMathPath = "{$wgUploadPath}/math";

$wgMathDirectory = "{$wgUploadDirectory}/math";

$wgTmpDirectory = "{$wgUploadDirectory}/tmp";

SVG images aren't displayed, too.

But, jpg images are normally displayed.

Version: 1.12.x
Severity: major



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:07 PM
bzimport set Reference to bz12719.
bzimport added a subscriber: Unknown Object (MLST).

After new test, no image can be resized with the latest version of mediawiki. 1.12. svn, even jpg images

You seem to have unnecessary calls to thumb.php going on:

This fails as the requested thumb size is the same or larger than the actual image.

In most circumstances you should not use thumb.php, and should set $wgThumbnailScriptPath to false; thumbs will be generated at parse time as required.

However there does appear to be some issue with the thumb script being invoked incorrectly for full-size images.

Fixed in r30044. The Image base handler class now returns false for getTransformScript for formats that don't require rendering when the width is equal or greater to the base image size (in which case it wouldn't get thumbed normally, and thumb.php would return an error). That now means fallback to the regular path, in which case you'll get a direct use of the original file.

(Long ago thumb.php would give you back a copy of the original file when you requested a larger size, but that was problematic with its use in autogeneration.)