Talk:MediaWiki 1.19/Flow

Previous page history was archived for backup purposes at Talk:MediaWiki 1.19/LQT Archive 1 on 2015-07-10.

bugzilla:42730. «I suspect one of the environment (TMPDIR, TMP or TEMP) is set to a directory which is NOT writable by your webserver. In such a case, you have to set $wgTmpDirectory in your LocalSettings.php to a directory writable by your webserver.»

Hey there, since I have updated my 1.18.3 release of mediawiki to 1.19.0 I can't get new thumbnails created. If I upload a new picture I get the following error:

Error creating thumbnail: Unable to save thumbnail to destination

in my LocalSettings.php there is the following:

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads  = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";
#$wgUseImageResize = true;
$wgImageMagickTempDir = "/srv/httpd/vhosts/wiki.laub-home.de/htdocs/images/imtmp";
#$wgCustomConvertCommand = "/usr/bin/convert -resize %wx%h %s %d";

ImageMagick 6.6.0-4 is installed on a debian squeeze system. I can't see any errors in the apache logfiles and I didn't change the rights on my image folder. Anyone has the same problem? Greeting Andreas

Is this your issue?

No, I test the patcht, but still didn't work. If it's an open_base_dir thing, I should see something in the apache logs.

I made a mistake adding the patch. Forgot to delete the line

return sys_get_temp_dir();

Now it works fine! Thanks for the Patch and thanks for your help!

Hi Sumana,

I found a problem in the patch for open_base_dir. I changed the upload_tmp_dir to /srv/php-tmp/ in my php.ini. This is a security thing. So the patcht checks first for /tmp which is the system tmp directory and this drops out an open_basedir error in apache log. Then it goes to the php.ini upload_tmp_dir, which works. I think the order of the patch schould changed to first look at php and then the system temp dir to avoid the error in apache log.

Greetings Andreas

Andreas, can you go ahead and just submit a corrected patch either via Developer access or via the bug in Bugzilla?

Hi, I don't have access to Bugzilla, so here is my Patch, the whole function wfTempDir() looks like that on my Mediawiki:

function wfTempDir() {
        foreach( array( 'TMPDIR', 'TMP', 'TEMP' ) as $var ) {
                $tmp = getenv( $var );
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
                }
        }
        if (ini_get('upload_tmp_dir')!==false) {
                $tmp = ini_get('upload_tmp_dir');
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
                }
 
        }
        if( function_exists( 'sys_get_temp_dir' ) ) {
                $tmp = sys_get_temp_dir();
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
                }
        }
        # Usual defaults
        return wfIsWindows() ? 'C:\Windows\Temp' : '/tmp';
}

You do have access to Bugzilla: https://bugzilla.wikimedia.org/

Hi, I don't have access to Bugzilla, so here is my Patch, the whole function wfTempDir() looks like that on my Mediawiki:

function wfTempDir() {
        foreach( array( 'TMPDIR', 'TMP', 'TEMP' ) as $var ) {
                $tmp = getenv( $var );
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
                }
        }
        if (ini_get('upload_tmp_dir')!==false) {
                $tmp = ini_get('upload_tmp_dir');
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
                }
 
        }
        if( function_exists( 'sys_get_temp_dir' ) ) {
                $tmp = sys_get_temp_dir();
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
                }
        }
        # Usual defaults
        return wfIsWindows() ? 'C:\Windows\Temp' : '/tmp';
}

Linked to the patch in the bug.

And now also bugzilla:42730.

I can save file, but cannot create thumbnail. It say Error creating thumbnail: Which my Setting was:
$wgAllowTitlesInSVG = True;
$wgFileExtensions = array('pdf', 'png', 'gif', 'jpg', 'flv', 'swf', 'mp3','doc','xls','pdf', 'svg');
$wgFileExtensions[] = 'svg';
$wgSVGConverter = 'ImageMagick';
$wgMaxImageArea = 100 * 1000 * 1000;
$wgMaxShellMemory = 202400;
If i change $wgSVGConverter into 'rsvg' it say error Error creating thumbnail: env: python: No such file or directory So there is any suggestions?

Have you checked where rsvg is located on your machine?

Hey, I seem to be having the same problem, but the patch doesn't help: No matter what I do, I get the same error message.

