Usually, bugs should be reported to bugzilla, but sometimes people just need help walking through the issues. Hopefully this thread will help people diagnose these sorts of problems.
Topic on Project:Support desk/Flow
As pointed out there, this was fixed in 1.20.2
From Thread:Talk:MediaWiki 1.19/Thumbnails didn't work since Update to 1.19/reply (50), User:Carchaias asks:
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
Looking at http://blechschaden.bplaced.net/, it looks like there is a problem with an extension. Could you email me your LocalSettings.php or (if you're comfortable doing this) post it here?
It looks like the extensions you are using may not have been upgraded to versions compatible with 1.20 ... could you check those?
All the extensions are delivered with the original 1.20.2. So they should be up to date or not. What you see is the result after aplying the patch form the starting thread. Before patching it worked but without beeing able to link to files or upload files. Perhaps I will unpatch it and then you might look again.
now unpatched:
This is what a [[File:Filename.exp]] looks like without the patch and $wgShowDebug =true; :
What do your logs show? Could it be the same problem as this?
If you create a debug log, does it contain any more information?
$wgDebugLogFile = "/tmp/mw-debug.log";
This is the output within mw-debug.log when page Test is called.
Start request GET /wiki/index.php?title=Test
HTTP HEADERS:
HOST: blechschaden.bplaced.net
USER-AGENT: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
ACCEPT-LANGUAGE: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
ACCEPT-ENCODING: gzip, deflate
CONNECTION: close
REFERER: http://blechschaden.bplaced.net/wiki/index.php?title=Hauptseite
IF-MODIFIED-SINCE: Fri, 04 Jan 2013 16:30:39 GMT
CACHE-CONTROL: max-age=0
CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser]
Class LanguageDe not found; skipped loading
LocalisationCache: using store LCStore_DB
Connecting to localhost blechschaden...
Profiler::instance called without $wgProfiler['class'] set, falling back to ProfilerStub for safety
Connected to localhost blechschaden.
Fully initialised
Title::getRestrictionTypes: applicable restrictions to [[Test]] are {edit,move}
Connecting to localhost blechschaden...
IP: 62.143.238.102
Connected to localhost blechschaden.
MessageCache::load: Loading de... got from global cache
Gadget::loadStructuredList: MediaWiki:Gadgets-definition parsed, cache entry blechschaden-BS_:gadgets-definition:6 updated
Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser
Parser: using preprocessor: Preprocessor_DOM
Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct
OutputPage::checkLastModified: client sent If-Modified-Since: 2013-01-04T16:30:39Z
OutputPage::checkLastModified: effective Last-Modified: 2013-01-04T16:30:39Z
OutputPage::checkLastModified: NOT MODIFIED, page=2012-12-29T22:15:43Z, user=2013-01-04T16:34:09Z, epoch=2013-01-04T16:30:39Z
OutputPage::sendCacheControl: private caching; Fri, 04 Jan 2013 16:30:39 GMT **
wfClientAcceptsGzip: client accepts gzip.
wfGzipHandler() is compressing output
Article::view: done 304
Request ended normally
I don't know if this could be a problem with filesystem permissions.
1. The file itself was uploaded and mw was able to create the folders and the file itself on the server. When you look at http://blechschaden.bplaced.net/wiki/images/e/e0/Info48.png you can see: The file is there.
2. The /images/tmp and /images/thumb folder are not created. I created them and chmoded to 755 by ftp but that did not change anything so I deleted again.
3. Another Wiki on V 1.18 works without any problems on the same hoster.
Update: I don't know what happend, but now I'm not able to upload any longer. There ist a message at the top of the page
wfMkdirParents: failed to mkdir "/wiki/images/7/71" mode 0777 in <b>/users/blechschaden/www/wiki/includes/GlobalFunctions.php
Maybe you need to fix the permissions on your images directory. Also, adding a temp directory might help:
mkdir wiki/images/temp chmod 0777 wiki/images wiki/images/temp
You'll also need to add the following line to LocalSettings.php:
$wgTmpDirectory = "$IP/images/temp";
I would like to thank you very much. Your last hint was the key. This is what the section in LocalSettings.php now looks like:
## To enable image uploads, make sure the 'images' directory ## is writable, then set this to true: $wgEnableUploads = true; $wgUploadDirectory = "$IP/images"; $wgUploadPath = "$wgScriptPath/images"; $wgTmpDirectory = "$IP/images/temp";
I used the commands mkdir and chmod via ftp from command line. Example
ralfhagenbuck@ubuntu:~$ ftp ftp> open (to) blechschaden.bplaced.net Connected to server2.bplaced.net. 220 Welcome to bplaced, FTP server standing by ... Name (blechschaden.bplaced.net:ralfhagenbuck): blechschaden 331 Hello blechschaden, your FTP account password is required: Password: 230-Login successful, your current directory is / 230 69792 Kbytes used (3%) - authorized: 2097152 Kb Remote system type is UNIX. Using binary mode to transfer files. ftp> cd wiki 250 OK. Current directory is /wiki ftp> chmod 0755 images images/temp 200 Permissions changed on images
(This would not work using a Windows based computer cause chmod is no command there.)
Some Questions remain:
1. I never had to set $wgTmpDirectory before. Is that new? Shouldn't this the be done by the mw-config script at setup?
2. $wgUploadDirectory and $wgUploadPath have not been set by mw-config script. This is the standard configuration so they shouldn't be needed (and they are not in my 1.18 Wiki).
3. Why does $wgUploadDirectory use the $IP and $wgUploadPath use the $wgScriptPath variable. I used $wgScriptPath for both but thats not working.
4. In my other Wiki all /images and subfolders are 0755. Why now 0777? 0755 does it the same way in my case.
(This would not work using a Windows based computer cause chmod is no command there.)
True, but you could still ftp from a Windows computer. If your wiki is hosted on a *nix system (most are) then it will work.
I never had to set $wgTmpDirectory before. Is that new? Shouldn't this the be done by the mw-config script at setup?
Good point. Tracked here: https://bugzilla.wikimedia.org/show_bug.cgi?id=43644
$wgUploadDirectory and $wgUploadPath have not been set by mw-config script. This is the standard configuration so they shouldn't be needed (and they are not in my 1.18 Wiki).
Are they needed? What happens if you don't set them? The documentation for $wgUploadPath and $wgUploadDirectory makes it look like they don't need to be set unless you want to have some sort of special control over them.
Why does $wgUploadDirectory use the $IP and $wgUploadPath use the $wgScriptPath variable. I used $wgScriptPath for both but thats not working.
The documentation (linked above) explains what is going on. $wgUploadDirectory is pointing to the location on disk. $wgUploadPath provides the path portion of the url. $wgScriptPath doesn't point to an actual directory on disk, but $IP does.
In my other Wiki all /images and subfolders are 0755. Why now 0777? 0755 does it the same way in my case
Who owns the directory on your other Wiki? 0755 means that anyone can see the files but only the owner of that directory can write files. The 0777 permissions make it so that anyone can write the files there.
The Windows FTP Commandline does not have chmod. Perhaps it works with filezilla or thelike.
$wgUploadDirectory and $wgUploadPath are needed in my 1.20.2 installation but not in 1.18. Here the same section looks like this and works fine with 1.18 :
## To enable image uploads, make sure the 'images' directory ## is writable, then set this to true: $wgEnableUploads = true;
This is what the 1.20.2 /mw-config/index.php created also and it didn't work. Perhaps its a lag in the script.
The owner within the whole /wiki is always 33 or 330 - that varies. It is something that is set by the hoster i think. It is the same for both wikis.
- The Windows FTP Commandline does not have chmod. Perhaps it works with filezilla or thelike.
It is awkward, but you can do it in the bundled ftp client for windows. I just tried this by ftp'ing from my windows VM to my linux box. The command is
quote site chmod 777 FILE
- $wgUploadDirectory and $wgUploadPath are needed in my 1.20.2 installation
Your site is working now, right? What happens if you remove those two settings now? Does it keep working?
No, it does not work without this two parameters.
I have the same issue but nothing works (putting the two settings and chmod to 777). 1.20.2 here also (not fresh).
Could you start a new thread describing your problem in detail?
Just for infomation: I had a simular problem and solved it by creating an folder named tmp (not temp) in images/.