Welcome to the MediaWiki Support desk. This is a place where you can ask any questions you have about installing, using or administrating the MediaWiki software.
For issues about the mediawiki.org website, report to Village Pump instead.
Ask technical questions about Wikimedia websites on meta:Tech instead.
Post a new question
To help us answer your questions, please indicate which version of MediaWiki you are using, as found on your wiki's Special:Version page:
If possible, add $wgShowExceptionDetails = true;error_reporting( -1 );ini_set( 'display_errors', 1 ); to LocalSettings.php in order to make MediaWiki show more detailed error messages.
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.
To start a new thread, click the box with the text Add topic.
internal error Erreur fatale de type « Shellbox\ShellboxError
Latest comment: 10 days ago2 comments2 people in discussion
internal error when saving an edit:
[864d81fc-f74e-4f6d-a70f-1dad0bec6ad5] 2026-10-21 16:14:34: Erreur fatale de type « Shellbox\ShellboxError
Translation: The table is wrong in the folding state.
Here are two wikitables with mw-collapsible. The first is collapsed by default and the second is not. When the display language is changed to Chinese, the collapsed/folded header is displayed as vertically while the uncollapsed/unfolded header is displayed right-to-left.
Example:
标题
1
2
3
4
5
6
2
3
5
7
11
13
vs
标题
1
2
3
4
5
6
2
3
5
7
11
13
@Pawsdt: please confirm that I've accurately described the problem you raise.
Latest comment: 10 days ago3 comments2 people in discussion
I am trying to update our wiki from 1.39 to 1.43
I've updated various entries in composer.local.json to more recent versions, and made some changes to LocalSettings.php and the server seems to start up fine, so then the next stage is to update the database.
It's starts off ok, but then hits a problem
...ipblocks doesn't exist.
Table pagelinks contains pl_title field. Dropping...Wikimedia\Rdbms\DBQueryError from line 1198 of /var/www/mediawiki/w/includes/libs/rdbms/database/Database.php: Error 42704: ERROR: index "pl_namespace" does not exist
#0 /var/www/mediawiki/w/includes/libs/rdbms/database/Database.php(1182): Wikimedia\Rdbms\Database->getQueryException('ERROR: index "...', '42704', 'DROP INDEX pl_n...', 'Wikimedia\\Rdbms...')
#1 /var/www/mediawiki/w/includes/libs/rdbms/database/Database.php(1156): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('ERROR: index "...', '42704', 'DROP INDEX pl_n...', 'Wikimedia\\Rdbms...')
#2 /var/www/mediawiki/w/includes/libs/rdbms/database/Database.php(647): Wikimedia\Rdbms\Database->reportQueryError('ERROR: index "...', '42704', 'DROP INDEX pl_n...', 'Wikimedia\\Rdbms...', false)
The wiki has been functioning fine on 1.39, and the upgrade instructions indicate that upgrading from 1.39 directly to 1.43 should be ok. JRHodgson (talk) 01:08, 26 October 2026 (UTC)Reply
Some further information.
Before the update starts, the pagelinks table does include the pl_namespace index, but by the time the update gets to this point it seems it has already been removed. JRHodgson (talk) 20:56, 26 October 2026 (UTC)Reply
@JRHodgson: try re-creating the index and re-runing.
If you don't have a mysql client, you can use the include sql maintenance script:
$ cat>/tmp/pagelinks-indexes.sql<<'SQL'CREATE INDEX IF NOT EXISTS pl_namespace ON pagelinks (pl_namespace, pl_title);CREATE INDEX IF NOT EXISTS pl_backlinks_namespace ON pagelinks (pl_from_namespace, pl_namespace, pl_title);SQL$ phpmaintenance/run.phpsql/tmp/pagelinks-indexes.sql
Latest comment: 9 days ago4 comments2 people in discussion
Im not logged into the nullscape wiki, and when i use my wikimedia login details it fails, theres no button to create an account so i have to manually go to the create account special page. When i go to create an account for that wiki it says i need to be logged in to create an account… meaning i have to make an account if i want to create an account.
nullscape.wiki is a Miraheze wiki, not a Wikimedia wiki, so your account won't work there. It looks like you'll have to ask the wiki's writers to get an account.
Latest comment: 11 days ago3 comments2 people in discussion
I am maintaining 3 mediawiki instances. Two are on version 1.34 and one on 1.33 and I know the upgrade must be done in a series of steps.
My question is, do I have to go one version number at a time, or are there upgrades that can be skipped? I see that a jump straight from 1.39 to 1.43 should be OK. Are there any other instances where intervening upgrades can be skipped? Roygrubb (talk) 10:44, 30 October 2026 (UTC)Reply
Latest comment: 6 days ago4 comments2 people in discussion
Encountering a couple of issues with pending changes (i.e. FlaggedRevs with the $wgFlaggedRevsProtection turned on):
When trying to view the page history of any page currently under pending changes, I get
Warning: Undefined property: FlaggedRevsUIHooks::$dbProvider in FlaggedRevsUIHooks.php on line 563
as well as simultaneously
Internal Error "[aueDpsn57jxilslPg04icAAWQxk] Error: Call to a member function getReplicaDatabase() on null"
When attempting to implement pending changes level 2 onto a page (i.e. wikipedia:WP:ORANGELOCK) I get a "permission denied" error in the protection interface even though the reviewer user group is configured, and I can set autoconfirmed and sysop pending changes with no issue.
Also, a question: how do I hide the "stable version" icon in the upper right hand corner of pages? As in, completely suppress the display for everyone regardless of the stable version status or lack thereof? Asking because it appears to clash with Extension:WikidataPageBanner. I assume some sort of CSS change somewhere? I'm on 1.43 if it makes a difference. The Boston Railfan (talk) 18:33, 1 November 2026 (UTC)Reply
@The Boston Railfan: Being on 1.43 does make a difference. Your PHP version also makes a difference. Do you know which one you're on?
Can you point to your wiki?
I think you can hide the stable version with the following:
PHP version is 8.3.36 (cgi-fcgi). Yes I'm using the 1.43 extension version. My user account is not in the reviewer group but it is in the sysop group which contains all of the permissions that are in the reviewer group as part of its larger toolset. Shouldn't admins be able to configure all protection settings, including PC Level 2? (i.e. a sysop should be able to configure pending changes to require all edits from those who are not reviewer or higher to be checked... essentially WP:ORANGELOCK). I generally prefer not to link to the wiki directly in order to avoid importing vandalism or spam from the Wikimedia suite's crawlers/lurkers (I get too much of it already just from being search engine indexed). The Boston Railfan (talk) 17:09, 2 November 2026 (UTC)Reply
@The Boston Railfan: MediaWiki does not have a sense of hierarchy when it comes to groups. This means, for example, that unless you are in the Interface administrators group, you won't be able to edit MediaWiki:Common.css.
New item for ICAM S.p.A. (Q141855947) not showing up in search
Latest comment: 8 days ago2 comments2 people in discussion
Hello,
I recently created the item Q141855947 for ICAM S.p.A. a few weeks ago, an Italian manufacturer of automated vertical storage systems based in Putignano (Apulia), founded in 1957. In the interest of transparency, I’m the company’s Marketing & Communication Manager, so I have a conflict of interest. I’m happy to follow any guidance on how to handle this.
When I search for “ICAM” on Wikidata, the results show other organizations (for example ICAM, the chocolate manufacturer) but not our item. Could someone help me understand:
whether the item is correctly indexed, or still being processed;
whether anything is missing from its labels, aliases or descriptions that would help it show up and be told apart from other entities called “ICAM”;
whether it meets the notability criteria, and which references I should add to make it more solid.
Latest comment: 4 days ago2 comments2 people in discussion
Since this is a core MediaWiki extension, should the license information for PageImages be more "serious" (for lack of a better term)? There are other less controversial wordings available such as "Unlicense" or "0BSD". It sticks out in a list of bundled extensions.
@MLRodrigue: I certainly agree that it sticks out, but I think it is a serious license as the creator (Sam Hocevar) is a Debian developer (people who are known to be serious about software licensing) and was a Wikimedia France board member.
Some of his other associations show that the creator is a provocateur, but all of this is pretty normal in the world of Free Software.
By “serious”, maybe you mean that it doesn't fit in a corporate environment. I would not disagree with that assessment. Google is the definition of corporate and they do not allow their developers to contribute to WTFPL licensed projects.
I think the approach of the FSF is instructive here: They said it is “not recommended” but confirmed it is compatible with the GPL.
Should it be kept out of MediaWiki core because the authors have a “whimsical” license on their software? No.
Free Software is about freedom. MediaWiki is Free Software. PageImages is useful (indicated by the fact that it is widely used on several projects). The creator of the software is allowed to license the software the way they want.
CARE: site Arc is sunsetting on December 22, 2026.
Latest comment: 5 days ago1 comment1 person in discussion
Just found that is was used (for example) in page Reader_Growth/Minimal_Minerva to reference chrome we must prepare to have some potential impact on archived solutions.
A farewell to Arc
Arc is sunsetting on December 22, 2026.
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.
