Open main menu

MediaWiki β

Project:Support desk

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, Wikimedia Developer Support, Q&A, mwusers (unofficial forum) 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".

Import fehlgeschlagen: Es wurde kein Interwiki-Präfix angegeben

Shadowslight (talkcontribs)

Ich wollte eine xml Datei importieren und bekomme diese Fehlermeldung.

Hat jemand einen Tip wie man das beseitigen kann ?

Reply to "Import fehlgeschlagen: Es wurde kein Interwiki-Präfix angegeben"

How to remove/disable page information in search results

2 (talkcontribs)

Hi! I'm not really good with coding and are having problems with removing/disabling page information in my search results. I use the standard search engine. In the attached picture I have marked in red which information I want to remove/disable; I would like to just have list of page titles as search results.

The page in question is

AhmadF.Cheema (talkcontribs)

Try setting the following in your Wiki's MediaWiki:Common.css,

#mw-content-text > div > ul > li > div.searchresult { display: none }
#mw-content-text > div > ul > li > { display: none }

For future reference, you can make use of browser developer tools (F12) to select and edit the CSS of a web page's elements.

Reply to "How to remove/disable page information in search results"

User not receiving email to confirm email address.

Alberteranio (talkcontribs)

i'm new to mediawiki. i'm using $wgEmailConfirmToEdit = true;

how to fixed this? when i wan't to confirm email address but there's no incoming email confirmation.

Please explain step by step. thankyou

Reply to "User not receiving email to confirm email address."

Registered User not allowed to edit. Not receiving Email to confirm email address.

Kuhitkuhit (talkcontribs)

Developed this problem since I deactivated automatic registration. I can still as the administrator create users, however when the user login, the wiki shows that he is logged in but when he tries to edit it says: "You do not have permission to edit this page, for the following reason: You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences."

Tried clicking on "user preferences" but it does not allow me to "check" all the boxes in "email options".

Also when I click on "Confirm e-mail address"
This message shows:
"A confirmation code has already been e-mailed to you; if you recently created your account, you may wish to wait a few minutes for it to arrive before trying to request a new code."

The problem is: The user does not get the email. So the user can't confirm.

in my localsettings.php the following shows:
$wgEnableEmail = true;
$wgEnableUserEmail = true;
$wgEmailAuthentication = true;
$wgPasswordSalt = true;
$wgEmailConfirmToEdit = true;

AKlapper (WMF) (talkcontribs)

If the email is not received, have you checked your mailserver's error log? Did you receive any kind of bounce notifications? Also thinking of phab:T66795 depending on the mailserver of the recipient...

Alberteranio (talkcontribs)

hello, is this resolved? please let me know how to fixed this..

Reply to "Registered User not allowed to edit. Not receiving Email to confirm email address."
Janezdrilc (talkcontribs)
Jdforrester (WMF) (talkcontribs)

StructuredDiscussions was based on the work on the third version of LiquidThreads.

Janezdrilc (talkcontribs)

That means LiquidThreads are outdated and will sooner or later be replaced with StructuredDiscussions?

(Asking for the sake of translating.)

AKlapper (WMF) (talkcontribs)

Extension:LiquidThreads answers this already? It says "unmaintained", it says "cancelled".

"later be replaced" depends on each wiki's admins; cannot generalize. :)

Janezdrilc (talkcontribs)

Ups, yes. I missed the notice. Thanks.

Upgrade from 1.27.4 to 1.31.0 fails during database update

Summary last edited by Ciencia Al Poder 08:38, 16 July 2018 7 days ago

A database permissions problem reported by the database schema update script (/maintenance update.php) was misleading.

The problem was tracked to an incompatible LocalSettings.php file.

Old installations were setting $wgDBmwschema to 'mediawiki' in LocalSettings.php. This setting was ignored for MySQL installs, but it's now being taken into account since MediaWiki 1.31. Remove this setting from LocalSettings.php if you're using MySQL.

Lady G2016 (talkcontribs)

Current: MediaWiki 1.27.4 Upgrade to: MediaWiki 1.31.0

PHP 7.1.17 (fpm-fcgi) MariaDB 10.2.14 URL - localhost (test environment)

Running the maintenance script update.php produces a privilege error:


Turning off Content Handler DB fields for this part of upgrade. Adding ipb_id field to table ipblocks ...[06a6bcb5ba7a28f0640c1c8d] [no req] Wikimedia\Rdbms\DBQueryError from line 1457 of /var/www/html/w/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: ALTER TABLE `mediawiki`.`ipblocks`

ADD ipb_auto tinyint NOT NULL default '0',
ADD ipb_id int NOT NULL auto_increment,