It's a brand new MW installation, 1.19.0, in a shared hosting environment. I have php 5.3.10 (apache2handler) and GD library enabled. My "upload_tmp_dir" in phpinfo.php says "/tmp", and the /tmp directory on my server has rights drwxrwxrwt.

This is what I have in LocalSettings.php - uncommenting the ImageMagick variables has no effect:

$wgEnableUploads = true;

1. $wgUseImageMagick = true;
2. $wgImageMagickConvertCommand = "/usr/bin/convert";

I have tried to get some more error messages out of the php, using:

error_reporting( E_ALL ); ini_set( 'display_errors', 1 ); $wgShowExceptionDetails = true;

in LocalSettings.php, but that doesn't produce anything either.

Any ideas???

Forgot to say, but the images directory in the MW installation has rights 777, as do all the subfolders.

Are you able to write to /tmp from your web process? Could you write a test script to verify this? If you don't know how, could you install a test I write to verify it?

Good question. Sure, pass me the script if you have one! (I think I could figure it out myself, but not without some effort...)

Some more info that I guess is relevant: I have another, older mediawiki installation running on the same server, where file uploads work fine. That is MW 1.15.1 though. I also just realized that php safe mode is enabled on our server. Is that a likely cause for trouble?

CORRECTION: I just realized that, although file uploading has worked fine for the purposes I have had till now, *thumbnailing* does not seem to work in any of the MW installations on our server. (Haven't had the need for thumbnailing until now.) So I guess this issue is not related strictly to version 19 of MW, but is a general issue with either MW or our server. Sorry about that.

Still, if anyone has any idea about how to diagnose this problem, I'd be thankful!

I tried the following:

<?php
$handle = fopen("/tmp/test.txt", "x");
if ($handle) echo "Success!";
else print_r(error_get_last());
?>

...which returns "failed to open stream: No such file or directory". According to php.net the 'x' flag should cause the file to be created if it doesn't exist, so I guess there is something wrong somewhere? I have allow_url_fopen=off in phpinfo, but that shouldn't matter, right?

Sorry for spamming the thread - I'm a noob. I changed the above script to point to the images directory, and then i get success. Could this be a php bug? (Or at least a very misleading error message...)

My open_basedir has "no value".

Excellent work on reproducing the problem since I took too long to get back to you. Could you try this script?

<?php


function dirTest( $label, $dir ) {
    echo "Test for $label: $dir\n";

    if( file_exists( $dir ) ) {
        echo "Dir exists\n";
        $s = @stat( $dir );
        if( $s === false ) {
            echo "Stat failed: $php_errormsg\n";
        } else {
            echo "Permissions: ". decoct( $s[2] ) ."\n";
            echo "Is dir: ". ( is_dir( $dir ) ? "true" : "false" ) ."\n";
            echo "Is writable: ". ( is_writable( $dir ) ? "true" : "false" )  ."\n";

            $file = tempnam( $dir, "test" );
            echo "Attempting to create: $file\n";
            $fh = fopen( $file, "w" );
            if( $fh !== false ) {
                $written = fwrite( $fh, "stuff" );
                if( $written === false ) {
                    echo "Error when writing: $php_errormsg\n";
                } else {
                    echo "Wrote $written bytes.\n";
                    if( fclose($fh) === false ) {
                        echo "Error when closing: $php_errormsg\n";
                    }
                }
                if( unlink( $file ) === false ) {
                    echo "Error removing $file: $php_errormsg\n";
                } else {
                    echo "Sucessfully removed $file\n";
                }
            } else {
                echo "Error opening for writing: $php_errormsg\n";
            }
        }
    } else {
        echo "Directory does not exist!\n";
    }
    echo "\n";
}

dirTest( "Unix tmp dir", "/tmp" );
dirTest( "Window temp dir", "c:/windows/temp" );
dirTest( "sys_get_temp_dir", sys_get_temp_dir() );
dirTest( "upload_tmp_dir", ini_get( 'upload_tmp_dir' ) );

btw, on my laptop this gives:

Test for Unix tmp dir: /tmp
Dir exists
Permissions: 41777
Is dir: true
Is writable: true
Attempting to create: /tmp/testjmWbDE
Wrote 5 bytes.
Sucessfully removed /tmp/testjmWbDE

Test for Window temp dir: c:/windows/temp
Directory does not exist!

Test for sys_get_temp_dir: /tmp
Dir exists
Permissions: 41777
Is dir: true
Is writable: true
Attempting to create: /tmp/test6nrzCk
Wrote 5 bytes.
Sucessfully removed /tmp/test6nrzCk

Test for upload_tmp_dir: 
Directory does not exist!

Thanks for getting back to me! The above script returns:

Test for Unix tmp dir: /tmp
Directory does not exist!

Test for Window temp dir: c:/windows/temp
Directory does not exist!

Test for sys_get_temp_dir: /tmp
Directory does not exist!

Test for upload_tmp_dir: /tmp
Directory does not exist!

For the record, there IS a directory that appears to me as '/tmp' in my command line. But I posted this question on stackoverflow, and a commenter suggested the problem could have to do with 'chroot'. This server is part of a large university network, so I am sure the setup is fairly complex.

It seems odd though, given that the user 'nobody' - which I am almost certain is the user running php scripts - is able to write to /tmp.

Is there any way to have the thumbnailing process use some other tmp folder, for instance one under the images folder - where I know i can write?

To be more precise: the reason I believe the php user can write to /tmp is that I find lots of files in that directory which have "nobody" as their owner, which is the same owner as I saw on the subfolders that the mediawiki system created under the images folder. The files I see in the /tmp folder all start with "sess_" followed by something that look like a hash, I assume they are some kind of temporary files created by the webserver. Unfortunately I do not at the moment have access to the apache error logs.

Interesting. There is $wgTmpDirectory, but wfTempDir() ignores it. Instead of trying to track this down further, go to your includes/GlobalFunctions.php and replace the body of wfTempDir() with:

function wfTempDir() {
  global $wfTmpDirectory;
  return $wfTmpDirectory;
}

I'll investigate why wfTempDir() ignores this. I'm sure there is a good reason, I just don't know it.

I assume that's a typo, the variable name should have a 'g' as in $wgTmpDirectory, right? That doesn't quite fix the problem, though. There is a small change: Before the image that I'm trying to upload didn't show up at all on the File:Filename.jpg page (the one that comes up after you click upload) - even though the full version of the image did get uploaded, where it should show on the page was just the error message. Now the full version of the picture is shown, but in the "File History" table below the same error message is shown under "thumbnail". so I guess this modification made the script crash a little later in the process?

Looking in the "thumb" directory there are now empty directories, which each have the same filename as an image I have tried to upload. (E.g. 'images/thumb/PICT0157.jpg/').

If I switch over to using ImageMagick, I get a different error message, saying something about safe mode preventing an external program to be called. Which I guess supports the hypothesis that this fix removed one problem, but the script still crashes later on.

Thank you very much for taking an interest in my problem - will still be grateful if you have any other ideas for a solution...

Sorry, yes, a typo.

> where it should show on the page was just the error message

What is the error message?

> so I guess this modification made the script crash a little later in the process?

I don't think so. I think you just need to regenerate the thumbnail. Try adding "?action=purge" to the File:Filename.jpg url. New files should upload with no problem.

> What is the error message?

I was referring to the same error message as we've been talking about all the time: "Error creating thumbnail" etc. Before it showed up two places: Where the picture should come, and in the "File history" table. Now it only comes in the table.

> New files should upload with no problem.

Nope. I always test with new files - the errors I am reporting apply to new files that I have not previously tried to upload.

Thanks for the explanation. At least we've moved it a bit.

Could you try this patch?

I'd love to try it, but I don't know how to get it in a format so I can apply it to my installation. I can't use the command that comes up if I click on "patch", because my environment doesn't let me run git (two of my machines say "command not found", the third says "not a git repository").

I emailed a patch to you. Let me know if it doesn't work.

I'm facing the same problem with a brandnew MediaWiki 1.19.1.

I tried the first proposed patch. The thumbs in my articles were not shown. However thumbnails were shown in the list of uploaded files. But at the same time I got dozens of error messages: "Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/www/web1388/html/:/var/www/web1388/phptmp/:/var/www/web1388/files/:/var/www/web1388/atd/:/usr/share/php/) in /var/www/web1388/html/mediawiki_test/mediawiki/includes/GlobalFunctions.php on line 2495"

I saw that there is another patch. Is it also available as a patch file for Tortoise SVN? I'm not familiar with git.

Will this bug be fixed in 1.19.2?

BTW: I run another wiki on the same shared hosting with MediaWiki 1.16.2 and all thumbnailing works fine on this installation. I don't use ImageMagick on any of my wikis.
My PHP version: 5.3.13-1~dotdeb.0 (cgi-fcgi)
MySQL version: 5.5.25-1

Thanks for your help!

This post was posted by Britpoper, but signed as Stefahn.

If you are sitting in the root of your MediaWiki installation and have access to patch, then this patch should be able to be applied like so:

 $ curl https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=patch;h=99fdc6e838d4c7f6a7135a06b58d0bb232ca611c | patch -p1

Mark, thanks for your excellent support (also via mail)!

Just for the record:
I managed to apply the patch to my 1.19.1 version.
Then I created a temp folder in the images folder (with chmod 775).
Then I added the following line to localsettings.php:

# Make sure this directory exists and is writable by the webserver!
$wgTmpDirectory = "$IP/images/temp";

Now thumbnails work fine again :)

