Last modified: 2011-04-04 21:28:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12970 - Problem creating image thumbnails in 1.11
Problem creating image thumbnails in 1.11
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
Other Solaris
: Normal major with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2008-02-08 13:30 UTC by Gary Thompson
Modified: 2011-04-04 21:28 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Gary Thompson 2008-02-08 13:30:43 UTC
When I upgraded from 1.10 to 1.11, image thumbnails stopped showing.

Server runs PHP5 in SAFE_MODE (sorry).

Problem is that directories created in 'thumb' are being created with mode 0755, and there are problems with ownership of files and folders meaning that MW couldn't write the thumbnail to it's created folder.

We have resolved this in the meantime by changing ownership of my wiki installation to the web server - but this now leaves me with no editing capabilities for LocalSettings and installations of extensions.

If servers are being run under safe mode, it would make sense that there could be a local setting to disable creation of directories for thumbnails.

Comment 1 Gary Thompson 2008-02-08 13:34:30 UTC
Sorry - forgot to add I'm having to use GD.

I also tweaked LocalSettings to force creation of deleted images in the root of 'deleted' to work around the same issue there with:
$wgFileStore['deleted']['hash'] = 0;
Comment 2 Brion Vibber 2008-02-13 05:32:58 UTC
$wgHashedUploadDirectory = false;

and move all your files into one dir.
Comment 3 Gary Thompson 2008-02-13 09:11:24 UTC
$wgHashedUploadDirectory controls the creation of sub-sub directories.  Setting this to false stops the creation of those folders but does not stop the creation of folders with the filename of the thumbnail. See [ Data Storage].

With setting=true path is: pathofwiki/images/x/xy/MyPicture.png/MyPicture.png
With setting=false path is: pathofwiki/images/MyPicture.png/MyPicture.png

In safe mode the folder MyPicture.png can be created but the image MyPicture.png cannot then be placed in it.

Comment 4 Gary Thompson 2008-02-13 09:13:10 UTC
Sorry - forgot to add /thumb to the paths above.
Comment 5 Tim Starling 2008-02-26 18:07:20 UTC
This is a regression from 1.10 to 1.11 because in 1.10, many people were using client-side scaling without realising it. In 1.11, there's no way to disable server-side scaling if GD is available. Unfortunately, as the reporter explains, the 1.5+ thumbnail directory layout is broken with safe_mode, due the the UID check. 

The solution is to reintroduce a global variable to force client-side scaling, and to warn the user during install that client-side scaling will be used and that this is bad.
Comment 6 Gary Thompson 2008-02-27 10:21:44 UTC
Thanks, Tim.

Is this something that I can work-around beyond my current fix of having the web server 'own' all of my wiki, or do I have to wait now for a minor release?

As things currently stand I no longer have ownership of LocalSettings, and can't add in any extensions without the university web admin uploading them for me.

Comment 7 Tim Starling 2008-02-27 15:44:34 UTC
To force client-side scaling, use something like this:

Index: includes/media/Bitmap.php
--- includes/media/Bitmap.php	(revision 31344)
+++ includes/media/Bitmap.php	(working copy)
@@ -74,7 +74,7 @@
 			$scaler = 'client';
-		if ( $scaler == 'client' ) {
+		if ( true ) {
 			# Client-side image scaling, use the source URL
 			# Using the destination URL in a TRANSFORM_LATER request would be incorrect
 			return new ThumbnailImage( $image, $image->getURL(), $clientWidth, $clientHeight, $srcPath );
Comment 8 MarcoSwart 2008-05-02 12:29:57 UTC
When I installed a new wiki with 1.11.1 on a shared hosting account some time ago, I had the same problem. This fix solved it. Thanks! Your proposal in #5 is more than welcome, though. My impression is that there are more relatively unexperienced users like myself, who are quite likely to use shared hosting and would be very happy if you do not have to look beyond the installation instructions to get basic functionality like thumbnailing.
Comment 9 Chad H. 2009-03-03 21:22:37 UTC
(In reply to comment #5)
> The solution is to reintroduce a global variable to force client-side scaling,
> and to warn the user during install that client-side scaling will be used and
> that this is bad.

Added $wgForceClientThumbnails in r47992. Didn't add warning to installer since we already warn on safe_mode and this warning already mentions potential thumbnail problems.
Comment 10 Brion Vibber 2009-03-25 10:06:05 UTC
r48787 follows up to use the preexisting $wgUseImageResize (defaulting to true but actually settable to false again!) instead of creating a new var.

Note You need to log in before you can comment on or make changes to this bug.