https://bugzilla.wikimedia.org/show_bug.cgi?id=72324
--- Comment #10 from Bawolff (Brian Wolff) <[email protected]> --- (In reply to Daren Welsh from comment #9) > I was reading this: https://www.mediawiki.org/wiki/Manual:$wgMaxImageArea > > Thank you for modifying it, though I think it could use some more detail. > > Can you provide an example of a case where you want a large (image) file > uploaded where it cannot be rendered/scaled? > > 1. I don't agree that you should allow a user to upload an image of a size > that will not be able to be scaled by whatever tool is being used because > the default action of the upload page is to take you to the file page with a > scaled version of that image. So that process just breaks in the case of a > large image. The upload page should stop the upload and report that the > image size is in excess of the $wgMaxImageArea value which will result in > memory issues when the image is automatically scaled. Maybe there should be > an option or separate special page for large images where you do not require > scaled versions. People uploading original source files. People uploading very high resolution scans of an image from a museum, that sort of thing. Sometimes people upload files to the wiki with the sole intention of "sharing" it with the group, and don't care about thumbnailing it at all. People use MediaWiki for a wide variety of purposes. > 2. I find the following scenario interesting: I increase the value of > $wgMaxImageArea (for example, to 100,000,000) but leave $wgMemoryLimit to > the default value. Then I go to the upload page to upload a new version of > an image that is very large but under the new limit of $wgMaxImageArea (and > $wgMaxUploadSize). After selecting the file, it creates the thumbnail > successfully. Note, the preview in the upload form happens on the client side. Your web browser makes the thumbnail succesfully, not MW (Which is why the server side limits don't come into play). > But when I click on the upload button, I get a blank page. Now > the only way to fix that page is to increase $wgMemoryLimit in LocalSettings > (at least temporarily for that one page load). It seems like there should be > some mechanism to relate these two values together. I agree that that is rather bad behaviour. If using image magick you get an error message instead of a blank page (A hard to comprehend error message, but an error nonetheless). I agree that ideally the two would be related, although its kind of complicated. The amount of memory required and the size of the image are related, but is not exactly a functional link. Different images of the same size sometimes take different amount of memory, and the amount of memory taken up differs depending on what program you use to scale the image, what version of the program is in use, and possibly which platform you're running on. So its not like we can say - The area limit is foo, so the memory limit needs to be bar. Some people may also not like MW playing with memory limit, as that's meant as a stop valve for the web server to not steal all the computer's memory and cause problems for others on the server (OTOH, anyone who is seriously using the memory limit like that should be setting it in PHP config and not allowing MW to play with it). > > Remember, the reason I posted this report and am investigating the details > is that one of our users uploaded an image with no warning or push-back and > was met with two broken pages: the file page itself and a page that > displayed a thumbnail of that image. It seems like there should be something > in place to "more-gracefully fail". I agree that the failure mode here is quite sucky. Especially the blank page part. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