Function: Wikimedia\Rdbms\Database::sourceFile( /var/www/html/w/maintenance/archives/patch-ipblocks.sql ) Error: 1142 ALTER command denied to user 'wiki'@'localhost' for table 'ipblocks' (localhost)


  1. 0 /var/www/html/w/includes/libs/rdbms/database/Database.php(1427): Wikimedia\Rdbms\Database->makeQueryException(string, integer, string, string)
  2. 1 /var/www/html/w/includes/libs/rdbms/database/Database.php(1200): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
  3. 2 /var/www/html/w/includes/libs/rdbms/database/Database.php(4194): Wikimedia\Rdbms\Database->query(string, string)
  4. 3 /var/www/html/w/includes/libs/rdbms/database/Database.php(4129): Wikimedia\Rdbms\Database->sourceStream(resource (closed), NULL, NULL, string, NULL)
  5. 4 /var/www/html/w/includes/installer/DatabaseUpdater.php(683): Wikimedia\Rdbms\Database->sourceFile(string)
  6. 5 /var/www/html/w/includes/installer/DatabaseUpdater.php(751): DatabaseUpdater->applyPatch(string, boolean, string)
  7. 6 /var/www/html/w/includes/installer/DatabaseUpdater.php(482): DatabaseUpdater->addField(string, string, string)
  8. 7 /var/www/html/w/includes/installer/DatabaseUpdater.php(446): DatabaseUpdater->runUpdates(array, boolean)
  9. 8 /var/www/html/w/maintenance/update.php(200): DatabaseUpdater->doUpdates(array)
  10. 9 /var/www/html/w/maintenance/doMaintenance.php(94): UpdateMediaWiki->execute()
  11. 10 /var/www/html/w/maintenance/update.php(245): require_once(string)
  12. 11 {main}

Running the update script as a database user with administrator privileges produces this error:

Function: Wikimedia\Rdbms\Database::sourceFile( /var/www/html/w/maintenance/archives/patch-ipblocks.sql ) Error: 1146 Table 'mediawiki.ipblocks' doesn't exist (localhost)

(same backtrace)


My database user account has "GRANT ALL PRIVILEGES ON `wiki`.* TO 'wiki'@'localhost'".

There are no errors when I run the update script from a version 1.31 clean install.

There are no errors when I run the update script from my current version 1.27.4.

I am blocked upgrading to version 1.31.0.

How can I debug this problem? I do not see any mention of this problem in Phabricator.

2001:16B8:106B:1200:B5FB:6E29:5A6F:ED48 (talkcontribs)

This is a problem with MySQL/MariaDB permissions. You are speaking about two different databases!

> ALTER TABLE `mediawiki`.`ipblocks`

> ALTER command denied to user 'wiki'@'localhost' for table 'ipblocks'

> GRANT ALL PRIVILEGES ON `wiki`.* TO 'wiki'@'localhost'

The correct database name obviously is "mediawiki", not "wiki".

Lady G2016 (talkcontribs)

Thank you for the reply. I agree, the database name does not match. There is no mention of 'mediawiki' in my LocalSettings.php file; the correct database name is 'wiki'. Therefore, the database name has changed during the script execution.

I was incorrect in my earlier statement of There are no errors when I run the update script from a version 1.31 clean install. The script did indeed run, but that was for a clean (new) database. The conditions which triggered my error did not occur - modification of an existing database.

All maintenance scripts utilize the configurations in LocalSettings.php. Perhaps this is the source of my problem? I replaced my existing LocalSettings.php file with the version created from a clean install. It worked!

I then modified the "clean" LocalSettings.php to align with my existing configuration. Extensions were added to the bottom of the file. (Previously, they were near the top of the file.) I don't know if the extension placement or a configuration setting was source of my problem.

In any case, I have a working configuration and can proceed with my testing.

Albert Ke (talkcontribs)

I had exactly the same error message as @Lady_G2016 indicated when upgrading from MW1.30 to MW1.31. So I asked for help from my University of Colorado colleague at the IT department, Karen. Karen indicated the following:

It almost looks like there is a code error. In most cases, the settings use $wgDBname, which properly points to the mysql database "csdms_wiki" [the dbname of my wiki].   However, in Setup.php, there is a reference to $wgDBmwschema, which, per LocalSettings.php should only be used if you are using postgresql. In LocalSettings.php, $wgDBmwschema points to 'mediawiki'. So maybe try changing the value for $wgDBmwschema in LocalSettings.php from 'mediawiki' to 'csdms_wiki'?

I did that and the update.php script runs smoothly. So could it be that the reference in the Setup.php to $wgDBmwschema shouldn't be there when running the wiki from a mysql database?



Lziobro (talkcontribs)

I had this exact issue as well. I use MySQL. My LocalSettings.php, which was originally generated quite a many versions ago, had this code:

$wgDBmwschema       = 'mediawiki';

I changed it to this, and the problem went away.

$wgDBmwschema       = $wgDBname;
Ciencia Al Poder (talkcontribs)

Site CSS, can't find header h1 element

Noxiousnoxy (talkcontribs)

Hi, inspecting the header, h1, title of a page it has the following css loading...

