Project:Support desk

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

Read in your language

There are also other places where to ask :

• IRC
• mailing lists
• Wikimedia Developer Support
• Q&A
• mwusers (unofficial forum)

Before you post

• Make sure you have read our fundamental introduction.
• Please carefully check our FAQ and Errors and Symptoms pages.
• Project:Current issues is where you should discuss issues about the mediawiki.org website itself.
• If your question is about a specific function, please read the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• Test wiki editing at the Project:Sandbox.

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".

Previous page history was archived for backup purposes at Project:Support_desk/old on 2015-07-30.

I'm trying to update our stone-old mediawiki 1.24 to 1.34.

At the moment I'm hangig at two things: I use the giant family case in the LocalSettings.php, with only one case active and the default set. When trying to load the site I get "Parse error: syntax error, unexpected end of file in /var/www/mediawiki-1.34.0/LocalSettings.xxx.php on line 198" and I have no clue what it means. I did basically take the settings files from the old version and updates it. For some reason I had to move several options like $wgDebugDumpSql and wfLoadExtension( 'ParserFunctions' ); to the main LocalSettings.php file. At least I don't know how else I should fix the errors where it doesn't say "unexpected end of file" but "unexpected '$wgDebugDumpSql'. But I don't see anything missing to end the file.

When trying to run the update.php for database update from the bash I only get "PHP Notice:  Undefined index: SERVER_NAME in /var/www/mediawiki-1.34.0/LocalSettings.php on line 6". I know that this can't work from CLI and to fix it it was already said to use php_uname, but I have no clue how and where to use that

Debian 10.3

PHP 7.3.14

MariaDB 10.3.22

usually the first error means you forgot a ; or ' somewhere (Probably not on the line number being reported, but on an earlier line). Try putting the file through a syntax highlighter to see if that helps you find the error.

php_uname is not a suitable replacement for SERVER_NAME when running on the commandline. If you specify --server servername as an option to update.php, it will define $_SERVER['SERVER_NAME'] appropriately.

thanks, I'll try that

ok, it was a missing ; I should have been able to think about that myself. Anyway...

Now the only problem seems to be the database update. I used your method but I only get "Invalid address" back. I tried with and without https: infront, I tried with both the website and the server name, nothing. So I'm a bit confused what else it wants

--server should be exactly the sane format as SERVER_NAME (protocol and host but no path). So for https://example.com/mywiki something like

php update.php --server "https://example.com"

If all else fails, you can try using the web updater by navigating to mw-config subdirectory.

I'll try that tomorrow. The Server name in the config is "//wiki x y de" (or is that an old scheme?) and I tried both "wiki x y de" and "https // wiki x y de" both failed. I tried even with IP adress.

I'll try to get to the web updater, yesterday that failed, maybe because of the still existing errors with the LocalSettings

So the web updater would be accessable via "wiki x y de/mw-config/<"nowiki>" instead of the normal "<nowiki>wiki x y de/index php"?

PS: I had to rip the URLs apart to post it, so every space between quotes stands for a dot

