Project:Support desk

Jump to: navigation, search

About this board

vde   Welcome to's Support desk, where you can ask MediaWiki questions!

There are also other places where to askCommunication: IRCCommunication#Chat, mailing listsMailing lists, Q&A etc.

Before you post

Post a new question

  1. To help us answer your questions, please always indicate which versions you are using (reported by your wiki's Special:Version page):
    • MediaWiki
    • PHP
    • Database
  2. Please include the URL of your wiki unless you absolutely can't. It's often a lot easier for us to identify the source of the problem if we can look for ourselves.
  3. To start a new thread, click "Start a new topic".
By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
Reception123 (talkcontribs)

Hello, I would like to know how I could program the local time zone to show up for instead of UTC. For example if my timezone is set as GMT -10 the Special:RequestWiki page should show the GMT - 10 time not the UTC.

Reception123 (talkcontribs)

@Ciencia Al Poder Any idea about this?

Ciencia Al Poder (talkcontribs)

No idea, although you should clarify who is 'my timezone'? server or client

Reception123 (talkcontribs)

Client's timezone

Ciencia Al Poder (talkcontribs)

The server has no idea about the client's timezone, that's not information that's sent in the request headers, so it will require JavaScript on the client to grab the timezone, and probably make an ajax call to the server to re-send the entire contents again in the correct timezone, or reparse all dates on the page with JavaScript (scary at best)

Reception123 (talkcontribs)

Hmm. Thanks for the response.

Reception123 (talkcontribs)

@Ciencia Al Poder Thinking about it, wouldn't it be possible if the clients timezone is set in Special:Preferences?

Ciencia Al Poder (talkcontribs)

Yes, you can use the same methods Special:RecentChanges and page histories use to format dates and times

Reception123 (talkcontribs)

@Ciencia Al Poder I'm not exactly sure how I would integrate that into an extension.

Ciencia Al Poder (talkcontribs)

You should probably hire a developer if you are not able to copy&paste what other parts of the code are already doing. I'm just a volunteer not actively working on MediaWiki code.

Reception123 (talkcontribs)

@Ciencia Al Poder Sorry for asking so much. If it's not to much bother could you at least point me to a similar extension that uses this type of code?

Ciencia Al Poder (talkcontribs)

It's done in MediaWiki core, you can see Special:Log, Special:RecentChanges, Special:Contributions and page histories. It shouldn't be hard to see how the dates are transformed to the user timezone set in preferences...

Reply to "Program local timezone for extension"

Error creating thumbnail: Unable to save thumbnail to destination

Star Warden (talkcontribs)

Hey. I keep getting this error button and I don't know how to fix it. It can be seen here:, here: and here:

I've tried setting a temp folder ($wgTmpDirectory = "$IP/images/temp";) and a debug file ($wgDebugLogFile = "/var/log/mediawiki/debug-{$wgDBname}.log";) as suggested and even made the temp folder writable by the server using chown, but that did not work.

The manual on how to debug specifies that this log can contain sensibile information, thus I won't post all of its contents and would like to know what could I share here from it that would help in solving this issue?

I mention the console is displaying some weird errors, but I cannot interpret them, sadly.

MarkAHershberger (talkcontribs)

Looking at your Special:NewFiles, it looks like you are able to upload images without problem, but those particular images cause a problem.

I can use thumb.php to create thumbnails of various sizes (see also).

thumb.php appears to work on images that show the problem.

Meanwhile, fails to produce thumb.php some thumbnails for the problematic images.

Maybe you can see what is produced in the debug log when one of the failing thumb.php links is called?

Star Warden (talkcontribs)

I found no recent instance of the cupcake thumb (at least the date isn't displayed when such calls are made, so it might be recent), thus I also included something more recent. The cupcake thumb is at the very top, the others are separated by a large space: Hope it helps!

MarkAHershberger (talkcontribs)

I'm at a loss. I don't really know how to help you without access to your machine. Sorry. Perhaps you can check the permissions on all the directories in your images folder to see if one or two has funky permissions.

Ciencia Al Poder (talkcontribs)

What if you set $wgShowExceptionDetails to true temporarily and open the problematic thumb.php URL?

Star Warden (talkcontribs)

That string was already set to true even before the problem occurred. But here's the strange thing. If you go and check my first two links (ruins and habitats), you'll see that the problem was solved on its own...

Here's a screenshot of the permissions that all folders seem to have: I selected all of them, and made sure they are all set to that. Do I need to change anything?

I forgot to mention that when renaming the file, the issue seems to disappear (of course, there's a reason I named them the way I did, in the first place, thus this isn't a good solution or the solution for that matter). And, in some cases, the issue is triggered only if I get over a certain pixel size while adding it to the article. Would manually moving the images (on the server) from one folder to another solve it? Is it even safe to do that?

MarkAHershberger (talkcontribs)

The permissions look fine if that user is the user that runs as the web server. You could also change the permissions on images to the numeric code 777 and recurse through the images directory.

You could move the images directory, but you would need to change a few configuration options like Manual:$wgUploadPath or Manual:$wgUploadPath. You might also need to use Manual:Img auth.php to stream images.

Star Warden (talkcontribs)

I am not sure if that user is the one that runs as the web server.. I was using the root account. How do I find out who it is?

Also, the second option you gave me is the same as the first one. I was asking if I could only move the images that cause trouble, not the whole directory. Seems kinda pointless to move the whole thing just for a few troublemakers.

MarkAHershberger (talkcontribs)
  • I don't recognize the tool you are using for ftp. But what does the full listing of the mediawiki directory show? Maybe that would have user names on it.
  • If you can physically remove the primary uploaded problematic file, then I think you could re-upload it. That might solve the problem.
Star Warden (talkcontribs)
  • I use FileZilla Client. I am not sure what you're referring to. Is this it: ?
  • By physically removing it, you mean to manually delete it from the server itself or from the wiki? Because if it's the latter, it doesn't work.
MarkAHershberger (talkcontribs)
  • That has the information I wanted. It looks like you're on a Debian server and the permissions are set correctly.
  • I meant from the server itself.
  • Could you use FileZilla to get the listing of the images/thumb/9/90 and images/thumb/9/90/The_Winds_of_November_Event_%2816.11.14%29.jpg directory?
Star Warden (talkcontribs)

I managed to get there and the folder has the image in 3 different sizes: 200px, 300px and 400px. Interestingly enough, this folder seems to have another owner than the typical one: I checked other problematic files, thinking the owner might be at fault, but they had the typical owner, so I guess the different owner theory can (for now, at least) be ruled out.

Should I delete the image from both its permanent place and the thumb folder?

MarkAHershberger (talkcontribs)

The root owner is definitely going to cause a problem. Delete that directory and its contents.

Star Warden (talkcontribs)

That solved the thumbnail problem, but only for that image.

Star Warden (talkcontribs)

Ehm, I was thinking of something. Sometimes, some special pages (usually uncategorised files) won't update, no matter what, regardless if I run updateSpecialPages.php (which runs daily on a cron job) no matter what. So I force it with refreshLinks.php which, in turn, creates a ton of jobs which are run by runJobs.php later on. From time to time, some jobs just get stuck, not allowing themselves to be run. I posted about it 2 months ago ( but got no response. So I looked into the database and found the stuck jobs in the job table. So I just manually deleted them (and have been doing that ever since). Could this be the problem behind it or is it unrelated? I remember this particular issue happened on the 1.26.2 installation, then a failed server upgrade brought the wiki down for a little while, we moved servers and that issue was fixed (this was last summer).

MarkAHershberger (talkcontribs)

It could be related.

You need to make sure that runJobs.php and refreshLinks.php are running as the www-data user and not the root user.

Star Warden (talkcontribs)

I am sorry, I am not good at this. How do I do that? I haven't used any other user besides my personal one and the root one.

MarkAHershberger (talkcontribs)

How do you normally get the jobs to run? How are they being run right now?

Star Warden (talkcontribs)

With cron. When I set it up, I opened putty, logged in on root, entered the command: crontab -e then I added this string: */120 * * * * cd (path to wiki) && php maintenance/runJobs.php and saved. But after using refreshLinks, I run it manually. It usually doubles the number of jobs, initially, then starts to decrease them.

MarkAHershberger (talkcontribs)

If the only cron jobs you have are those that are running for the wiki, then run this sequence of commands as root:

# crontab -l > cron.txt         # to save the current crontab
# crontab -r                    # to delete the current crontab for root
# crontab -u www-data cron.txt  # to give the crontab entries to the www-data user.

If you have other crontab entries, skip the second step (which removes all the entries for root) and edit cron.txt so that only wiki maintenance scripts are left in the file before running the third command.

In any case, the first command will back up all your root cron commands if there is a mistake made.

Star Warden (talkcontribs)

Before proceeding, I used grep CRON /var/log/syslog to see the other jobs. There are 3 other that are not in my current crontab (when using crontab -e), but they all are run by root. Two seem to be more server-related:

Is it safe to still do all the steps?

Also, I did the first step, but I got no confirmation of whether the procedure was successful or not? How do I check?

Star Warden (talkcontribs)

Ah, also, deleting images from the server then re-uploading them doesn't get rid of the error (because it uploads them to the same place in which they were before), BUT, I think it might just be related to root being the owner. So far, all images that I checked in images/thumb that had the issue, had root as the owner. It seems this issue occurs only with thumbnails.

MarkAHershberger (talkcontribs)

You can see if the first step worked by looking for cron.txt in the directory where you ran the file.

In fact, since you have other cron jobs running as root, skip the second step and just edit the cron.txt file to have the wiki-related jobs.

After that, erase those jobs from the root crontab using crontab -e and then run the third command to move the cronjobs to the www-data user.

Star Warden (talkcontribs)

I am not exactly sure what I am doing wrong. Technically, I run the command in the base directory (that is, I didn't change the folder after opening putty), but there is no such file there. Then I looked in /var/spool/cron/crontabs, which has the crontab that I can access through the crontab -e and crontab -l commands, but that's the only file in there (googling also lead me to the same location). There's also another crontab in /etc which lists all the cronjobs. But no sign of cron.txt in any of those three spots....

MarkAHershberger (talkcontribs)

If you run "crontab -u root -l > cron.txt" as root, it should create the cron.txt file for you.

Star Warden (talkcontribs)

I did that, still wasn't in any of those three locations, but I used find / -name and found it in /root. Inside it, there are the two jobs: runJobs.php and updateSpecialPages.php and the default "# Edit this file to introduce tasks to be run by cron". Is this the right file?

MarkAHershberger (talkcontribs)

That is it. It makes sense that it is in /root since that is the root user's home directory. Probably typing ls after running the command would have shown it.

Star Warden (talkcontribs)

Awesome. So let me get this straight before doing anything. I need to edit that file to have the wiki-related jobs going. It already has two jobs (updateSpecialPages and runJobs). This means I need to add the other three remaining jobs from /etc/crontab?

These are:
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

MarkAHershberger (talkcontribs)

Just the first one. And "root" should not be there. You should probably paste your cron.txt before running the command to load it.

Star Warden (talkcontribs)

Is this correct: What do I do with the last 3 cronjobs and with the other two crontabs (from /var/spool and /etc)?

EDIT: There was another job that I missed which was added as custom, apparently:

*/15 * * * *	root	cd /(path to wiki)/ && /usr/bin/php maintenance/rebuildFileCache.php >> /var/log/(log folder)/rebuildFileCache.log 2>&1
5 2 * * *     root    cd /(path to wiki)/ && /usr/bin/php maintenance/runJobs.php >> /var/log/(log folder)/runJobs.log 2>&1

It seems there is a second runJobs which is a tad bit different than the first runJobs. Doesn't really seem to be doing its job properly, though. Should I just remove it?

MarkAHershberger (talkcontribs)

First, do not run crontab -r. Use crontab -e to edit the root crontab files and remove only the wiki crontab entries. The rest should remain.

You should have a file, cron.txt, with the following based on the information you've given here:

*/15 * * * * www-data  cd (path to wiki) && php maintenance/rebuildFileCache.php   >> (log folder)/rebuildFileCache.log 2>&1
*/15 * * * * www-data  cd (path to wiki) && php maintenance/runJobs.php            >> (log folder)/runJobs.log 2>&1
0    0 * * * www-data  cd (path to wiki) && php maintenance/updateSpecialPages.php >> (log folder)/updateSpecialPages.log 2>&1

Move the cron.txt file to /etc/cron.d/wiki-cron-jobs.

This will allow Ubuntu's cron system to run them. Anytime you need to change them, you can safely edit that file.

I think this will get you where you need to be. Sorry for the confusion.

MarkAHershberger (talkcontribs)

And to reduce the repetition, you can use shell variables in that file, so you could do the following:

LOGDIR=/var/log/(log folder)
WIKIDIR=(path to wiki)

*/15 * * * * www-data  cd $WIKIDIR && php maintenance/rebuildFileCache.php   >> $LOGDIR/rebuildFileCache.log 2>&1
*/15 * * * * www-data  cd $WIKIDIR && php maintenance/runJobs.php            >> $LOGDIR/runJobs.log 2>&1
0    0 * * * www-data  cd $WIKIDIR && php maintenance/updateSpecialPages.php >> $LOGDIR/updateSpecialPages.log 2>&1
Star Warden (talkcontribs)

I did that and moved the .txt to where you suggested (I had to manually create the wiki-cron-jobs folder). Here's the entire paste:

Now, one question. What do I do with the remaining cronjobs that I wrote here ( They weren't in the crontab file that I could open with crontab -e while logged in on root. They are in the crontab that's found in /etc. This is its contents:

MarkAHershberger (talkcontribs)

I'm sorry, I should have been clearer. I wanted you to move cron.txt to a file called /etc/cron.d/wiki-cron-jobs. If you've created a directory, I'm not sure it will work.

Remove these lines from the file you found under /etc:

*/15 * * * *    root    cd /(wiki path) && /usr/bin/php maintenance/rebuildFileCache.php >> /var/log/wiki_logs/rebuildFileCache.log 2>&1
5 2 * * *     root    cd /(wiki path) && /usr/bin/php maintenance/runJobs.php >> /var/log/wiki_logs/runJobs.log 2>&1

The others should be left as-is.

Star Warden (talkcontribs)

Well, there was no such file there. Cron.txt currently rests in /etc/cron.d/wiki-cron-jobs folder. I used grep CRON /var/log/syslog to see the recent jobs, but not jobs from cron.txt seem to have been executed... what should I do?

MarkAHershberger (talkcontribs)

Run the following commands:

$ mv /etc/cron.d/wiki-cron-jobs/cron.txt /etc/cron.d/wiki-jobs
$ rmdir /etc/cron.d/wiki-cron-jobs

Both should run without problem and you should see cron jobs executing shortly after that.

Star Warden (talkcontribs)

Hey. Thanks! But there seems to be a problem... the jobs aren't run. Using grep CRON /var/log/syslog it does show me the runJobs.php has been executed, but the number does not go down, unless I manually run it. What might be the cause?

Star Warden (talkcontribs)

Actually, it seems none of the maintenance scripts are working, not only php runJobs.php.

MarkAHershberger (talkcontribs)

Could you run the following and tell me the output:

$ grep wiki-jobs /var/log/syslog
Star Warden (talkcontribs)

This is what I get:

Reply to "Error creating thumbnail: Unable to save thumbnail to destination"
Steings (talkcontribs)

I am moving a site to a new server and upgrading MediaWiki from 1.20 to 1.27 (BlueSpice 1.20 to 2.27). PHP is 5.6.23 and MySQL is 5.6. On the old site, there are many "[[File:lowercase.gif]]" in the wiki text that work even though the image is saved as Lowercase.gif; on the new site, it considers them bad Image links and there is just a display of link text which is a link to a page to upload the missing image. I can't find anything in the code that explains this difference. I don't want to have to search through all the pages for lowercase image names to change. (The application is internal, so I can't provide a link.)

MarkAHershberger (talkcontribs)

Did you change anything in your LocalSettings.php? Did you create a new LocalSettings.php?

What is $wgCapitalLinks set to?

Steings (talkcontribs)

$wgCapitalLinks does not appear in LocalSettings.php. The file is generally the same except a few require_once are changed to wfLoadExtension. We did drop the Accesslog and Realnames extensions. We had to change Auth_remoteuser to AuthRemoteuser. Finally, there were many changes with BlueSpice, but I think it's roughly the same.

MarkAHershberger (talkcontribs)

You could also try

$wgCapitalLinkOverrides[ NS_FILE ] = true;
Osnard (talkcontribs)

Mark is right. Please set the $wgCapitalLinkOverrides for NS_FILE in you LocalSettings.php. We've had a bunch of default settings in the BlueSpiceFoundation ( that we always apply to our customers installations. Unfortunately this introduced some issues with the community users. So we've removed the settings in the upcoming release and have it now in a separate config file that we deploy to our customers. You can also modify the BlueSpiceFoundation/includes/DefaultSettings.php directly as it will change with the next release anyways.

If setting $wgCapitalLinkOverrides in LocalSettings.php does not work directly, try to set it within a $wgExtensionFunctions callback. E.G.

$wgExtensionFunctions[] = function() { $GLOBALS['wgCapitalLinkOverrides'][ NS_FILE ] = true; };
Steings (talkcontribs)

Thank you. Osnard's suggestion has solved my problem.

Reply to "Lowercase image names not working"

Error "there seems to be a problem with login" on nas

Liannnnn (talkcontribs)


I have a Synology DS116 and I installed MariaDB 5.5.53-0070, PHP 5.6.28-0050 and MediaWiki 1.27.1-0117 on it. When logging in to the wiki, MediaWiki returns an error message.

Occurance: When logging in to wiki (ip address/MediaWiki/index.php)

Error message: "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again"

Browser: Chrome (also tried in cognito) and IE

Sources on the internet say it could have to do with cache-type (changing $wgMainCacheType = CACHE_ACCEL; into ANYTHING or DB) or cache save location (adding session_save_path("tmp");), but this didn't help me.

Thanks in advance!

Lian (talkcontribs)

I've got the same problem. (talkcontribs)

Try changing $wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING.

It worked for me.

Reply to "Error "there seems to be a problem with login" on nas"
Reception123 (talkcontribs)

At Miraheze (wiki farm) we have extension and it uses a system where a user makes a request, the requests get submitted and added to a queue for it to be accepted. I would like to know how I could integrate a sort of TitleBlacklist inside of to be able to blacklist keywords so that the request doesn't get submitted if the keywords are present. Does anyone know how this would be possible?

MarkAHershberger (talkcontribs)

Maybe call abortNewAccount() or testUserName()?

Reply to "Blacklist keywords for extension"
Asdaricus (talkcontribs)

I asked a while back how to have a custom font in my wiki. I was told that I need to edit the CCS. I am using the 'vector' style. I was not able to find the css for it. How does that work. Thank you.

MarkAHershberger (talkcontribs)

You can make the change in your wiki's [[MediaWiki:Common.css]] page.

Asdaricus (talkcontribs)

Thanks for your reply. What's the expected path? I don't see a common.css file or a vector.css in my wiki? Is it a file I have to create to override the default?

Ciencia Al Poder (talkcontribs)

See Manual:Interface/Stylesheets for expected location, but basically it's a page you need to create on your wiki

Reply to "How to edit CSS for customized font" (talkcontribs)

WikiMedia USA have UNLAWFULLY DEBITED MY VISA CARD!! Thanks a lot for all the hassle you are causing me. The Bank are investigating. I have also passed this incident on to our Australian Police Dept for further investigation.

Ciencia Al Poder (talkcontribs)

You should ask WikiMedia Foundation about this, not MediaWiki (talkcontribs)

I am not even sure that something called "WikiMedia USA" actually exists. At least I have never heard of that name. Maybe this even does not have anything to do with the Wikimedia Foundation? Should this be the case, I think that WMF also would be interested in this issue.

Reply to "FRAUD BY YOU"
Hansie (talkcontribs)

Dear Member,

Some time ago I got user registration problems most probably because of port problems of the hosting company :Topic:Szjv1s9juor2waas

Does a "MediaWiki-friendly" hosting company exists with which I don't have such problems?

Best Regards.


Malyacko (talkcontribs)

Hosting services

Reply to ""MediaWiki-friendly" hosting"

How to ?- Insert table in NUMBERED LIST .

Aum1 (talkcontribs)


   Unable to create a numbered list(CONTINUNG) when adding a table in one of the steps.
   Unable to figure the line break that compels a new numbered list to start.
       How do I fix this?


  1. Instruction 1
  2. Instruction 2
  3. Instruction 3
    1. Sub-list
      1. sub-list
    2. Sub-list
  4. Instruction 4
    • category 2
  5. Instruction 5
Example Example Example
  1. Instruction 6 - I am trying to make this list item continue from the list above. i.e 6 instead of starting a new list at 1 again.

Ada.Grobbelaar (talkcontribs)

I have the same problem

Aum1 (talkcontribs)

I figured one solution. Adding ComplexList extension <cl></cl> tag. This can be found at Extension:ComplexList

It works perfectly fine. It's pretty cool and simple- it lets you define your list with much ease(alpha, roman, numeric, etc) (talkcontribs)

I figured out the easiest way might be hard-code the html code by using <ol>...</ol> and <li>...</li>. I know it is dirty but it works if you do not want to install additional extension.

  1. category 2
  2. Instruction 5
    Example Example Example
  3. Instruction 6 - I am trying to make this list item continue from the list above. i.e 6 instead of starting a new list at 1 again. (talkcontribs)

As user from IP suggests, you have to use some HTML. another way is to use HTML to define your table - as long as you don't use line breaks. and getting lines as separators might be difficult too.

  1. Instruction 1
  2. Instruction 2
    Example Example Example
  3. Instruction 3 - this list item continues from the list above.
2001:4898:80E8:F:0:0:0:4F5 (talkcontribs)

I know this is an old thread. Seeing as how this page is locked down and We can not see the actual wiki formatting could someone post the actual Wiki code used in the above example please?

Ciencia Al Poder (talkcontribs)

Example 1 Using HTML for the list:

<li> category 2</li>
<li> Instruction 5<br>
{| class="wikitable"
| Example || Example || Example
<li> '''Instruction 6 - I am trying to make this list item continue from the list above. i.e 6 instead of starting a new list at 1 again.'''</li>

Example 2 using HTML for the table:

# Instruction 1
# Instruction 2 <table style="border: 1px solid black;"><tr><td>Example  </td><td>Example  </td><td>Example </td></tr></table>
# '''Instruction 3 - this list item continues from the list above. '''
Reply to "How to ?- Insert table in NUMBERED LIST ."

Unable to display file in Mediawiki

Adba.swht (talkcontribs)

Hello everybody who wants to help me asap.

I got a problem with displaying uploaded files (I am using Mediawiki). I know where the problem is but I don't know how to fix it.

Problem: Mediawiki stores uploaded files to the root insted of using a dedicated folder for some reason.

Well, I noticed that I am able to upload files properly but to the wrong location - all uploaded files are stored in root (C:\e, C:\n etc.) and I do not know why. However, I obviously need them in C:\inetpub\wwwroot\mediawiki\images where the mediawiki is taking them from and where the .htaccess file is located.

Uploaded files normally appear in Mediawiki, however without thumbnails, and when I want to show/display the full file (picture) this page appears:

HTTP Error 404.0 - Not Found

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

Detailed Error Information

Module IIS Web Core
Notification MapRequestHandler
Handler StaticFile
Error Code 0x80070002
Requested URL http://intranet:82/6/60/Something.jpg
Physical Path C:\inetpub\wwwroot\mediawiki\6\60\Something.jpg
Logon Method Anonymous
Logon User Anonymous

** I tried to copy all folders with files from root to the default location but it isn't working.

** I am using IIS7 on Windows Server 2008

** I have the upload function enabled. I changed this after installation: $wgScriptPath = "/mediawiki"; to $wgScriptPath = "";

Ciencia Al Poder (talkcontribs)

You may need to set Manual:$wgUploadDirectory, in case MediaWiki is unable to figure it properly, as seems to be the case.

Adba.swht (talkcontribs)

I've already had it configured like this:

$wgUploadDirectory = "$IP/images";

Ciencia Al Poder (talkcontribs)

Oh, right, the problem should be $wgUploadPath then (the URL MediaWiki think the files are accessible from the web). It should be right already, except if you have weird things in $wgScriptPath.

Adba.swht (talkcontribs)

Well, maybe i confused you a little but the "code" below was the first thing I add to LocalSettings.php:

$wgUploadDirectory = "$IP/images";

$wgUploadPath = "$wgScriptPath/images";

BUT I had a problem with uploading from the beginning so I add this (and it solved uploading issue - I can upload now, but they are not able to display properly) Maybe there is some problem but I cannot see it:

$wgFileBackends[] = array(

        'name'        => 'local-backend',

        'class'       => 'FSFileBackend',

        'lockManager' => 'nullLockManager',

        'containerPaths' => array(

                'local-public'  => "{$wgUploadDirectory}",

                'local-thumb'   => "{$wgUploadDirectory}/thumb",

                'local-transcoded' => "{$wgUploadDirectory}/transcoded",

                'local-deleted' => $wgDeletedDirectory,

                'local-temp'    => "{$wgUploadDirectory}/temp",


        'fileMode'    => 0644,


// Define a standard file repository that uses the local backend defined before

$wgLocalFileRepo = array (

        'class'             => 'LocalRepo',

        'name'              => 'local',

        'directory'         => $wgUploadDirectory,

        'scriptDirUrl'      => $wgScriptPath,

        'scriptExtension'   => $wgScriptExtension,

        'url'               => $wgUploadBaseUrl ? $wgUploadBaseUrl . $wgUploadPath : $wgUploadPath,

        'hashLevels'        => $wgHashedUploadDirectory ? 2 : 0,

        'thumbScriptUrl'    => $wgThumbnailScriptPath,

        'transformVia404'   => !$wgGenerateThumbnailOnParse,

        'deletedDir'        => $wgDeletedDirectory,

        'deletedHashLevels' => $wgHashedUploadDirectory ? 3 : 0,

        'backend'           => 'local-backend',


Adba.swht (talkcontribs)

And now MSUpload says: Unknown error: "directorycreateerror"

What the hell is going on?

I have the same configuration on my test wiki and works fine.

Only one difference is that my test wiki runs on XAMPP and my non-test wiki runs on IIS. So what is the problem?

Ciencia Al Poder (talkcontribs)

You should probably comment out the definition of $wgFileBackends and $wgLocalFileRepo. I suggested that long time ago because people were getting errors about unable to get lock for uploading files, but that was never the correct way to solve that, because all problems were because of permissions, either filesystem permissions, SELinux problem, or other misconfigurations like temp directories not writable.

Adba.swht (talkcontribs)

I removed it and it works fine now. Thank you.

But I am still a little confused because it didn't work yesterday with the came configuration and now it's OK.