Project:Support desk

Welcome to the MediaWiki Support desk, where you can ask MediaWiki questions!

(Read this message in a different language)

See also

• Other places to ask for help

Before you post

• Check the basic How does MediaWiki work? guide.
• Check the FAQ and Errors and symptoms .
• If your question is about a specific feature, check the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• For issues about the mediawiki.org website, report to Village Pump instead.
• For trying out wiki editing, use the Sandbox instead.

Post a new question

1. To help us answer your questions, please indicate which versions you are using, as found on your wiki's Special:Version page:
   • MediaWiki version
   • PHP version
   • Database type and version
2. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
3. To start a new thread, click "Start a new topic".

Hi, on my wiki, I'd like to deactivate the functionality to Preview a page before saving it (mainly because it causes some issues on my wiki - loss of data - and I don't use it enough to fix them). I could hide the button Preview, but is there a proper way ? Thanks

In some language sections of our wiki, we get this error when opening any citation page:

[e151029d61b06caf6d0daf1f] /wiki/Module:Citation LogicException: This ParserOutput contains no text!

Backtrace:

from /var/www/prolewiki/includes/parser/ParserOutput.php(382)

# 0 /var/www/prolewiki/extensions/Scribunto/includes/ScribuntoContentHandler.php(224): ParserOutput->getRawText()
# 1 /var/www/prolewiki/extensions/Scribunto/includes/ScribuntoContentHandler.php(193): MediaWiki\Extension\Scribunto\ScribuntoContentHandler->highlight()
# 2 /var/www/prolewiki/includes/content/ContentHandler.php(1759): MediaWiki\Extension\Scribunto\ScribuntoContentHandler->fillParserOutput()
# 3 /var/www/prolewiki/includes/content/Renderer/ContentRenderer.php(47): ContentHandler->getParserOutput()
# 4 /var/www/prolewiki/includes/Revision/RenderedRevision.php(259): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()
# 5 /var/www/prolewiki/includes/Revision/RenderedRevision.php(232): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached()
# 6 /var/www/prolewiki/includes/Revision/RevisionRenderer.php(223): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
# 7 /var/www/prolewiki/includes/Revision/RevisionRenderer.php(164): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
# 8 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()

...

The citations themselves work, and they can still be edited in source code, but they do not render any page in only two wikis.

e.g.: https://en.prolewiki.org/wiki/Module:Citation

e.g.: https://pt.prolewiki.org/wiki/Módulo:Referência

But on other languages, we don't see that error

e.g.: https://es.prolewiki.org/wiki/Módulo:Citación_web

e.g.: https://zh.prolewiki.org/wiki/Module:String

My initial suspicions is that it's a database problem? Because the English and Portuguese wikis were the first ones created, in a older version of MediaWiki, and they are the ones giving trouble. How can I further investigate this?

Windows 11 Home with XAMPP 3.3.0 and MediaWiki 1.41

With the web browser command localhost/hanekudai I can access my local site but I only get the front page with no CSS and any internal link leads to a 404 "Not found" page.

Here is my full LocalSettings.php:

<?php

# URL settings
    $wgSitename = "hanekudai";
    $wgServer = "http://hanekudai";
    $wgArticlePath = '/wiki/$1';

## Database settings
    $wgDBtype = "mysql";
    $wgDBserver = "localhost";
    $wgDBname = "OMITTED";
    $wgDBuser = "OMITTED";
    $wgDBpassword = "OMITTED";
    $wgDBprefix = "";
    $wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

# Language settings
    $wgShellLocale = "C.UTF-8";
    $wgLanguageCode = "he";

# Extension settings
    wfLoadExtension( 'Cite' );
    wfLoadExtension( 'ParserFunctions' );

# Skin settings
    wfLoadSkin( 'Vector' );
    $wgDefaultSkin = "vector-2022";

I didn't find a general log file in the rather complex file tree of MediaWiki.

What have I done wrong?

This is the URL of my frontpage:

http://localhost/hanekudai/index.php?title=Hanekudai

Please allow anonymous users to edit posts here for at least 1 hour to 12 hours after posting.

This can be done without much problem based on IP address AND a web browser cookie (and the time limit of up to twelve hours would really seal the deal I guess).

Although not speaking English (or any other Germanic language) as a first language I control it quite good but still more prone to error in it and I currently I also suffer from a psychiatric condition and tend to confuse and have typos or phrasing mistakes more often; I should get better soon but it will take a two months or so probably.

