ggt wrote:

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;

Set:
$wgHashedUploadDirectory = false;

and move all your files into one dir.

ggt wrote:

$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 [http://www.mediawiki.org/wiki/Manual:Image_Administration#Data_storage 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.

Gary.

ggt wrote:

Sorry - forgot to add /thumb to the paths above.

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.

ggt wrote:

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.

Regards,
Gary.

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 ) {

1. Client-side image scaling, use the source URL
2. Using the destination URL in a TRANSFORM_LATER request would be incorrect return new ThumbnailImage( $image, $image->getURL(), $clientWidth, $clientHeight, $srcPath );

m4swart wrote:

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.

(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.

r48787 follows up to use the preexisting $wgUseImageResize (defaulting to true but actually settable to false again!) instead of creating a new var.