so. I tried it now. I used the server name exactly as is in the LocalSettings file (of course without the leading //, don't know with what I confused that).

It's still invalid address. Furthermore I can't manage to get to the web interface of the database update. In the Link you can see a picture of the errors (I added error_reporting( -1 ); ini_set( 'display_errors', 1 ); to the LocalSettings.php to get to them)

http //img4web com/i/DVERS png

Edit: I achieved something but not much: I startet the update .php with -S wiki x y de:8080 and then bound that port to my local PC's port 8080 with ssh -L. Now I can go into a browser on localhost:8080. Still I can't access anything but I get a page with a purple top bar, so it's something.

Edit2: I did that again but this time with "-t ../" so teh document root wouldn't be the maintenance folder. I managend to get to some page und /mw-config/ where I could set my language and the wiki language (the latter I suppose is set to german, at least the content is german) but upon continuing I only see "This wiki is not available. Check configuration."

ok, I'm getting closer: I started the index.php in mw-config with "php -f index.php -S 127.0.0.1:8080 -t ../". It's giving back the error "127.0.0.1:43802 [404]: /mw-config/?page=ExistingWiki". But I can't find the string in any file in mw-config.

So it seems it's somehow searching for the existing wiki. Now how do I tell it what where that is located?

Hey everyone,

I want to upgrade my old Mediaiwki (V.1.21) at the newest version (V.1.34). (I use a DebianLinux where I install the new version). I searched on the site of mediawiki for upgrade my wiki (Manual:Upgrading/fr) and i found the patch.

I think it's the best solution for this upgrade ! But.. it will be so long to do every patch manually.

So Is someone know a script for make all install or another solution, please ?

If for patch do you mean a patch file (differencies between one version and other), don't do that. The patch is only available to upgrade from one minor version to another.

Instead, you should download the new version (full), extract on a new empty directory, copy LocalSettings.php from the old one, download any missing extensions you had from the old install, and then make that directory your current published wiki. If your uploads are on a directory outside the installation files you don't have to worry about them, otherwise move it to the new location.

Don't forget to run the "update.php" script

oh... Okay ?

My idea was to create a Debian with the old version and past step by step the patch (until the version 1.34). After, create an other Debian with the last version and make a dump of the old database in the newest... it's really not possible to do it like that ?

I try you're idea !

Thanks !

*your

sorry, my bad

Possible? Yes, but there's no benefit in doing that. The entire contents of the wiki are on the database, and the uploaded files. You don't need a working MediaWiki installation to migrate it to a new server. Just take a backup of the database and restore it on the new server, transfer the uploads, and install/upgrade on the new server. See Manual:Moving a wiki

Hi Ciencia AL Poder,

1. I want to upgrade my wiki from 1.32 to 1.34. Please help me. as you advice above. I will extract 1.34 to new directory and copy paste LocalSettings.php from Old to new.

And im using Mariadb on different server. So Wiki in 1a server and db on 2a Server.

Can I create path like this. ?

/ storage/storagewiki/wiki => This is 1.32 Version Path.

/storage/wiki => Can I create like this for 1.34 Version.

Please help me.

Yes, you can use those paths if that makes sense to you. Note that if you change paths from the previous version, in case you had some hardcoded paths in LocalSettings.php from the old location, or apache rules, you'll need to update those configurations too

Thank you very much. need one help, need to clear be vernability .

Vulnerability CVE IDs = CVE-2019-19910

MediaWiki: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (CVE-2019-19910).

Already I have upgrade wiki to 1.34. still I see this VA. Any advice please.

This is apparently fixed phab:T240487. I'm not seeing how 1.34 can be affected, since the code that introduced the bug was included on the 1.35 branch

Is there such a thing? What I would like to have is a function to add tags to a page with the click of a button rather than by going to the edit page and then saving.

The Page Forms extension's autoedit function might do what you want.

also consider looking into the hotcat gadget

While performing the environmental check after a fresh install. I am getting a backtrace.

PHP 7.4.3 is installed.

Found ImageMagick: /usr/local/bin/convert.

Image thumbnailing will be enabled if you enable uploads.

Found the Git version control software: /usr/local/bin/git.

Using server name "http://192.168.1.91".

Using server URL "http://192.168.1.91".

[c417810b1c3de017dacc2b2d] /mw-config/index.php Error from line 96 of /usr/local/www/mediawiki/vendor/guzzlehttp/psr7/src/Response.php: Call to undefined function GuzzleHttp\Psr7\filter_var()

Backtrace:

#0 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/Handler/StreamHandler.php(114): GuzzleHttp\Psr7\Response->__construct(string, array, MWCallbackStream, string, string)

#1 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/Handler/StreamHandler.php(49): GuzzleHttp\Handler\StreamHandler->createResponse(GuzzleHttp\Psr7\Request, array, GuzzleHttp\Psr7\Stream, NULL)

#2 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php(37): GuzzleHttp\Handler\StreamHandler->__invoke(GuzzleHttp\Psr7\Request, array)

#3 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/Middleware.php(30): GuzzleHttp\PrepareBodyMiddleware->__invoke(GuzzleHttp\Psr7\Request, array)

#4 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/RedirectMiddleware.php(54): GuzzleHttp\Middleware::GuzzleHttp\{closure}(GuzzleHttp\Psr7\Request, array)

#5 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/Middleware.php(58): GuzzleHttp\RedirectMiddleware->__invoke(GuzzleHttp\Psr7\Request, array)

#6 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/HandlerStack.php(67): GuzzleHttp\Middleware::GuzzleHttp\{closure}(GuzzleHttp\Psr7\Request, array)

#7 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/Client.php(277): GuzzleHttp\HandlerStack->__invoke(GuzzleHttp\Psr7\Request, array)

#8 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/Client.php(98): GuzzleHttp\Client->transfer(GuzzleHttp\Psr7\Request, array)

#9 /usr/local/www/mediawiki/vendor/guzzlehttp/guzzle/src/Client.php(106): GuzzleHttp\Client->sendAsync(GuzzleHttp\Psr7\Request, array)

#10 /usr/local/www/mediawiki/includes/http/GuzzleHttpRequest.php(174): GuzzleHttp\Client->send(GuzzleHttp\Psr7\Request)

#11 /usr/local/www/mediawiki/includes/http/HttpRequestFactory.php(124): GuzzleHttpRequest->execute()

#12 /usr/local/www/mediawiki/includes/http/HttpRequestFactory.php(146): MediaWiki\Http\HttpRequestFactory->request(string, string, array, string)

#13 /usr/local/www/mediawiki/includes/installer/Installer.php(1215): MediaWiki\Http\HttpRequestFactory->get(string, array, string)

#14 /usr/local/www/mediawiki/includes/installer/Installer.php(1084): Installer->dirIsExecutable(string, string)

#15 /usr/local/www/mediawiki/includes/installer/Installer.php(504): Installer->envCheckUploadsDirectory()

#16 /usr/local/www/mediawiki/includes/installer/WebInstallerWelcome.php(32): Installer->doEnvironmentChecks()

#17 /usr/local/www/mediawiki/includes/installer/WebInstaller.php(270): WebInstallerWelcome->execute()

#18 /usr/local/www/mediawiki/mw-config/index.php(80): WebInstaller->execute(array)

#19 /usr/local/www/mediawiki/mw-config/index.php(38): wfInstallerMain()

#20 {main}

what method did you use to install? (Git? Downloaded official tarball, something else?)

Try running the following command in the mediawiki directory and let me know if that fixes it:

composer update --no-dev

I mostly followed the instructions here Manual:Running MediaWiki on FreeBSD I installed php 74 instead of 56

when I run composer I get multiple errors

root@wiki:/usr/local/www/mediawiki # composer update --no-dev

> ComposerHookHandler::onPreUpdate

Loading composer repositories with package information

Updating dependencies

Your requirements could not be resolved to an installable set of packages.

  Problem 1

   - Installation request for nikic/php-parser 3.1.5 -> satisfiable by nikic/php-parser[v3.1.5].

   - nikic/php-parser v3.1.5 requires ext-tokenizer * -> the requested PHP extension tokenizer is missing from your system.

  Problem 2

   - Installation request for psy/psysh 0.9.9 -> satisfiable by psy/psysh[v0.9.9].

   - psy/psysh v0.9.9 requires ext-tokenizer * -> the requested PHP extension tokenizer is missing from your system.

  Problem 3

   - squizlabs/php_codesniffer 3.5.0 requires ext-tokenizer * -> the requestedPHP extension tokenizer is missing from your system.

   - mediawiki/mediawiki-codesniffer v28.0.0 requires squizlabs/php_codesniffer 3.5.0 -> satisfiable by squizlabs/php_codesniffer[3.5.0].

   - Installation request for mediawiki/mediawiki-codesniffer 28.0.0 -> satisfiable by mediawiki/mediawiki-codesniffer[v28.0.0].

  To enable extensions, verify that they are enabled in your .ini files:

then it goes on to list a boat load of extensions

In order to fix the the issue composer encountered I had to install

php parser

php tokenizer

php extensions

Once composer finished I restarted the VM and was able to continue on with the installer.

I need 2011 dumps of wikipedia from where I can download those pages. Or how can I get text from recent dumps which is older than 2011 thanks

See https://dumps.wikimedia.org/.

Thanks @Malyacko for your answer but I need the 2011 version XML files which have all the article text. I don't know how to extract that specific Wikipedia dumps? can I get it from the recent dumps? Thanks

I'm trying to embed a Google Calendar on my Wiki. However, I'm having trouble using the link provided on the Widget page. Would someone be able to help?

Which widget page? Please also elaborate what "trouble" means - what have you tried, what happens? Which MediaWiki version?

in my MediaWiki active users displays 0 even after editing the articles daily . I don't know why it is not changing . Does user need any parameters to become the active user?

In your root MediaWiki directory, try running the following command through SSH:

php maintenance/initSiteStats.php --active --update

If this causes the active users to update correctly, then this is an old bug (T140079).

Hi, I've installed MediaWiki 1.34 on IIS with Windows Sever Standard 2016. MySql database is 8.0.19. PHP version is 7.4.3.

Problem is when i try to edit page content with polish special characters like "śćż" etc. When I edit content and write "Na skróty" and click preview content then characters ar displayed as "Na skróty",

Sometimes it work properly and characters are displayed properly and sometimes not.

What should i check?

Additionally other polish words in MediaWiki "core" are displayed properly. Problem is only with preview area and with edit area.

Is the problem consistent? I'm going to guess that IIS is serving some bad headers. Do you know how to check the http headers?

Problem is not consistent. It happends from time to time. Yes i know how to check http headers. I will compare them when it is ok and it is not.

empty

I think it's a problem with the site's default character set, which should be UTF-8.

Is your site public? Maybe we could look.

maybe something like https://forums.iis.net/t/1229593.aspx?URL+Rewrite+Module+decodes+UTF+8+encoded+querystring+as+if+it+were+iso+8859+1 is related?

@MarkAHershberger - Site is not public.

I've made few test.

This is how page looks when its displayed:

https://drive.google.com/open?id=1Xs9rS6kAvPoZnDQz37XISoG7t3dUtlLr

And the headers:

https://drive.google.com/open?id=1nOsd58cq2ckFpF8z4em35xQIyFwlh740

Here how it looks when i press preview:

https://drive.google.com/open?id=1--gKDZBZWJaIDdbrFazDrrclQ9Gne6A6

and the headers:

https://drive.google.com/open?id=1eKBrdtYuSQ6bZgTA6WRjrqsSLsHFPR3z

When i open both headers on notepad++ they look good.

Now i'am realy confused and don't know where to check.

It also looks like you're running MediaWiki as a plugin to WordPress. Is that the case?

If so, how do you have them set up and what versions?

No, Media Wiki work's standalone.

feh... Sorry, I got distracted by the wpUnicodeCheck header that I didn't recognize.

@MarkAHershberger wpUnicodeCheck is needed to check if characters are properly encoded.

Now i see another regularity. When i have problem with polish characters. Then i visit phpmyadmin website located on the same IIS Server and go back to mediawiki page. After refresh page all polish characters are displayed properly.

Hello, I want to enter my mediawiki through url which contains username and password and used two methods.

START CODE

<?php

/*

    login.php

    MediaWiki API Demos

    Demo of `Login` module: Sending post request to login

    MIT license

*/

$endPoint = "http://192.168.73.129/mediawiki-1.34.0/api.php";

$login_Token = getLoginToken(); // Step 1

loginRequest( $login_Token ); // Step 2

// Step 1: GET request to fetch login token

function getLoginToken() {

global $endPoint;

$params1 = [

"action" => "query",

"meta" => "tokens",

"type" => "login",

"format" => "json"

];

    $url = $endPoint . "?" . http_build_query( $params1 );

$ch = curl_init( $url );

curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true );

curl_setopt( $ch, CURLOPT_COOKIEJAR, "/tmp/cookie.txt" );

curl_setopt( $ch, CURLOPT_COOKIEFILE, "/tmp/cookie.txt" );

$output = curl_exec( $ch );

curl_close( $ch );

$result = json_decode( $output, true );

return $result["query"]["tokens"]["logintoken"];

}