I control HTML, Wiki, and Markdown quite good for years now and usually very pedantic about them but had a thread here with two mistakes (yes @TheDJ two mistakes instead of just one are also possible even for an experienced user) and it is great of a trouble for me that I can't edit posts in my last thread in which I confused twice and had several phrasing mistakes.

Please, for accessibility's sake, allow anonymous users to edit their posts at last for some small time.

@Malyacko

@Bawolff

@Jonathan3

No. We aren't going to change this.

If you want to be able to edit previous posts, create an account.

No, thanks.

Our site has been moved to a new server for 1 day: https://sheki.org/wiki/index.php

The /.cagefs/tmp/ folder keeps creating merge files like 'merge-your-xYOkiL', 'merge-old-LUv354' etc. in their names. 3-6 times per minute. Each of these consists of the HTML code of one page of the site (5-6 pages in total, mostly large pages). I want to know, what is it for? Should it be avoided?

Thanks in advance.

Hi,

This is used during edit conflicts (when two people edit the same page at the same time) to try and automatically resolve the conflict.

There is no harm in these files, and they should be deleted automatically after the edit.

It is possible to disable by setting $wgDiff3 but i dont reccomend as that will significantly increase the frequency of edit conflict pages.

Hello,

I got this error : : failed to mkdir "/path/to/examplecom/sitemap/" mode 0777 [Called from wfMkdirParents in /home/wikicilo/public_html/wiki/includes/GlobalFunctions.php at line 1478] in /home/wikicilo/public_html/wiki/includes/debug/MWDebug.php on line 508

Can not create directory /path/to/examplecom/sitemap/

While I was trying generate the sitemap.

Is there anyone to help me please?

Try using sudo to run the script as the same user as the web server runs as (e.g sudo -u www-data )

Hello,

I am getting the "Could not open lock file for "mwstore://local-backend/local-public/image.jpg". Make sure your upload directory is configured correctly and your web server has permission to write to that directory. See https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgUploadDirectory for more information." error when uploading files to a MW page.

This page is hosted on RHEL and was updated by a previous sys admin in my organization, and the upload feature has been broken since he last updated MW. He is no longer with us.

I checked php.ini and file_uploads = On

Checked LocalSettings.php:

$wgEnableUploads       = true;

$wgGenerateThumbnailOnParse = false;

$wgUseImageMagick = true;

$wgImageMagickConvertCommand = "/usr/bin/convert";

$wgFileExtensions = array('png', 'gif', 'jpg', 'jpeg', 'doc', 'xls', 'bib', 'dat', 'pdf', 'ppt', 'txt', 'tex', 'docx', 'xlsx', 'pptx', 'ps');

$wgUploadDirectory= "$IP/images";

the /images directory has 775 permissions currently, not the 755 recommended by MW documentation. I tried changing it to 777 (just for the directory, not recursively) temporarily and that did not resolve the issue. It is also not a good solution because this is on a public web server.

/images is owned by apache/apache

I tried using the actual directory instead of $IP/images, but that did not help

I am not sure what else to try or check

I presume here that the webserver is running as the apache user.

Most commonly this is an ownership issue. Try and change the owner to apache/apache recursively in the images directory (including all files/subdirectories).

775 or 755 should both be fine provided they have the right owner. 777 isn't really reccomended for security reasons but if you want to try that out of desperation you would need to do it recursively.

Rarely selinux can cause issues. Check your selinux logs.

Hello. For some time now I have been having the problem where all the sudden when I try to click on "edit source" or "Source Editor" while in Visual Editor, it does nothing, in fact nothing loads. Sometimes it will give you the prompt: Invalid response from server.

Also I have the problem where now whenever I try to save long written articles the article will start saving and then prompt with: "server didn't respond in time"

I have updated the response time to being longer than was before and it sometimes works but usually does not and just gives that prompt.

This is on Mediawiki 1.40 btw.

I would suggest checking your php and apache error log to try and figure out if it is just a normal timeout or something else going wrong.

For timeout, be sure you have $wgMainCacheType set to something that works, as that can help a lot with performance.

I always get the invalid login CSRF token, it only happens when I want to get a login-type CSRF token. If I only want something like a edit CSRF token, it's valid. I only changed one word "login" to "csrf" in my code and it runs well when using checktoken module, or with "login", it doesn't work.

So... Is there any different when getting a login CSRF or a edit CSRF code? Or it's a MediaWiki issue?