Thank you, Stefahn! Was confronted with the same problem, then the patch + your temp folder solution made my day!

Hi,

I experience the same problem, but not able to use patch. What else can I do to get it back to work?

Cheers Yogie

Why can't you use the patch?

I'm on a shared host and do not have ssh or bash access I need to upload my files via FTP.

You can get the files to upload from here: includes/DefaultSettings.php, includes/GlobalFunctions.php, includes/Setup.php, includes/diff/DifferenceEngine.php, includes/filerepo/backend/TempFSFile.php, includes/objectcache/DBABagOStuff.php, maintenance/storage/checkStorage.php

Thank you so much, with these files I got it back to work! Yay! Outstanding support!

how do i update those without git? i only have ftp...

You can directly download the updated files - see the post by Mark on 4th of July (two posts above this).

After i install its working Fine i have the problem showing me after username exm. admin? end the colors have cheng to i dont know what to do please help any one P.S. Sorry for my bad English

Hey,

indeed, the patch did not work with my Wiki. I noticed that some thumbnails worked, others did not, independently of their file type (jpg, gif, ...). The only effect of the patch was that links to non-existent pages where not underlined red anymore, but black with a red question mark right next to it.

--Thorsten (talk)

hi

i have done all steps, but after it comes a white page when i do check and when im save my work its allways the same ->thumbnails do not work for me, the image couldnt save on the right place...sry for my bad english. my version is 1.19.1 . can you help me please....