// Step 2: POST request to log in. Use of main account for login is not

// supported. Obtain credentials via Special:BotPasswords

// (https://www.mediawiki.org/wiki/Special:BotPasswords) for lgname & lgpassword

function loginRequest( $logintoken ) {

global $endPoint;

$username = "Alexander@alexander";

$password = "lgb0plp3ri0ont3n73at5kna8rkbd2e9";

$post_data = "?action=login&lgname=$username&lgpassword=$password&logintoken=$logintoken&format=json";

echo ($urlfinal=$endPoint.$post_data);

echo "<br/>";

$post_test="http://192.168.73.129/mediawiki-1.34.0/index.php?title=Special:UserLogin&action=submitlogin&wpName=alexander&wpPassword=a12345ba12345b&returnto=index.php";

echo ($urlfinal=$post_test);

}

END CODE

the urls i get are

method I: http://192.168.73.129/mediawiki-1.34.0/api.php?action=login&lgname=Alexander@alexander&lgpassword=lgb0plp3ri0ont3n73at5kna8rkbd2e9&logintoken=4b751c26da1bc5c538044c4de299442c5e6959d8+\&format=json

error I:

{"error":{"code":"mustpostparams","info":"The following parameter was found in the query string, but must be in the POST body: lgpassword.","*":"See http://192.168.73.129/mediawiki-1.34.0/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at &lt;https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce&gt; for notice of API deprecations and breaking changes."}}

