Project:Support desk/Sections/Images

__NEWSECTIONLINK__

= Image Support =

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) Still waiting for a hand... MedRevise

Anyone? MedRevise 22:58, 12 January 2010 (UTC)

GIF scaling

 * MediaWiki version: Current version on the Commons.
 * PHP version: Current version on the Commons.
 * MySQL version: Current version on the Commons.
 * URL: Commons.

Can some developers and system admins have a look here:
 * commons:Commons:Graphics village pump

—Timeshifter 16:12, 14 December 2009 (UTC)

Difference between Preview & Saved page (Resolved)

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.4
 * MySQL version: 5.0.24
 * URL: http://www.trashlx.com/CnrsEmsi

Hello, I've a problem with images & thumbnails.

When I look to the preview, when editing an article I can see the images.

But when I save the page, only the border appears but not the image itself.

I checked the permissions of images, they are fine : rw-r--r--

Any idea ? Thanks

Stanislas Garret — 81.56.185.93 15:33, 15 December 2009 (UTC)

Just the $wgUploadBaseUrl to be set to base path of the wiki (with the trailing /)

Stanislas Garret - 81.56.185.93 05:41, 16 December 2009 (UTC)

Embedding an external image when the URL does not end in png/gif/jpg

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.6-3ubuntu4.4 (apache2handler)
 * MySQL version: 5.0.75-0ubuntu10.2

I've switched on $wgAllowExternalImages so that I can embed graphical Bugzilla reports into my wiki. The Bugzilla report is accessible via a URL (a large one, that contains all the report parameters) like:

http://bugzilla/report.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&cumulate=0&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&longdesc=&longdesc_type=allwordssubstr&short_desc=&short_desc_type=allwordssubstr&type0-0-0=noop&value0-0-0=&x_axis_field=component&y_axis_field=product&z_axis_field=&format=bar&ctype=png&action=plot&width=300&height=150

However, to embed this in the wiki I'm having to add a dummy filename on the end (e.g. chart.png) so that the MediaWiki parser recognises the URL as an image, e.g.

http://bugzilla/report.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&cumulate=0&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&longdesc=&longdesc_type=allwordssubstr&short_desc=&short_desc_type=allwordssubstr&type0-0-0=noop&value0-0-0=&x_axis_field=component&y_axis_field=product&z_axis_field=&format=bar&ctype=png&action=plot&width=300&height=150&chart.png

The embed now works great, but is there an easier way to do this without the dummy filename on the end? Is there some wiki markup that I can enclose the URL in that will indicate that the URL is an image and therefore the dummy filename will not be required?

—213.48.14.66 11:39, 16 December 2009 (UTC)

Image pages don't display
I can upload pictures to my wiki, and they display properly when an article on my wiki links to them, but when I click on the image to go to the image's page, I get the following message:
 * MediaWiki version: 1.15.1
 * PHP version: 5.2.11
 * MySQL version: 5.1.41
 * URL: it's a private wiki, so I don't think that would be helpful

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "wfGetImageTags". MySQL returned error "1146: Table 'DataBase.imagetags' doesn't exist (localhost)".

How I fix this problem? —Cheeselouise 07:45, 29 December 2009 (UTC)

(RESOLVED) Wrong edit tab links at image pages from shared images ($wgForeignFileRepos)

 * MediaWiki version: 1.15.1
 * PHP version: 5.2.4-2ubuntu5.7 (apache2handler)
 * MySQL version: 5.0.51a-3ubuntu5.4

I set up a wiki family with a commons wiki to share images between wikis. Everything works fine - the images are shown on any other wiki (e.g. newswiki) and when you click the image you get a hint that the image is from a shared repository.

Now when you click the sections edit links you are redirected to the original commons wiki image page (as it should be): Correct - (edit section link): http://commons.mywiki.de/w/index.php?title=File:Test.jpg&action=edit&section=1

BUT when you use the edit/create tab at the top of the page you won't be redirected to the commons wiki but stay in the newswiki and cannot edit the original image description (but create a new description page in the newswiki, which is completely wrong):

Error - (edit tab link): http://newswiki.mywiki.de/w/index.php?title=Datei:Test.jpg&action=edit

So why are the page tab links not rendered correctly, while the section edit links are? Is there any help?

Here is my setup: if( $wgDBname != 'commons' ) { $wgForeignFileRepos[] = array( 		'class' => 'ForeignDBRepo',		'name' => 'shared',		'directory' => '',		'url' => 'http://commons.mywiki.de/w/images',		'hashLevels' => 2,		'thumbScriptUrl' => false,		'transformVia404' => false,		'dbType' => 'mysql',		'dbServer' => 'localhost',		'dbUser' => 'wikiuser',		'dbPassword' => '***',		'dbName' => 'commons',		'dbFlags' => ($wgDebugDumpSql ? DBO_DEBUG : 0) | DBO_DEFAULT, // i.e. '16'		'tablePrefix' => '',		'hasSharedCache' => true,		'descBaseUrl' => 'http://commons.mywiki.de/wiki/Image:',		'scriptDirUrl' => 'http://commons.mywiki.de/w',		'fetchDescription' => true,		'wiki' => 'commons',	); $wgDefaultUserOptions['watchcreations'] = 1; }
 * 1) New commons settings

Thank you in advance,

—Svantje 17:12, 6 January 2010 (UTC)
 * This is the expected behaviour, for example on Wikipedia: w:File:Yuan chinese gun.jpg. Users of local wikis are supposed to be able to create and edit their local description pages for files from shared repos. For example, to categorise images. Because those sections you mentioned are from commons, their edit links correctly point to the right wiki. Max Semenik 17:33, 6 January 2010 (UTC)
 * Thank you Max. It seems, that the behaviour is different for the german wikipedia: de:File:Ziege.jpg. The philosophy seems to be, that all image descriptions belong to the commons page. But categorising is a good point. Anyway, do you have a hint how to change the tab links to immitate the de-wikipedia behaviour? --Svantje 11:14, 7 January 2010 (UTC)
 * They use a JS hack, see de:MediaWiki:Common.js, starting from "Lokaler Bilddiskussionsseitenlink eines Commonsbildes verweist nach Commons". Max Semenik 12:41, 7 January 2010 (UTC)
 * You're great. Thank you!--Svantje 15:48, 7 January 2010 (UTC)

Images from Wikimedia Commons sometimes show, sometimes not
This error apparently comes and goes like the wind. Even at the very same time some images show and some images don't. I cannot see any logical pattern in this. Can somebody help? —87.104.58.186 08:28, 13 January 2010 (UTC)
 * MediaWiki version: 1.15.1
 * PHP version:
 * MySQL version:
 * URL: http://wikilinksworld.info

Problems showing images on my new wiki
Pictures from Wikimedia Commons sometimes show, sometimes not. It is completely unpredictable. Very unsatisfacory indeed. Can somebody help? —87.104.58.186 08:49, 13 January 2010 (UTC)
 * MediaWiki version: 1.15.1
 * PHP version:
 * MySQL version:
 * URL: http://wikilinksworld.info


 * MediaWiki version:
 * PHP version:
 * MySQL version:
 * URL: http://wikilinksworld.info

Some of the images (from Wikimedia Commons) show, some don't. The pattern seems to be completely illogical and unpredictable. Am I really the only one to whom this has happened. What can the reason be. And how (if at all) can it be solved?

—87.54.18.7 11:04, 13 January 2010 (UTC)