best regards Barberman

Hello! Try this solution: http://jehy.ru/articles/2012/09/17/mediawiki-1-19-unable-to-save-thumbnail-to-destination/

Many thanks to Mark(for patch) and Stefahn(for code)

Replacing these files does solve the thumbnail problem, thanks. However, somehow my Common.css and Common.js pages won't show up anymore.

Can you link to your wiki so I can see what you're talking about? Or send me an email.

Thanks for your reply. Unfortunately the wiki is on our intranet so I can't send you the link.

I reverted to MW 1.19.2 and finally solved the problem using an environment variable for pointing to the temp dir as suggested as the second solution at http://jehy.ru/articles/2012/09/17/mediawiki-1-19-unable-to-save-thumbnail-to-destination/

I also used the temp dir path provided by my hosting provider instead of an MW internal path.

hth

I did a fresh Install of 1.20.2 today with no modification to the uploadpath or so and now I'm facing the same problem. How can I use the patch (if its suitable for the current version) on a host with no shell access. example ist at

http://blechschaden.bplaced.net/wiki/index.php?action=Test

while an 1.18 works on the same host out of the box

http://wiki.fivefivezero.bplaced.net

Ok I inserted all the files from the post of 4.Jul.2012. But now I get an MWException. With $wgShowExceptionDetails = true; it results in:

Preprocessor_DOM::preprocessToObj: generated node count limit exceeded

Backtrace:

1. 0 /users/blechschaden/www/wiki/includes/parser/Parser.php(2979): Preprocessor_DOM->preprocessToObj('$1 ??? {{SITENA...', 0)
2. 1 /users/blechschaden/www/wiki/includes/parser/Parser.php(3036): Parser->preprocessToDom('$1 ??? {{SITENA...')
3. 2 /users/blechschaden/www/wiki/includes/parser/Parser.php(540): Parser->replaceVariables('$1 ??? {{SITENA...')
4. 3 /users/blechschaden/www/wiki/includes/parser/Parser.php(4636): Parser->preprocess('$1 ??? {{SITENA...', Object(Title), Object(ParserOptions))
5. 4 /users/blechschaden/www/wiki/includes/cache/MessageCache.php(815): Parser->transformMsg('$1 ??? {{SITENA...', Object(ParserOptions), Object(Title))
6. 5 /users/blechschaden/www/wiki/includes/Message.php(618): MessageCache->transform('$1 ??? {{SITENA...', true, Object(Language), Object(Title))
7. 6 /users/blechschaden/www/wiki/includes/Message.php(436): Message->transformText('$1 ??? {{SITENA...')
8. 7 /users/blechschaden/www/wiki/includes/Message.php(476): Message->toString()
9. 8 /users/blechschaden/www/wiki/includes/OutputPage.php(790): Message->text()
10. 9 /users/blechschaden/www/wiki/includes/OutputPage.php(833): OutputPage->setHTMLTitle(Object(Message))
11. 10 /users/blechschaden/www/wiki/includes/Article.php(485): OutputPage->setPageTitle('Kategorie:Villo...')
12. 11 /users/blechschaden/www/wiki/includes/CategoryPage.php(73): Article->view()
13. 12 /users/blechschaden/www/wiki/includes/actions/ViewAction.php(37): CategoryPage->view()
14. 13 /users/blechschaden/www/wiki/includes/Wiki.php(427): ViewAction->show()
15. 14 /users/blechschaden/www/wiki/includes/Wiki.php(304): MediaWiki->performAction(Object(CategoryPage))
16. 15 /users/blechschaden/www/wiki/includes/Wiki.php(536): MediaWiki->performRequest()
17. 16 /users/blechschaden/www/wiki/includes/Wiki.php(446): MediaWiki->main()
18. 17 /users/blechschaden/www/wiki/index.php(59): MediaWiki->run()
19. 18 {main}

Since this is a 1.20 issue, I've copied your question here and replied there.

My solution for MediaWiki 1.20.3 has been to add the following line to LocalSettings.php

$wgTmpDirectory = ini_get('upload_tmp_dir');

Thanks man!

I could solve the problem in version 1.30.0 with changing the temp path setting:

I had:

$wgTmpDirectory     = "{$wgUploadDirectory}/tmp";

but it should be with "e":

$wgTmpDirectory     = "{$wgUploadDirectory}/temp";

even creating a tmp folder with full access right did not help, the path seems to be hard wired to 'temp' anywhere else..

thumbnails stopped working after some change in server software. possibly php version changed. thumbnails worked fine before that. i got 777 on images folder. what can be the cause?

... and i get "Error creating thumbnail: sh: /usr/local/bin/convert: No such file or directory"

Those for 1.19 and 1.20 seem to have disappeared.

Thanks for pointing this out. This is because of the move to gitblit.

Hello i've some problems with my wiki configuration too, including displaying .svg thumbs, it didn't work this time, but i have figure out, why the upload function generally don't work at this point, after reading and thinking of your conversation, i trying something and now it works fine for pictures like .jpg or .png.

Make following step: 1) put this line in your ls.php, save it and upload, don't forget to back up your latest working ls.php.

<source lang="php">

1. 1. To enable image uploads, make sure the 'images' directory
   2. is writable, then set this to true:

$wgEnableUploads = true; $wgDisableUploads = false; # Enable uploads

1. $wgUseImageMagick = true;
2. $wgImageMagickConvertCommand = "/usr/bin/convert";

$wgUploadDirectory = "{$IP}/images/"; </<source>

Sorry for moving this out of the thread... I did that before I realized you were offering a solution. And, now I can't move it back :(

Hello, ah no problem, hoping it helps everyone, if you would like to post it in the entire thread, then you can do it. In my wiki configuration works it, but thumbnailing .svg did not working.

I don't get it. What does this fix?

It is a possible solution for user, having trouble with enabling fileupload. By the way: my wiki can't create thumbnails of svg's, getting instead an output textmessage with following content:

Fehler beim Erstellen des Vorschaubildes: sh: convert: not found