method II: http://192.168.73.129/mediawiki-1.34.0/index.php?title=Special:UserLogin&action=submitlogin&wpName=alexander&wpPassword=a12345b&returnto=index.php

Error II: NO login

thanks

You can't login through GET. You must use POST, as the error message says.

Hello, i am trying to install mediawiki, unfortunately i am getting this error report. Can anyone help me please? Many gretings Gloria

[c8aeae25] [no req] Exception from line 61 of /data/multiserv/users/1289248/projects/2707382/www/mediawiki-1.24.1/includes/WebRequest.php: MediaWiki does not function when magic quotes are enabled.

Backtrace:

1. 0 /data/multiserv/users/1289248/projects/2707382/www/mediawiki-1.24.1/includes/Setup.php(544): WebRequest->__construct()
2. 1 /data/multiserv/users/1289248/projects/2707382/www/mediawiki-1.24.1/includes/WebStart.php(121): require_once(string)
3. 2 /data/multiserv/users/1289248/projects/2707382/www/mediawiki-1.24.1/mw-config/index.php(36): require(string)
4. 3 {main}

This error means that there is a problem with your PHP configuration: You have an option called "magic quotes" enabled. However, MediaWiki needs this option to be disabled in order to work properly.

You need to disable magic quotes in the PHP configuration to fix this problem!

