Project:Support desk/Sections/Images

__NEWSECTIONLINK__

= Image Support =

Jpeg File Resolution 5000*5000 Pixel Bugs.Thanks
When I Upload Jpeg File Resolution 5000*5000 Pixel. The 'Special:Newimages' Can't Be Load (Blank Page), How Can I Solve ? Thanks.
 * MediaWiki version: 1.11.1
 * PHP version: 5.1.33
 * MySQL version: 5.29
 * URL: Intranet

Please Help, Hope Help.
 * See Blank page. Most likely, you're hitting memory and/or execution time limit. See relevant docs on how to tweak your PHP settings. Max Semenik 17:32, 16 November 2009 (UTC)

Images no longer appear
MediaWiki 	1.15.1

PHP 	       5.2.9 (apache2handler)

MySQL 	       5.0.81-community

URL: http://www.evolution-rpg.com/wiki/index.php/Main_Page

I just finished upgrading my wiki to version 1.15.1. I've noticed that any images that are linked from off site, no longer appear by posting the url to the image. Does 1.15.1 allow the use of off-site images using just their url or is there another way image links should be formatted?

—71.32.70.23 20:53, 14 September 2009 (UTC)

(RESOLVED) JPEG thumnailing errors (using GD)

 * MediaWiki version: 1.15.1
 * PHP version: 5.3.0 (apache2handler)
 * MySQL version: 5.1.39-log
 * URL: (internal)
 * OS: Red Hat RHEL4

Quite a few people seem to encounter this error message within a grey box:
 * Error creating thumbnail: Incomplete GD library configuration: missing function imagecreatefromjpeg

I had that issue, but after some hours, resolved it. Some PHP 4.x and 5.x versions of PHP have a bug where the libjpeg is detected but not enabled during the ./configure step; this is fairly prevalent on Red Hat/RHEL/CentOS systems. The fix for this (if you don't want to use ImageMagick) is to recompile PHP. First, find out (from phpinfo) what the existing ./configure switches were, and add --with-jpeg-dir before --with-gd. make clean ./configure --with-various-switches --with-jpeg-dir --with-gd --with-more-switches make make test #switch to root make install Afterwards, restart the webserver (for Apache on Red Hat: service apache stop then service apache start ). To test, simply view the File:... page again (no need to upload again). For more information see the comments on PHP: imagecreatefromjpeg (function synopsis)

—202.53.35.32 00:28, 9 October 2009 (UTC)

(Resolved) Image uploading/viewing causes internal server error/execution timeout with files bigger than 5kb

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.9 (cgi-fcgi)
 * MySQL version: 5.0.67-userstats-log
 * URL: locked down

Basically everyone is unable to upload any large files to the wiki. I've checked all the php configurations for max post size/upload limit and they're all at 8M or higher and viewing the phpinfo confirms this (as does the limit shown on the mediawiki upload form). If i attempt to upload something with a size of about 5-10kb it works absolutely fine. However if I try to upload something that is 900kb, the upload form eventually times out with an Internal Server Error (enabling display_errors etc. in the LocalSettings.php has given no details thus far). The error shown in the server error log is:

[Sun Oct 11 04:38:48 2009] [error] [client xxx.xxx.xxx.xxx] Premature end of script headers: index.php, referer: http://wiki.xxx.com/index.php?title=Special:Upload

This is due to php running as a cgi binary instead of a php module. Usually a premature end of script headers indicates that no output was sent from php which means php encountered a max execution timeout. I've tried raising this timeout to 60 seconds from 30 but got the same problem.

Curiously, checking the http://wiki.xxx.com/index.php?title=Special:ListFiles shows the file DID upload correctly and I can view the file in it's physical path on the FTP. But if I then try to view this image on the wiki I get the same timeout/php error I described above. Again, just to remind you - files of 5-10kb work fine with no problems.

My last observation is that after the timeout has occurred, two processes are left hanging when viewing "top" via SSH. The processes are "convert" and "ulimit4.sh" which I have to manually kill.

I hope this helps you guys figure it out, thanks.

Edit - Interestingly enough, if I allow the page to start hanging (before the internal server error) and then kill the convert and ulimit4.sh processes then the page loads fine, but gives the error "Error creating thumbnail:" in the thumbnail box.

—Ephialtes 11:45, 11 October 2009 (UTC)


 * Fixed it by setting $wgUseImageMagick = false; in LocalSettings.php to force it to use PHP GD instead. I tried this earlier but it was setting it true lower in the file, my bad! —Ephialtes 14:19, 11 October 2009 (UTC)

Problem with forms and files

 * MediaWiki version: 1.15.0
 * PHP version: 5.2.5 (cgi-fcgi)
 * MySQL version: 5.0.67.d7-ourdelta-log
 * URL: http://www.videoville.org/wiki/

Hello,

My wiki is having problems with file uploads (also, all forms are broken). I'm guessing this is a database issue? The wiki essentially says 'Well, that was nice' when you try to upload, does nothing.

CHMOD is a-ok.

The change appeared after I updated the site to 1.15.0.

—69.242.253.125 13:25, 30 November 2009 (UTC)

Uploaded images have permission 600, but thumbnails have permission 644

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.11 (cgi-fcgi)
 * MySQL version: 5.0.77
 * URL: http://www.southyorkshireorienteers.org.uk/w/index.php?title=Main_Page

Images uploaded to my wiki are given file permission (CHMOD) 600, which means they are not visible, which is a problem. The associated thumbnail file that is created during the upload has permission 644, so it is visible. Which setting(s) in which file(s) do I need to change in order that uploaded image files have a permission that makes the file visible? Thanks.

—Martin Ward 10:55, 9 December 2009 (UTC)

Error on uploading PNGs

 * MediaWiki: 1.11.1
 * PHP: 5.2.6 (cgi)
 * MySQL: 5.0.81-community
 * URL: MedRevise.co.uk

Whenever anyone tries to upload a PNG, we get this error: "The file is corrupt or has an incorrect extension. Please check the file and upload again."

Any ideas?

—MedRevise 17:19, 9 December 2009 (UTC)