Project:Support desk
(Read this message in a different language)
See also
Before you post
- 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.
- 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.
MySQL 8.4+ Compatibility
[edit]MySQL 8.4 has changed the way auto_increment works. Will this affect MediaWiki compatibility?
Data Types & Constraints: 8.4 prohibits AUTO_INCREMENT on FLOAT/DOUBLE columns. Molsen7970 (talk) 18:16, 5 May 2026 (UTC)
- MySQL 8.4 was released more than two years ago, not sure why you'd ask now? Compatibility implies compatibility. Malyacko (talk) 10:51, 12 May 2026 (UTC)
- The highest version of MySQL listed on the compatibility site is MySQL 5.7.0+. I assume the plus at the end means 8.4 is compatible with Mediawiki 1.43.8 because of the "+" but there seems to be a difference between MySQL 5.7 and 8.4 in the way AUTO_INCREMENT works. We were curious if Mediawiki uses AUTO_INCREMENT in a way that would break when we upgrade to MySQL 8.4. (MySQL 8.0 LTS ended last month which is why we are upgrading to the next LTS, 8.4.) Molsen7970 (talk) 20:21, 19 May 2026 (UTC)
- We had this same debate about ambiguity in relation to PHP versions a while back. In that case, "PHP 8.1.0+" did not (at the time) include PHP 8.4. See Talk:Compatibility#PHP_8.4_is_missing_(in_compat_matrix). However, one comment which was wrong in one sense (the truth is "It's hoped that things above it are supported" rather than "everything above is supported") might answer your question here: "e.g. in the database matrix is says MySQL 5.7.0+. For me that means that everything above is supported. e.g. I'm using MySQL 8.4 and mediawiki runs on it" :-) Jonathan3 (talk) 15:24, 23 May 2026 (UTC)
- The highest version of MySQL listed on the compatibility site is MySQL 5.7.0+. I assume the plus at the end means 8.4 is compatible with Mediawiki 1.43.8 because of the "+" but there seems to be a difference between MySQL 5.7 and 8.4 in the way AUTO_INCREMENT works. We were curious if Mediawiki uses AUTO_INCREMENT in a way that would break when we upgrade to MySQL 8.4. (MySQL 8.0 LTS ended last month which is why we are upgrading to the next LTS, 8.4.) Molsen7970 (talk) 20:21, 19 May 2026 (UTC)
Redirects appear as target page, not originating page.
[edit]I am a contributor for a wiki that runs on MediaWiki. In that Wiki, links that point to a redirect page appear as the target page, not the origin page.
For example, if a page titled "Start" has the content "#REDIRECT [[End]]", then [[Start]] appears as "End", rather than "Start".
I've never seen this behavior on other wikis. For example, on this wiki, [[Help:Redirect]] appears as Help:Redirect, not "Help:Redirects". Likewise, on Wikipedia, [[theme park]] appears as "theme park", not the target page "Amusement park".
Is there a setting or plugin I should look for? The version page for that wiki is at https://azudaioh.miraheze.org/wiki/Special:Version. 428koiwai (talk) 17:28, 16 May 2026 (UTC)
- This happens usually when you have the Extension:Display Title enabled. You may ask Miraheze to disable it or to set $wgDisplayTitleFollowRedirects to false. Ciencia Al Poder (talk) 19:55, 17 May 2026 (UTC)
Text on the Special:RevisionDelete page
[edit]Where can the following text be found and edited?
- Deleted revisions will still appear in the page history, but parts of their content will be inaccessible to the public. Other administrators will still be able to access the hidden content and to undelete it, unless additional restrictions are set.
- Suppression should only be used for the following cases:
- potentially libelous information
- inappropriate personal information
- home addresses and telephone numbers, national identification numbers, etc.
- Please confirm that you intend to do this, that you understand the consequences, and that you are doing this in accordance with the policy.
I can't seem to find a page with this content. Thanks in advance for any help! -- 日本穣 Nihonjoe (talk) 01:41, 17 May 2026 (UTC)
- It's split across multiple pages: MediaWiki:revdelete-text-text, MediaWiki:Revdelete-confirm, MediaWiki:revdelete-text-others, MediaWiki:revdelete-suppress-text. Using qqx can easily identify the source of a message. * Pppery * it has begun 06:23, 17 May 2026 (UTC)
- Thanks! That's what I was looking for. -- 日本穣 Nihonjoe (talk) 21:49, 22 May 2026 (UTC)
TranslateWiki.net is down
[edit]Hello @Siebrand @Nikerabbit
Just to let you know that when accessing https://translatewiki.net/, Cloudflare reports a timeout (error 522).
Regards Dregad (talk) 06:30, 18 May 2026 (UTC)
- Only saw this now. We had 4 hours of downtime that is now resolved. Nikerabbit (talk) 15:46, 21 May 2026 (UTC)
class=tpl-stickytable - how to stick only the header line ?
[edit]When i scroll down page Developers/Maintainers the arrays defined with class = tpl-stickytable always stick the header together with first data line. It gives a mess when overwritten by the following lines of the array. How can I exclude the first data line from stick as to keep only the header line sticked ? Thanks. -- 🚨 Christian 🇫🇷 FR (talk) 13:48, 19 May 2026 (UTC)
- Looks as though it's a problem with Template:Import-stickytable as even the example on that page has the same problem. Jonathan3 (talk) 10:44, 20 May 2026 (UTC)
- I think the CSS at Template:Import-stickytable/styles.css is meant to make the header or (if there is no header) the first row sticky, but actually makes both sticky. Jonathan3 (talk) 10:52, 20 May 2026 (UTC)
- do i file a ticket on Phabricator ? -- 🚨 Christian 🇫🇷 FR (talk) 18:04, 23 May 2026 (UTC)
- I think the CSS at Template:Import-stickytable/styles.css is meant to make the header or (if there is no header) the first row sticky, but actually makes both sticky. Jonathan3 (talk) 10:52, 20 May 2026 (UTC)
How to get my user name from Lua ?
[edit]Is it possible to get my user name using Lua? I tried this:
mw.config.get('wgUserName')
but that only returns "attempt to index field 'config' (a nil value)". - Erik Baas (talk) 06:05, 21 May 2026 (UTC)
- It's not, lua is there for wikitext processing, and
mw.configdoesn't even exist there (it's a JS API) Archimedes5000 (talk) 01:53, 22 May 2026 (UTC)- I think there are extensions that could return the current user's username, and I expect you could use one of them via Lua. Jonathan3 (talk) 15:17, 23 May 2026 (UTC)
- You could use Help:Magic words#REVISIONUSER, e.g.
mw.getCurrentFrame():preprocess("{{REVISIONUSER}}"), but you can't get the current reading user because then the rendered wikitext would have to be cached separately for each viewer. Sam Wilson 11:24, 30 May 2026 (UTC)
关于Special:Version/Creadits
[edit]该页面不会随参数设置内“国际化->语言”内的设置更改语言。Pawsdt (talk) 07:57, 22 May 2026 (UTC)
- @Pawsdt: Thanks for reporting this. It looks like the headings on that page are not actually translatable. I've opened phab:T427702 for this. Sam Wilson 06:57, 30 May 2026 (UTC)
Survey (proposed direction for Wishlist)
[edit]You are invited to voice your opinion on a new community-proposed direction for the Community Wishlist. Thank you! MediaWiki message delivery (talk) 03:07, 29 May 2026 (UTC)
Photo Media
[edit]Hi Gramps
Please forgive me in advance as I'm no the brightest globe.
I am investigating media storage in my Gramps database and have found what appears to be inconsistent media file referencing.
My media files are stored under a main FAMILIES directory with surname-based subdirectories. For example:
FAMILIES\KOZUBEK@ File KOZUBEK Erna Clara 1938-1999\Pho KOZUBEK Erna Clara 1938-1999.jpg
Many media records in Gramps correctly reference files using their original directory structure and filenames.
However, some media records reference files using a different structure where the path begins directly with the root media folder in uppercase, for example:
FAMILIES\0122343ecbe74c60c28bf4d68b4561c8.jpg
These files exist in the FAMILIES directory and open correctly, displaying the expected image. The media record is therefore working, but I do not understand why Gramps is referencing a generated filename instead of the original path and folder structure.
I have identified approximately 385 files with similar generated hash-like filenames in the FAMILIES directory.
For example, the media associated with Erna Clara KOZUBEK points to:
FAMILIES\0122343ecbe74c60c28bf4d68b4561c8.jpg
rather than:
Family\KOZUBEK@ File KOZUBEK Erna Clara 1938-1999\Pho KOZUBEK Erna Clara 1938-1999 i0041.jpg
Questions:
1. Is there a recommended method to restore media records to the original directory structure?
Any guidance would be appreciated.
Mark CHARMAN
~2026-32090-74 (talk) 01:27, 30 May 2026 (UTC)
- @~2026-32090-74: You're reporting this on the wrong website, sorry. Gramps uses MediaWiki, but it sounds like your issue is with Gramps itself. Try https://gramps-project.org/wiki/index.php/Using_the_bug_tracker Sam Wilson 05:09, 30 May 2026 (UTC)