thank for the answer. Can you tell how i find my php configuration. I have kilu.de and also filezilla. Is it anywhere there?

The PHP configuration usually is located inside php.ini files. Where the according files are located in your case depends on the server setup. Your host will know that! Note that many shared hosters do not allow you to edit these files as doing so you would be able to change the PHP configuration.

I would have lked to give you a link to the PHP manual where you will find further details about how to enable/disable magic quotes, but mediawiki.org does not let me save posts, if they contain links. So no link for you.

maybe you could send it to my emailadress: Glow88 (at) gmx. net That would be so great. Thank You

Oh, I just happened to notice this comment and just figured I'd mention that I found a quick fix for that. If you surround the link in nowiki tags, you can display the link, although it won't be clickable.

For example:

https://en.wikipedia.org/wiki/Main_Page

Also, internal links seem to work fine.

So here it is: http://php.net/manual/en/security.magicquotes.disabling.php (Anyway, bothersome that posting links is broken. In the past it was working, maybe it presented a captcha, but it was working. Yuch!)

Lol yeah I hope it's just a bug that gets fixed soon.

@88.130.127.250: I have fixed your post to make it a clickable link :) (hope that's not a general problem? :/)

Thanks for fixing, Florian!

I think it is a general problem: It worked until maybe two weeks or so back and then it stopped. Since then, when I have a link in my posts, after clicking "Save page", these posts are not saved. As I said that started maybe two weeks or so ago. Since then, this problem is there with every single post I try to make here.

I don't know if a captcha is wanted or whatever, anyway: The current situation is just bad! This should be fixed again!