Thanks!

There is a bunch of differences. Most notably though csrf tokens are disabled for logged out users where login tokens are always on.

Most common cause of an issue like this is something with cookies. E.g. you have a bot that is not storing or sending cookies, or there is something wrong with how the web server is handling cookies or session ($wgSessionCacheType) cache.

Windows 11 Home with XAMPP 3.3.0 with MediaWiki 1.36

After creating a database username, password and a database with the same name (all matcing details in LocalSettings.php), and after a successful import of the data from a backup I am having trouble accessing MediaWiki from localhost.

The name of the website directory is hanekudai and LocalSettings.php file also contains these data:

$wgServer = "localhost://hanekudai";
$wgEnableCanonicalServerLink = true;

$wgDBtype = "mysql";
$wgDBserver = "localhost";
$wgDBname = "OMITTED";
$wgDBuser = "OMITTED";
$wgDBpassword = "OMITTED";
$wgDBprefix = "";
$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

In a web browser, the command localhost redirects me to XAMPP welcome page but the command localhost/hanekudai leads to the same webpage I am currently at.

How to get MediaWiki to work on XAMPP?

localhost:// is not a valid protocol. http:// and https:// are protocols.

It is true that these two are protocols and I was confused and changing:

$wgServer = "localhost://hanekudai";

to:

http://localhost:hanekudai

Solved the problem.

Oh, no it didn't solve the problem (it seemed to because I got an error after forgetting to turn on MySQL) but anyway I now get:

This page isn’t working right nowlocalhost sent an invalid response.

Any suggestions what to do?

http://localhost/hanekudai

Don't take this the wrong way... but if you don't know how URLs work, I don't think you are going to enjoy running a server. This is very basic required knowledge and if you got stuck here, there are going to be 100 more points after this that you are likely going to get stuck at.

@TheDJ

You are wrong. I know how URLs work since year 1996 approximately.

In this post I meant to write:

It is true that these two are protocols and I was confused and changing:

$wgServer = "localhost://hanekudai";

to:

$wgServer = "http://localhost:hanekudai";

didn't solve the problem.

I couldn't edit the post above to fix my mistake for some reason (it's very bad that anonymous users here can't edit their posts even for just one hour or 12 hours from the posting operation).

That being said

Evidently I had another mistake there confusing : instead of / after years I didn't set a local server environment on Windows so just chill out and don't be so demagogue about alleged 100 future probelms that never were and shouldn't be and about what I am going to enjoy or not.

Here is the first part of a Bash script I once wrote years ago to set my VPS on a Digital Ocean droplet, something I greatly enjoyed doing at the time:

#!/bin/bash

apt update -y
apt upgrade sshguard
apt upgrade ufw
ufw --force enable
ufw allow 22,25,80,443/tcp
ufw allow 22,25,80,443/udp
apt upgrade unattended-upgrades wget curl zip unzip tree git at
apt install lamp-server^
apt install certbot python3-certbot-apache
a2enmod http2 deflate expires # Activate Apache mods
systemctl restart apache2

Don't be hasty in your conclusions.

Anyway, to any user who wants to help, even with:

$wgServer = "http://localhost/hanekudai";

but the site still doesn't work. After executing localhost/hanekudai in a web browser, I am being redirected to:

http://localhost/hanekudai/index.php/Hanekudai

were I get the following error message:

This page isn’t working right now

localhost redirected you too many times.

• Try deleting your cookies.

ERR_TOO_MANY_REDIRECTS

As suggested in the error message, I have flushed all caches from all time in another web browser and tried to execute the address again but got the same error message.

If anyone has any idea why that happens, pelase share it.

> $wgServer = "http://localhost/hanekudai";

This is wrong. $wgServer should only have the protocol and server part of the url not the path component. The path component goes in $wgArticlePath / $wgScriptPath.

If I am not mistaken, adding the following line to LocalSettings.php solves the problem:

$wgArticlePath = '/index.php?title=$1';

Manual:$wgArticlePath says:

This is the base URL that will be used to construct all internal links within MediaWiki. The default value points it to the main index.php script using a relative URL, but if you are using .htaccess for pretty URLs, this can be altered as required.

I don't know if and how it solves the problem because now I have another error relating to the skin Timeless which I recall modifying in the time.

I have solved the skin problem by replacing the skin to Vector and the site homepage goes up but without CSS and when I click the login link I am redirected to the XAMPP welcome page.