Project:Support desk/Sections/Images

__NEWSECTIONLINK__

= Image Support =

Cannot allocate memory error while displaying thumbnails of larger images.

 * MediaWiki version: 1.15.0
 * PHP version: 5.2.5 (cgi)
 * MySQL version: 5.0.77-community
 * URL: http://wiki.harfordhackerspace.org/index.php?title=Projects

When including images which need to be resized on the fly I am getting this error instead of the resized image.

"Error creating thumbnail: libgomp: Thread creation failed: Cannot allocate memory"

However, smaller images render just fine. I have tried putting a php.ini file in the home directory and increasing the memory_limit to as large as 8gigs and it still did not correct the problem.

—69.250.233.187 23:17, 13 June 2009 (UTC)

I love it when I answer my own questions only seconds after posting for support and hours after trying everything. All I had to do was use GD which was done by setting $wgUseImageMagick = false; in my LocalSettings.php file.

Updating new versions of existing files

 * Moved from Project:Forum Happy ‑ melon 08:28, 19 June 2009 (UTC)

I don't know if this is the right place to post but my company has a wiki we use internally that is a MediaWiki and I am having trouble getting it to recognize and link to a new version of an existing file. So say it is a report that I add to with more data every few weeks but has the same name, I upload the new version and even retype the link and it still goes back to the old report. any advice on how to make it work so I don't have a million versions of what is essentially the same document? thanks (6/18/2009)


 * When you view the file description page, does it show the curent version of the file? Have you tried null-editing (editing and saving with the same content or a trivial change) the file description page? Happy ‑ melon 08:31, 19 June 2009 (UTC)

Is the File History page the same as the File Description page? If so, then it does. I am not really sure what null-editing is or how it relates to this but these files are word or excel documents that we link to where I make very small updates and changes to every few weeks as more data comes in, they're reports that build on itself. Sorry, I'm really new to this so I am don't even know the right language or anything, this was just sort of dropped in my lap. Andrea 6/19/2009


 * Yes, the file description page is the page you reach when you follow a link like File:Example.png. Essentially what a null-edit does it to force the page to be rebuilt from scratch (and makes a note for all descendent pages, such as pages that include the file, to be rebuilt in the same way.
 * Hang on a minute, though. How are you making these links?  You can't 'thumbnail' Excel documents into pages, you'll only get a link.  Are you linking to the file description page using wikimarkup (like  )??  Or are you linking to the file directly (using an external link like  )??  If the latter, then this is the expected behaviour: every version of a file that you upload is stored separately - that's the wiki way - and the software automatically keeps track of which one is the 'current' version and displays that on the file description page.  Which method are you using? Happy ‑ melon 12:45, 19 June 2009 (UTC)

Our links are as [[Media:Name_of_Report.doc]] and when you click it opens the word/excel file. I just upload the file and I create that link and it works. Is that a wikimarkup? When I reupload a file of the same name the File History page shows all the uploads of it and displays the date and time of the last upload and says current, but when I click on the link on the page, the old version pops up, even if I re-enter the link to it. Should I be linking to it in a different way? We're wiki-novices here that were given a quick run-down but are trying to figure this all out on our own now. Thanks for your patience with this. Andrea 6/19/2009 8:55 EST


 * Ah, I see, and yes, that is wikimarkup and should work corectly. And you say that the links don't update, even if you edit the page containing the link and resave it? That is a bit bizzarre.  If you add another link to the same document on the same page, does the new link point correctly?  Does adding the new link make the first link also work?  Happy ‑ melon 13:16, 19 June 2009 (UTC)

That is correct, it's not updating them, even if I add another link to the same page, all links will go to the older version of the document. Does that mean this is somehow a glitch and its not operation correctly? Andrea 6/19/2009 10:21 EST


 * Well that ain't right :D... What caching settings are enabled on your wiki? There are a whole host of different components - see Manual:Cache - variables like $wgUseParserCache, etc.  Which do you have enabled? Also, can you give the MediaWiki/SQL/OS/Server versions, like other threads on this page? Happy ‑ melon 07:39, 20 June 2009 (UTC)

Sorry, I've been outta the office for a bit. Bear with me as I am not technical at all, the cache settings are a long list but that Parser Cache settings are: $wgEnableParserCache, $wgRenderHashAppend, $wgParserCacheExpireTime, and $wgParserCacheType -- is this in any way helpful to you? where do I find the MediaWiki/SQL/OS/Server versions? The OS is Windows XP... sorry that I know so little. Can updating a file really have to do with cache settings? Andrea 6/25/2009 8:47 EST


 * Either your browser or the server might be caching the file; purging the article where you link to the file (and possibly also the file "article") should fix this. You may also need to try bypassing your browser cache. —Emufarmers(T 19:39, 27 June 2009 (UTC)

ImageMap not working, neither RandomImage

 * MediaWiki version: 1.13.4
 * PHP version: 5.1.6 (apache2handler)
 * MySQL version: 	5.0.22
 * Extensions:
 * RandomImage (Version r37641)
 * ImageMap (Version r35980)
 * LocalSettings for images:

The use of command. And the file is fine, it loads without any issues directly off the server. So that rules out it being a corrupted file. Seems now that it is something do with how the file is represented in the DB. -- Dr DBW |  talk  05:24, 24 July 2009 (UTC)


 * More information. The subdirectory structure for where images are saved on the server is based on the MD5 for the file.  Example I was given is    so that file will be located in the b/bc subdirectory. -- Dr DBW  |  talk  02:52, 30 July 2009 (UTC)

Attempted to upload a new file over the old one, using the same file name and once you hit "upload file" end up with a blank page, so seems the same error occurs.-- Dr DBW |  talk  03:31, 30 July 2009 (UTC)

Image Security for Dummies?
I'm really confused by all of the info on image security... I don't know much about directory permissions (read: essentially nothing), don't use any of the text-based operating systems that seem to be assumed, and am just generally confused by the info. Is the default configuration (that is, the file types being strictly restricted to jpg, jpeg, png, and gif) enough, if I don't enable other formats? What could happen? In essence: How do I go about securing uploads on Windows Vista, or are the secure as-is? (my wiki is currently just locally-hosted, not live on the web, using MW 1.15.0). Thanks! --Drilnoth 01:35, 9 July 2009 (UTC)
 * Alternatively, would restricting image uploads to admins or 'crats prevent all security risks coming from users not in those groups? --Drilnoth 21:59, 12 July 2009 (UTC)


 * If you have it set to just image formats, then from my limited understanding of it you can't have any issues with hacks etc, since the files have to be uploaded with those extensions. And those extensions can't be executed or used to deliver a payload. -- Dr DBW  |  talk  04:24, 24 July 2009 (UTC)
 * Awesome; thanks. That's kind of what I thought, but I wanted to double check. --Drilnoth 03:06, 31 July 2009 (UTC)