i'm not sure, where the problem is, any help for solving this is appreciated.

You need to install imagemagick. What sort of system is your host?

Its all on a webserver from my hoster:

Produkt 	Version
MediaWiki 	1.18.3
PHP 	        5.3.2-1ubuntu4.14 (apache2handler)
MySQL    	5.1.61-0ubuntu0.10.04.1

Is it available as an extension or must do it then the provider?

You will have to ask your web hosting provider to install it. For them, they just need to do

$ sudo apt-get install imagemagick

Okay i'll tell it him. Thank you for your support and good night. :)

Hello my provider installed today imagemagick and now does the preview function. But no preview in various sizes by clicking on is 200px, 500px, 1000px, 2000px generated and once you upload a file, are also not found in the above thumbnail images (.png) generated. What should be done to fix this, is there another command to generate said to have thumbnails? Oh and sorry for my worst english, i hope you understand it.

Above, it says you have $wgUseImageMagick set to false. I think it needs to be set to true, but look at Image thumbnailing for more info. Feel free to post back if you need more help.

Evening, i have tried two commands, the first above and "$wgImageMagickConvertCommand", but it doesn't work. I'm not sure whether or not or why ImageMagick creates thumbnails not matching, because in its folders, there are only 2 pictures, they have also not selectable dimensions.

Have you tried uploading a new svg since changing the configuration?

What version information does convert --version respond with on the command line?

Are there any errors?

If you enable debugging, does the debug log show anything?

Hello again, yes i have it tried, but i get the same error. After debug mode is on my wiki activated, he gives me following reason: http://postimage.org/image/met49iff5/ (can't copy the message and created a screenshot)

What happens if you disable the AntiBot extension?

Just tried to click on any of the different selection will be forwarded to the home page of the hoster. The thumbnails, which will be presented seem to be neither more cached generated when clicking. So it makes me at least seems.

Do new png and jpeg thumbnails work now? Otherwise, sounds like something your hoster can help with.

Have you tried updating the AntiBot extension to the latest version? Do you have an active subdirectory created under your AntiBot extension? Are there any files in it?

No, I'm probably have no way to upgrade extensions, it is the latest version, I had downloaded and installed on 24/05/2012.

In the folder there is: Folder: "available" file included -> "GenericFormEncoding.php" File outside the folder available:

AntiBot.i18n.php AntiBot.php

If you can install extensions, you can upgrade them.

On the AntiBot page, it says "copy the plugins you want into the active directory."

Try the following in the AntiBot directory:

$ cp -pr available active

I think that will get rid of the antibot error at least.

I'm not sure if I can do with what the command, but maybe because I've found something you think when you look at it this way? In the column "Permissions" so in German "Berechtigungen", the "temp" folder to another unchangeable given permission. When I had uploaded a new file (also .svg), was stored in this folder "httpdocs/wiki/images/e".

See also: http://s11.postimage.org/t8uetsexd/5k4b245jkh6b2h5j4.jpg

If you can't run commands, perhaps you can just copy or rename the folder from "available" to "active"?

If you can't do that, then just create an folder next to "available" named "active" and copy the files from "available" to "active".

Good evening, i've renamed the above folder from "available" to "active" but it seems like that it has no effect.

Do you get the same error ("Invalid argument supplied for foreach() in .../AntiBot.php on line 57")?

I would try disabling the AntiBot extension ... at least for testing. Once we verify everything else, we can figure out why the AntiBot extension is causing problems.

I have now disabled the extension Antibot and turned debugging mode on, after I updated the Wiki, the message any longer, even if the extension is not active.

Your message isn't clear: is it working now that you've disabled AntiBot?

No, but it will continue to create thumbnails, but I found in the subfolder / images/thumb/0/03/images suddenly like: 120px-XYZ-Logo.svg.png or 159px-XYZ-Logo.svg.png (examples).

So, you are getting thumbnails.

What is displayed in the file history now that AntiBot is disabled?

It sounds like your configuration may be trying to trigger something (thumbnail generation?) for 404s. What is in your .htaccess file?

In the file version of the current link to the file:

http://www.example.com/wiki/images/0/03/Example-Logo.svg

The final image (ie the first, I always put out), now contains the link:0

http://www.example.com/wiki/images/archive/0/03/20120527214439%21Example-Logo.svg

