Last modified: 2011-04-04 21:28:17 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. Gary.
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.
$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.
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.
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 ) { # 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 );
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.