h1, h2, h3, h4, h5, h6 {

    color: #000;

    background: none;

    font-weight: normal;

    margin: 0;

    overflow: hidden;

    padding-top: 0.5em;

    padding-bottom: 0.17em;

    border-bottom: 1px solid #a2a9b1;


I can't find this css anywhere.

It says it loads in at...


But I don't know where to find this to edit it. I do not wish to overide it, but find where it's already stated.


Malyacko (talkcontribs)

You can use the URL parameter "debug=true" to find the exact file.

Noxiousnoxy (talkcontribs)

changing the parameter didn't work at all.

But I found where all the css is hiding. For future reference;


Amycjgrace (talkcontribs)

My website at is running MediaWiki 1.31.0, PHP 7.2.5, MySQL 5.6.36-82.1, Lua 5.1.5, and Scribunto (106fbf4}. I imported several infoboxes and templates which all seemed to work correctly. The most common is template:infobox video game. Although pages with that infobox appear correctly, when I enable php error logging, I get the error: "Undefined offset: 1 in /home/mysweetw/public_html/ti/extensions/Scribunto/includes/engines/LuaStandalone/LuaStandaloneEngine.php on line 426." I looked at line 426 of LuaStandaloneEngine.php which says "return $result[1];" but that didn't help me discover the issue. The error doesn't seem to affect any pages, but if possible, would like to figure out a way to resolve the error. Any thoughts on how to discover the source of the error?

Reply to "Infobox or Scribunto Error Help"
Fokebox (talkcontribs)

Hi there! Could you please let me know if there is an extension that allows to make e-mail the message to all registered users?

AhmadF.Cheema (talkcontribs)
Reply to "E-mailing to registered users"

Problems after migrating 1.28 to 1.30

Summary by Ciencia Al Poder
Vledru (talkcontribs)
Ciencia Al Poder (talkcontribs)

If your wiki is public, please share a link so we can take a look at the problem.

Open a file description page (a page of the File: namespace) and click on the "view full size". If it displays an error instead of the file itself, something is misconfigured. If the error is a 404 not found, either MediaWiki is pointing to the wrong URL or your webserver has problematic rewrite rules. If error is a "forbidden" or "unauthorized", there may be problems with permissions of those files.

If it works fine, then problem may be for thumbnails.

Vledru (talkcontribs)

Thank you Ciencia Al Poder

My wiki is not public ... However, I did your tests and everything works normally. When I remove the size of my thumbnail in my wikicode [[File: example.jpg | 400px | legend]] -> [[File: example.jpg | legend]] it works perfectly ...

Really strange ^^

Ciencia Al Poder (talkcontribs)

Problem is on thumbnails, then. Use the thumb.php script (from your browser) to request a file on your wiki (with the "f" parameter) and provide a width for the thumbnail (the "w" parameter), and see what happens, if it's displayed correctly or it displays an error.

Robert.hanke (talkcontribs)


I have the same problem. This doesn't work in my wiki:

[[File:image.png|thumb|My Image]]

this works:

[[File:image.png|frame|My Image]]

thumb.php works just fine:


My wiki is also a private wiki.

Ciencia Al Poder (talkcontribs) (talkcontribs)

We face the same problem after upgrading to 1.30: Thumbnails are shown as broken images though they are correctly rendered on server side. The developer console of chrome reveals the following error messages:

Failed parsing 'srcset' attribute value since it has an unknown descriptor.

Dropped srcset candidate "/uploads/thumb/xxx.png/450px-xxx.png"

Failed parsing 'srcset' attribute value since it has an unknown descriptor.

Dropped srcset candidate "/uploads/thumb/xxx.png/450px-xxx.png"

GET https://aaa.bbb.ccc/5x 404 (Not Found)

Turning off Manual:$wgGenerateThumbnailOnParse and running maintenance script Manual:FAQ#…are some of my images not showing up after an upgrade does not fix the issue.

thumb.php works perfectly.

Maybe this thread deals with the same issue: Topic:U7m4bysmlzhqp0y1 ?

Is this a known bug, can anybody confirm this behaviour or is there any solution?

Ciencia Al Poder (talkcontribs)

Inspect the image with the developer tools of your browser (right-click and inspect this element, or hit F12 and manually select the image). If the srcset property contains commas instead of dots, the problem is the server locale and you should change it on LocalSettings.php by adding:

setlocale(LC_NUMERIC, "C");

See task T181987 (talkcontribs)

This fixed our problem, thank you!

Vledru (talkcontribs)

Sorry for the delay, I had to let go of my investigation ... Thank you all for solution! It's resolved!

Rastaferraille (talkcontribs)

Hello, thanks for the trick but for me setlocale(LC_NUMERIC,"C"); has no effect..

dots are still replaced by comma in my html

Do you have an idea please ?

Many thanks (I'm from France, I upgraded PHP form 5.6 to 7.0 and mediawiki from 1.27 to 1.31)

Ciencia Al Poder (talkcontribs)

Have you tried editing the page and doing a preview, to be sure you're not seeing a cached version of the page generated before the change in setlocale?

Reply to "Problems after migrating 1.28 to 1.30"