Note: there are only example links

The .htaccess file contains the following:

 
# Protect against bug 28 235
<IfModule rewrite_module>
RewriteEngine on
. RewriteCond% {QUERY_STRING} \ [? ^ \ \ /: * \ X22 <> |%] + (# | \ | $?) [Nocase]
RewriteRule. - [Forbidden]
</ IfModule>

I don't see anything that could cause this in your .htaccess file.

Using https://commons.wikimedia.org/wiki/File:Example.svg as an example, I see https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Example.svg/600px-Example.svg.png for the top example. Does this match where you see http://www.example.com/wiki/images/0/03/Example-Logo.svg ?

If so, you need to set up svg thumbnailing.

Hi Mark, I follow your suggest for set up svg thumbnailing. When i use ImageMagick, it say Error Creating Thumbnail. Then when i use rsvg it say 'Error creating thumbnail: env: python: No such file or directory' So what must i install for that problem solution? Thanks

This post by Kghbln was moved on 2013-06-06. You can find it at Thread:Talk:MediaWiki 1.19/UML extension still support?.

Hi everybody,

I'm trying to update my wiki from 1.16.2 to 1.19.6. But when the update is terminated, the login doesn't work. password check works fine because if it's false I have the error message but when I connect with the good login. I don't have a connexion. Login/create account button comes and I don't have edit button.

Has anybody an idea ?

Thanks

PS: Does mwusers forum closed ?

Check the cookies that MW is trying to send your browser. It sounds like MW isn't sending the right ones.

I think that's come of the server version (IIS5) and this bug http://support.microsoft.com/kb/q176113 but I'm not sur. I tried with Apache and it works.I will try with IIS 7.5 to confirm.

That was that. IIS5 server is too old ;-)

Thanks for your help

Hallo, ich probier's einfach mal in Deutsch: Ich habe MediaWiki in Version 1.20.0 auf einem Windows Server 2008 R2 mit IIS 7.5 installiert. PHP (5.3.13 (cgi-fcgi)) habe ich über den Web Plattform Installer (WebPI 2.0) installiert. MySQL (5.1.57-community) habe ich ebenfalls über den WebPi installiert.

Auf das images-Verzeichnis und die Unterverzeichnisse und Dateien habe ich in der Verzweiflung Vollzugriff für "Jeder" gegeben. Trotzdem erscheint die Fehlermeldung

 Fehler beim Erstellen des Vorschaubildes: Die Miniaturansicht konnte nicht am vorgesehenen Ort gespeichert werden

bei jedem Bild.

Erstaunlicherweise habe ich in einem parallelen Verzeichnis auf dem IIS ein Wiki in derselben Version, bei dem dieses Problem scheinbar nicht auftritt. Die LocalSettings.php-Dateien habe ich auch bereits verglichen. Auch da scheint es keine relevanten Unterschiede zu geben.

Hat jemand eine Idee, woran es noch liegen könnte? Danke, Alex.

Hi Alex,

hast du dir schon den Thread eins drunter angesehen? Speziell ab dieser Stelle: http://www.mediawiki.org/wiki/Thread:Talk:MediaWiki_1.19/Thumbnails_didn't_work_since_Update_to_1.19/reply_(31)

I thought this problem from 1.19 had been fixed in 1.20, but yours is the second report of this in 1.20. In the meantime, can you set $wgUploadDirectory to an existing, writable directory?

How do i update mediawiki on my wiki?

See Manual:Upgrading. Ask here (or on that talk page) for more help if you need it.

Hello, when I updated my wiki to 1.19 version, this error appear:

http://www.tibiawiki.com.br/Especial:Arquivos_novos

Someone know how do I fix this?

I just tried upgrading from MW 1.18 to MW 1.19, without a problem. Maybe this is related to the extensions you have installed?

For MediaWiki 1.18, we had a really beautiful page that had a good, easy to read, easy to scan, summary of the things in 1.18. I'm not sure we can make this page as nice as that, but I would like something a little better than what we have right now. Today, I'll be working on updating the page and I invite others to join me.

I contributed some important details to the MediaWiki 1.18 page, and I'd be happy to jump in with this one as soon as I feel competent. Thanks for making me aware of the need.

Also have a look at MediaWiki 1.19 which we'll be rolling out next week.