Jump to content

Project:Support desk

Add topic
From mediawiki.org
(Redirected from Support desk)
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.

(Read this message in a different language)

See also

Before you post

Post a new question

  1. To help us answer your questions, please indicate which version of MediaWiki you are using, as found on your wiki's Special:Version page:
  2. 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.
  3. 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.
  4. To start a new thread, click the box with the text "Add topic".

Syntax when protecting pages for a non-standard length of time

[edit]

I'm a bureaucrat at Wikispecies and an administrator at Swedish Wikivoyage and Wikimedia Sweden (WMSE). When protecting a page on any of those wikis I'm faced with the option to protect it for a fixed period of time (one week, one month, "infinitely" etc.), but there's also an option to chose "Other time" by entering code into a text box. However, I can't seem to find any information about how this command should be formatted, nor anything about the preferred date format and such. I've looked in Help:Protected pages and similar MediaWiki help pages, but struck no luck. (Most Meta-Wiki pages on the subject simply soft-redirects to MediaWiki). Even though protecting pages is (and should be) a fairly rare event, any help would be much appreciated. –Best regards, Tommy Kronkvist (talk), 19:19, 16 April 2025 (UTC).Reply

I've wondered that too. According to the code, the other time can be 'infinite', 'indefinite', 'infinity', or 'never' to mean infinite, or whatever php's strtotime function accepts (with some qualification that your user timezone is not accounted for). --Clump (talk) 13:57, 1 May 2025 (UTC)Reply
[edit]

On my Miraheze wiki, the Minerva.js settings currently contain this code:

mw.util.addPortletLink('p-navigation', '/wiki/Special:WhatLinksHere/' + mw.config.get( 'wgPageName' ), 'What links here', 'nav-wlh');

However, it should be quickly noted that "What links here" is invalid for pages in the Special namespace themselves; to that end, I'd like to know exactly what wraparound to use for cancelling it out if special pages are visited. Once I receive a tip (from @Bawolff or otherwise), the same procedure will apply for overviews of related changes.

Still, with Good Friday and Easter weekend close at hand, this might take a little while. --Slgrandson (talk) 01:56, 18 April 2025 (UTC)Reply

@Slgrandson I havent tested, but generally an ISO timestamp will likely work yyyy-mm-dd hh:mm:ss —TheDJ (Not WMF) (talkcontribs) 08:16, 21 April 2025 (UTC)Reply
@TheDJ: If so, which part of the calls is the timestamp appended to? --Slgrandson (talk) 20:58, 21 April 2025 (UTC)Reply
Leaving this message up in case anyone else has a better solution. --Slgrandson (talk) 07:43, 5 May 2025 (UTC)Reply

Gadget for auto numeration and Vector-2022

[edit]

Hello, the auto numeration activated with MediaWiki:Gadget-autonum.css and MediaWiki:Gadget-autonum.js (I load them in my global.js) does not work well together with Vector-2022 skin, because the counter reset does not work, and so all lower sections are just counted up. Note, that in vector-2022 only the else tree of the script is active and the code of the CSS is used. If you think, why I do not just ask the author Krinkle – well he wrote almost a year ago “I do not use the autonum gadget myself. For now, I have exceed the time I'm willing to spend on this gadget. I suggest gathering support and awareness of other people in the community, to hopefully find someone who is able and willing to maintain this JS/CSS snippet for further modifications.” (Krinkle’s user talk page on meta, cf. meta:Special:Diff/26715423 or the full conversation at m:Special:PermaLink/26721127#Section autonumeration with Parsoid). As an example: Manual:FAQ (itself not ready for vector-2022, at least the toc part I looked for) has 12 sections, and the latest one has 6 subsections which is fine displayed in (legacy) Vector from 2010, but with Vector 2022 I see the count 12.107. — Speravir (talk) – 00:35, 25 April 2025 (UTC)Reply

Hello sir, I saw your problem. From my investigation, Vector-2022 relies on the CSS-based numbering (the else branch in autonum.js, using autonum.css) when no table of contents (TOC) is present, as per the gadget’s design. The CSS (https://en.wikipedia.org/wiki/MediaWiki:Gadget-autonum.css) uses counter-reset properties, but these seem incompatible with Vector-2022’s DOM structure or styling, possibly due to changes in how headings are rendered (e.g., .mw-headingclasses, per Vector-2022 documentation).
I’m aware that Krinkle, the gadget’s author, noted in 2024 that they no longer maintain this gadget and suggested community collaboration for further fixes (see meta:Special:PermaLink/26721127#Section_autonumeration_with_Parsoid). I’m hoping to gather insights or assistance from others familiar with Vector-2022’s CSS/JS or gadget maintenance. Has anyone encountered similar issues with autonum or other CSS-based numbering gadgets in Vector-2022? Are there known workarounds, such as adjusting the counter-reset selectors to match Vector-2022’s heading structure, or modifying the JS to handle TOC-less pages differently? ProfessorNikolaus (talk) 18:53, 25 April 2025 (UTC)Reply
Your reply reminded me that I had myself written to Krinkle about the issue for pages without toc. I just did not consider now that the new skin has the same section structure in DOM. But because I ask for a change of a page gadget I seem to be wrong in the support desk. I'll ask at the Village Pump, instead, see VP: Gadget for auto numeration and Vector-2022. — Speravir (talk) – 00:16, 29 April 2025 (UTC)Reply

Importing pages from old wiki into newest wiki 8.3.0

[edit]

I want to manually insert all my pages from an old wiki project into a new wiki website (using mediawiki 8.3.0). The database in my new wiki shows pages are stored in "ew7o_page". In my old wiki this was calles "page" What is the best way to export from old wiki and import (insert) in newest wiki ? Same for "pagelinks" : need to be inserted in "ew7o_pagelinks" . When I try this now it's creating a new row in my SQL with the name "page". The "ew7o_page" reamains unchanged.

Stevy7 (talk) 10:14, 27 April 2025 (UTC)Reply

@Stevy7: What do you mean by "mediawiki 8.3.0"? The latest version is MediaWiki 1.43. Oh, or do you mean you're updating from MediaWiki 1.8? That's impressive, if you've still got it running! Can you upgrade to 1.35 and then step through LTS versions since then? Or perhaps export the site's pages as XML (see Manual:DumpBackup.php) and then import in to a fresh install? Sam Wilson 03:31, 1 May 2025 (UTC)Reply

Error messages in SkyWiki wikis

[edit]

Hi, I've reported several error messages on SkyWiki wikis, including phabricator.skywiki.org. I've tracked them as issues in Wikimedia Phabricator (see links to issues at the right of this message), but these issues were all rejected as invalid. How can I contact SkyWiki founder in order to have those bugs fixed? --Agusbou2015 (talk) 18:26, 27 April 2025 (UTC)Reply

SkyWiki, which is already outside Wikimedia's purview/priority/attention, has been lingering in the shadows of Miraheze, Fandom, et al.--but not even Google has the home URL indexed on its first results page as I type! (The top result for "SkyWiki", unquoted, is a Fandom site on an unrelated video game.) Afraid I could say otherwise, but unless you or I are lucky to find their support e-mail or social handle(s), there's nothing else that can be done on the matter. --Slgrandson (talk) 08:08, 29 April 2025 (UTC)Reply
"phabricator.skywiki.org" never existed (you can enter literally any domain like "agusbou2015.skywiki.org" and get the very same error for non-existing sites) thus mentioning non-existing subdomains makes no sense. Phabricator is not some subdomain magically included in every MediaWiki installation to report issues but it is a complete separate piece of software hosted by Wikimedia. Malyacko (talk) 14:41, 1 May 2025 (UTC)Reply

Extensions and skins not working (most of the time)

[edit]

Hi everyone, I am new here, so i might not get everything at first or botch some specialistic MW wording.

Getting to the problem - I appear to have a problem with LESS variables. Many skins are affected, like Vector, Minerva and Timeless, possibly many more (currently only one "working" is Chameleon). The symptoms are: broken CSS, buttons not working, extensions not working (happens in Chameleon too). There are images present, so I don't think that the solution from here applies, but I tried it either way and it does not make a change.

With broken LESS variables comes more problems - when I try to enable extensions like WikiEditor or VisualEditor I get 50kB of console errors with Less_Exception_Compiler saying that @variable_name is not defined (which clearly is defined in mediawiki.skins.defaults.less). It also frequently happens with @cdx_variable_name which i deduce is some codex variable which is not defined in mediawiki.skins.defaults.less, but i don't know how to handle this. It's a shame, but it can be worked around by writing in pure wikicode. Yet, there are problems still (which I didn't find the cause for), thumbnails and frames are not rendering correctly. The image is here, there is a caption, but there is no frame, image is not snapping to the right (if set to |right|), text isn't wrapping around it.

I am wandering if this is something on my hosting server side or with my installation, but I don't really know... I'll get you through installation steps i went through:

  1. download and unpack mediawiki, push it to my host ftp, import php.ini file and make /tmp
  2. run the installation following the tutorial
  3. wiki breaks and sends me a giant list of errors with Less_Exception_Compiler
  4. I download and install Chameleon via Composer (site isn't that broken now)
  5. I download a REL1_43 extension and put it in /extensions/, set (eg) wfLoadExtension( 'VisualEditor' );
  6. I try to edit a page using VE, but nothing is showing, console is red full with errors

So yeah, not much here to be honest... Right now I have almost every important extension disables, because it breaks my site. What can be the cause? What am i doing wrong?

I tried installing the 1.43.0 version, but it gives me the same results.

Nazwa Wersja
MediaWiki 1.43.1
PHP 8.4.0 (uwsgi)
ICU 69.1
MySQL 8.0.33-25
Pygments 2.17.2
Lua 5.1.5

Thanks for help in advance! Astroksiezyc wiki (talk) 01:45, 28 April 2025 (UTC)Reply

(for anyone looking at this, there are some stacktrace screenshots at phab:T392761) ‍—‍a smart kitten[meow] 09:50, 28 April 2025 (UTC)Reply
@Astroksiezyc wiki "download and unpack mediawiki," from where ? git, tarball, your linux distro ? —TheDJ (Not WMF) (talkcontribs) 16:47, 2 May 2025 (UTC)Reply
I just downloaded the file from the MediaWiki download website. Tomorrow I might try to get it directly from git if it would be better.
Do the packages differ in some way? Or maybe am I missing some crucial installation step when downloading from official website? Astroksiezyc wiki (talk) 22:39, 2 May 2025 (UTC)Reply
Ok, I tried dovnloading and installing from git - I added the skins packages, there weren't any present. I get Vector-2022 not working, just breaking the site completely and Chameleon giving me the same errors as before. I just don't know what else can i do Astroksiezyc wiki (talk) 11:42, 5 May 2025 (UTC)Reply

Wikimedia installation repair needed

[edit]

Hello Wikimedians - I'm a non-coder who installed a private Wikimedia wiki on my Go Daddy website, for my own use in organizing local history research. The available installation tools worked fine, and the website worked well until recently, when I got a notice that I needed to upgrade the php. I didn't find any non-coder tools to help me do that, and my efforts have really screwed things up - now I can't even log in. I need someone who knows how to fix the site (for pay, of course). How do I find such a person? WCCasey (talk) 17:41, 29 April 2025 (UTC)Reply

There are some people listed here: Professional development and consulting. Jonathan3 (talk) 19:09, 29 April 2025 (UTC)Reply
@WCCasey: You shouldn't have to be a coder to install and upgrade MediaWiki, although I know that sometimes the process can be a bit tricky. Ideally, we'd make it easier! If you do want to try doing it yourself, you could try posting here describing the issues you're having with the upgrade, and we could try to help. It might not be insurmountable. Sam Wilson 03:11, 30 April 2025 (UTC)Reply

Thanks for pointing me to that list - that's what I was looking for. Also thanks for offering to help me fix things myself. I may be back at some point to try that! WCCasey (talk) 16:20, 1 May 2025 (UTC)Reply

Interwiki issues with vector 2022 for non-languages

[edit]

Dear ∀,

In Vector 2022 I have difficulties with interwiki connections in my local wiki (1.39, ULS activates) as soon as the link happens not to be an ISO language prefix.

In special:interwiki I have defined those interlanguage prefices:

aa https://localhost/mediawiki/index.php/$1 ja nein Bearbeiten, Löschen
en https://en.wikipedia.org/wiki/$1 ja nein Bearbeiten, Löschen
urwiki http://localhost/mediawiki/index.php/$1 ja nein Bearbeiten, Löschen

In Names.php I have defined , as far as my question is concerned, these:

'urwiki' => ' mein Urwiki', # Test für Sprachverknüpfung
'en' => 'English', # English
'aa' => 'Urwiki via aa', # Afar

On my Main Page I added:

[[urwiki:Main Page]][[en:Wikipedia:Village pump]][[aa:Main Page]]

Under vector 2010 I am offered all three links

Under vector 2022, the interwiki popup is flagged with three languages, but if I open the popup, only en and aa are being offered, beside a lot of whitespace.

How can I make mediawiki handle urwiki the same way as ISO prefices?

Thank you in advance!

Yours, Ciciban (talk) 10:49, 30 April 2025 (UTC)Reply

Mediawiki styles not loading after upgrade

[edit]

Hello,

I've been at this for a couple of days now and no online resource could help so far. I upgraded my mediawiki 1.31 to 1.35.14, planning to go to the 1.43. I followed the procedure described in the manual (backed up the db and images folder -> unzipped mw_1.35 tar replaced relevant files -> ran php maintenance/update.php), but after all the steps it seems mw is having issues grabbing the right modules:

Skipped unresolvable module site

Skipped unresolvable module mediawiki.page.startup

Skipped unresolvable module mediawiki.page.ready

Skipped unresolvable module skins.vector.legacy.js

Skipped unresolvable module ext.visualEditor.desktopArticleTarget.init

Skipped unresolvable module ext.visualEditor.targetLoader

There is also this javascript error: Uncaught TypeError: Cannot read properties of undefined (reading 'state')  @https://[redacted].com/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector

And this text in what i assume was suppose to be the css file in sources?

Problematic modules: {"ext.visualEditor.desktopArticleTarget.noscript":"missing","mediawiki.special.version":"missing","skins.vector.styles.legacy":"missing"}

Due to these issues, while the wiki displays my content, there is 0 styling on the website.

I cleared caches, made sure the temp folder is writable, followed the manual for the short url structure (hopefully right), redownloaded the 1.35 Vector skin with no luck, and many others. I also tried activating debug in LocalSettings but that does not show anything on the page.

I would very much appreciate some input if anyone has encountered this before.

Setup:

Product Version MediaWiki 1.35.14

PHP 7.4.33 (apache2handler)

MariaDB 10.11.11-MariaDB-0ubuntu0.24.04.2

ICU 74.2

Entry point URLs

Article path /wiki/$1

Script path /w

index.php /w/index.php

api.php /w/api.php

rest.php /w/rest.php

Thanks in advance. Sorestoreclerk (talk) 08:25, 1 May 2025 (UTC)Reply

ResourceLoader Issue? MediaWiki:Minerva.js not loading/executing (MW 1.43.1, MF 2.4.1)

[edit]

Hello,

I am seeking help diagnosing an issue where JavaScript placed in MediaWiki:Minerva.js is not being loaded or executed in the mobile view (MinervaNeue skin via MobileFrontend). I am new to MediaWiki administration and web development in general and have been heavily assisted by AI (Gemini/ChatGPT) in troubleshooting so far.

Environment:

  • MediaWiki: 1.43.1
  • PHP: 8.1.32 (litespeed)
  • Database: 10.6.21-MariaDB-cll-lve
  • Host: Namecheap Shared Hosting (cPanel, LiteSpeed Web Server)
  • Skin: MinervaNeue (Mobile), Vector 2022 (Desktop)
  • Relevant Extensions: MobileFrontend 2.4.1, UniversalLanguageSelector [2025-03-15 MLEB], Translate [2025-03-15 MLEB] (full list available if needed)
  • Configuration: $wgMFEnableSiteJs = true; added after wfLoadExtension('MobileFrontend'). $wgAllowUserJs is default (true).

Goal: Customize the mobile navigation menu by adding custom links/sections via JavaScript, similar in structure to mariowiki's mobile menu.

Problem & Diagnostics: JavaScript code in MediaWiki:Minerva.js fails to execute.

  1. An initial attempt using simple jQuery .append() did successfully add <li> elements to the menu (targeting #p-navigation), but styling was incorrect(primitive and rugged). I would like the custom links to have the same style as other things in the default menu.
  2. Subsequent attempts using the mw.mobileFrontend.menu.buildLink API failed (no elements added).
  3. Reverting to the simple jQuery .append() code also failed in later tests (no elements added).
  4. Crucial Test: Replacing the entire content of MediaWiki:Minerva.js with only console.log('Test'); results in no output in the F12 browser console when loading the mobile view (after purging cache and hard refreshing).
  5. Network Analysis: Checking the Network tab in F12 Dev Tools (mobile view) confirms that the content of MediaWiki:Minerva.js (the console.log line) is not present in the response body of any relevant load.phprequest. This indicates ResourceLoader is not serving the updated module content.

Troubleshooting Steps Performed (All Ineffective):

  • Confirmed $wgMFEnableSiteJs = true; and $wgAllowUserJs is default (true).
  • Extensive browser cache clearing (hard refresh, incognito mode, multiple browsers).
  • Used ?action=purge on MediaWiki:Minerva.js, MediaWiki:Minerva.css, and main pages.
  • Cleared host-provided CDN cache (Namecheap Supersonic) and LiteSpeed page cache.
  • Attempted to clear server-side PHP OPCache by editing/saving LocalSettings.php (add/remove comment).
  • Checked F12 console repeatedly for relevant JavaScript errors (none found).
  • Checked cPanel error logs for relevant PHP errors (none found).
  • Checked cache/ directory permissions (755) and found it only contains .htaccess (suggesting potential write issues, but unconfirmed).
  • Tested with ?debug=true parameter (no relevant debug output or errors observed).
  • (Note: I am unable to access Phabricator due to an IP block).

Question: Given that MediaWiki:Minerva.js is configured to load ($wgMFEnableSiteJs=true) but is demonstrably not being served by ResourceLoader (load.php), what could be the cause?

  • Is this a known bug in MediaWiki 1.43.1 or MobileFrontend 2.4.1 regarding ResourceLoader module invalidation or loading for MediaWiki:Minerva.js / site.mobile / skins.minerva.site?
  • Are there further steps to debug ResourceLoader module delivery beyond checking the Network response and using ?debug=true?
  • Could this be related to server-side caching mechanisms (OPCache, RL file cache) that resist standard invalidation methods, or a file permission/ownership issue preventing RL cache writes?

Any insights or suggestions would be greatly appreciated. Thank you! Segremost (talk) 12:22, 1 May 2025 (UTC)Reply

Cannot access the database error appearing on wiki

[edit]

MediaWiki Version: 1.36.2

PHP Version: 7.4.33 (litespeed)

Website: https://converter.penguinicewikis.com/mw19/

Hello. I know I may have posted something similar to this before, but I have problems with one of my wikis. When I try to access my wiki, I get a "Cannot access the database" error. And when I try to perform rebuildall.php in SSH, I get a related error. The error may appear on the link to the website above For problems in SSH, this is what the error in the SSH Terminal looked like:

Wikimedia\Rdbms\DBConnectionError from line 1507 of /home/gjlxrtap/public_html/mw19/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Cannot access the database: Unknown error (localhost)

  1. 0 /home/gjlxrtap/public_html/mw19/includes/libs/rdbms/loadbalancer/LoadBalancer.php(995): Wikimedia\Rdbms\LoadBalancer->reportConnectionError()
  2. 1 /home/gjlxrtap/public_html/mw19/includes/libs/rdbms/loadbalancer/LoadBalancer.php(960): Wikimedia\Rdbms\LoadBalancer->getServerConnection(0,'gjlxrtap_mw3455...', 0)
  3. 2 /home/gjlxrtap/public_html/mw19/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1126): Wikimedia\Rdbms\LoadBalancer->getConnection(-1, Array, 'gjlxrtap_mw3455...', 0)
  4. 3 /home/gjlxrtap/public_html/mw19/maintenance/includes/Maintenance.php(1410): Wikimedia\Rdbms\LoadBalancer->getMaintenanceConnectionRef(-1, Array, 'gjlxrtap_mw3455...')
  5. 4 /home/gjlxrtap/public_html/mw19/maintenance/rebuildall.php(44): Maintenance->getDB(-1)
  6. 5 /home/gjlxrtap/public_html/mw19/maintenance/doMaintenance.php(112): RebuildAll->execute()
  7. 6 /home/gjlxrtap/public_html/mw19/maintenance/rebuildall.php(67): require_once('/home/gjlxrtap/...')

Thank you for reading. Newman2 (talk) 14:45, 1 May 2025 (UTC)Reply

@Newman2 There are a few tips in https://www.mediawiki.org/w/index.php?title=Topic:Vgqkw937xxolc0mq&action=history that you may try. —TheDJ (Not WMF) (talkcontribs) 16:29, 2 May 2025 (UTC)Reply
[edit]

My company has an existing wiki that's been around a long time. I'm attempting to get it migrated, upgraded and working (on Windows Server). Original is on MediaWiki 1.18.2, the new one is MediaWiki 1.43.1. Most everything has gone ok with the migration and upgrade. One issue that was discovered is file:// links don't work. Originally, they did nothing when clicking on them. I have since enabled https and added the site to IE compatibility mode in Edge and now the links open saying "access to the file was denied. ...not readable, moved, file permissions." But I can copy/paste the link into a new window and it opens fine (so the file still exists and it's not a permissions issue). Things I've done:

verified $wgUrlProtocols has file: entry

enabled https

added site to local intranet sites, allowed pop-ups, and IE compatibility mode sites

enabled IntranetFileLinksEnabled policy locally

I've done a lot of researching on the internet trying any possible fix I could find. Any other ideas of things to try?

If the files do need to be moved local to the MediaWiki server and linked to there, is there an easy way to update all existing links?

Twittgo (talk) 18:36, 1 May 2025 (UTC)Reply

This might be a browser issue and not a mediawiki issue. Browsers are much more strict now a days about file links. Bawolff (talk) 05:41, 4 May 2025 (UTC)Reply

upgrade process

[edit]

Hi - we recently took over the mediawiki server and it is running version 1.19.23. I would like to know what would be the ideal way to bring it tot he latest version. 128.249.96.18 22:07, 1 May 2025 (UTC)Reply

There's some guidance about which version to upgrade to first at Manual:Upgrading#Check_requirements. Jonathan3 (talk) 13:52, 2 May 2025 (UTC)Reply

Some images not showing after Upgrade from 1.31 to 1.43

[edit]

I found several tickets to this problem, but the most common solution (run cleanupUsersWithNoId.php and migrateActors.php) is no longer applicable with 1.43 as both scripts are deceprated and removed.

Background: I upgraded from an old LTS (1.31) to the latest LTS with 1.35 as gap version. Exactly as stated on the upgrade page. And at first glance, everything was fine. But then, there are some images which are not there. They still have their description page and history, they're on the webserver, I can find them in the image folder, they have the same permission und owner as all the other images. The missing images also doesn't come from the same folder, as one is from e/e1 and another from 6/67, at the same time other images from these folders are displayed.

I already tried checkImages.php and rebuildImages.php with no luck. And after reading the other tickets to this topic, I'm afraid I have to manually reupload each missing image myself :s --91.42.74.217 18:57, 2 May 2025 (UTC)Reply

EDIT: Here is the link to the affected wiki and one of the example images, which are no longer displayed but still on my server: memory-alpha.wiki/wiki/Datei:Odo_2372.jpg. RebuildImages.php didn't help either. --80.128.152.128 19:18, 4 May 2025 (UTC)Reply

EDIT2: I have tried nearly all maintenance scripts at this point. importImages.php gives me the error "Importing XY.jpg...failed. (at recordUpload stage)". rebuildImages.php says that it did *something* but nothing actually happens. refreshFileHeaders.php makes nothing. Even manually uploading the image in my wiki via the webinterface doesn't work because, surprise, it recognize that its a duplicate. So my wiki knows that there are images, but it simply won't display it? Why? What happend between 1.31 and 1.43? (or 1.31 and 1.35 or 1.35 and 1.43?) 91.42.80.200 20:36, 7 May 2025 (UTC)Reply

"Odo 2372.jpg" has an md5sum of da49172cdaabe195c0a9d6b2c446b159, meaning that it should be located in this the directory https://memory-alpha.wiki/mediawiki/images/d/da/ which it clearly is not. So either the webserver doesn't have the right permissions on that file, in case it DOES exist locally (so then fix the permissions), or it is actually gone. That doesn't seem an upgrade issue, though it is possible that while upgrading you made a mistake with copying or something, that caused it to be lost. —TheDJ (Not WMF) (talkcontribs) 09:10, 8 May 2025 (UTC)Reply
"Odo_2372.jpg" (underscore instead of space) has a hash of 6992464c461e737fd03d1652cde1622b though and is located in the directory matching that hash: memory-alpha.wiki/mediawiki/images/6/69/Odo_2372.jpg. --2A02:2455:812B:BA00:F238:C7D9:4B56:36B6 10:02, 8 May 2025 (UTC)Reply
Yes exaclty, and this was also its position in the original image-folder pre-upgrade... Nearly half of all my images (mostly uploaded by users, which don't exist in my database due to the fact I imported the whole wiki back in 2018) are not there anymore. 87.157.182.103 21:05, 8 May 2025 (UTC)Reply

EDIT3: Ok, I go in full error mode. A secound try, where I carefully watched the output of both upgrade.php runs (1.35 and 1.43) revealed a missing cleanupUsersWithNoId.php run in 1.35, but even with that the exact same images are missing in 1.43. 91.42.65.179 07:30, 11 May 2025 (UTC)Reply

SOLUTION!! The error is within the image table! For the missing images, the img_actor field was 0. To correct the error, it only needs to be changed using UPDATE <wiki>image SET img_actor="3" WHERE img_actor="0";. The new value of img_actor must be any existing actor (e.g. the wiki creator is 1). Now ALL my images are back! And this is the solution to a years old problem! 91.42.65.179 19:52, 11 May 2025 (UTC)Reply

Convert timestamp to human-readable text?

[edit]

E.g. 20250511195252 to 11/05/2025? (but for any timestamp, not just revision timestamp) MouseCursor (talk) 16:28, 3 May 2025 (UTC)Reply

Does the #time function from Extension:ParserFunctions extension work? e.g. {{#time:d/m/y|20250504053801}} = 04/05/25 Bawolff (talk) 05:40, 4 May 2025 (UTC)Reply

what is the rule to translate EN strings generated by Lua modules ?

[edit]

Hi all, when a translated page calls a template which invokes a Lua Module, and this module generates strings, what is the rule for the Lua strings to be translated and appear on the calling page ? Should the Lua Module be derived in as many languages as pages (only its /doc has extensions /xx) ? We should have similar translated units as for pages. I am a bit confused seeing hardcoded EN strings provided by these modules present in the translated pages. Any idea ? .... Thanks -- Christian 🇫🇷 FR 🚨 (talk) 18:59, 4 May 2025 (UTC)Reply

Upgrade and unrecognized models

[edit]

Hello, I upgraded my two Wikis from MediaWiki 1.25 to 1.43.1. But not all templates are recognized.

For example:

New Wiki: https://www.europe-politique.eu/wiki/Groupe_de_l%27Alliance_radicale_europ%C3%A9enne_(ARE)

Old Wiki: https://web.archive.org/web/20241015200119/https://www.europe-politique.eu/wiki/Groupe_de_l'Alliance_radicale_europ%C3%A9enne_(ARE)

Thank you very much for WikiMedia and for your help! Lo2b (talk) 10:45, 5 May 2025 (UTC) 46.30.204.3 13:51, 5 May 2025 (UTC)Reply

As far as I can tell, you are missing at least one extension; #expr and #switch are parser functions (not templates) from the ParserFunctions extension, which you should download and install if you want to make use of them. Hope that helps. Cavila 18:03, 5 May 2025 (UTC)Reply
Many thanks @Cavila : it works perfectly !
Have a nice day !
~~~~ 2A01:CB04:5EC:D400:1CA2:FF3E:95EB:3AE5 18:52, 5 May 2025 (UTC)Reply
Sorry, I was not logged... Lo2b (talk) 18:54, 5 May 2025 (UTC)Reply

Database Error: too many connections?

[edit]

Title says it all. How is this even possible? And how can I stop this from happening?

MediaWiki internal error. Wikimedia\Rdbms\DBConnectionError: Cannot access the database: Too many connections (localhost)
Backtrace:
from /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1129)
#0 /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(796): Wikimedia\Rdbms\LoadBalancer->reportConnectionError()
#1 /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(784): Wikimedia\Rdbms\LoadBalancer->getServerConnection()
#2 /var/lib/mediawiki/includes/libs/rdbms/database/DBConnRef.php(107): Wikimedia\Rdbms\LoadBalancer->getConnectionInternal()
#3 /var/lib/mediawiki/includes/libs/rdbms/database/DBConnRef.php(125): Wikimedia\Rdbms\DBConnRef->ensureConnection()
#4 /var/lib/mediawiki/includes/libs/rdbms/database/DBConnRef.php(338): Wikimedia\Rdbms\DBConnRef->__call()
#5 /var/lib/mediawiki/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(762): Wikimedia\Rdbms\DBConnRef->selectField()
#6 /var/lib/mediawiki/includes/language/LCStoreDB.php(65): Wikimedia\Rdbms\SelectQueryBuilder->fetchField()
#7 /var/lib/mediawiki/includes/language/LocalisationCache.php(566): LCStoreDB->get()
#8 /var/lib/mediawiki/includes/language/LocalisationCache.php(612): LocalisationCache->isExpired()
#9 /var/lib/mediawiki/includes/language/LocalisationCache.php(523): LocalisationCache->initLanguage()
#10 /var/lib/mediawiki/includes/language/LocalisationCache.php(403): LocalisationCache->loadSubitem()
#11 /var/lib/mediawiki/includes/language/LocalisationCache.php(419): LocalisationCache->getSubitem()
#12 /var/lib/mediawiki/includes/language/MessageCache.php(1267): LocalisationCache->getSubitemWithSource()
#13 /var/lib/mediawiki/includes/language/MessageCache.php(1209): MessageCache->getMessageForLang()
#14 /var/lib/mediawiki/includes/language/MessageCache.php(1103): MessageCache->getMessageFromFallbackChain()
#15 /var/lib/mediawiki/includes/Message/Message.php(1554): MessageCache->get()
#16 /var/lib/mediawiki/includes/Message/Message.php(1036): MediaWiki\Message\Message->fetchMessage()
#17 /var/lib/mediawiki/includes/Message/Message.php(1127): MediaWiki\Message\Message->format()
#18 /var/lib/mediawiki/includes/exception/MWExceptionRenderer.php(253): MediaWiki\Message\Message->text()
#19 /var/lib/mediawiki/includes/exception/MWExceptionRenderer.php(399): MWExceptionRenderer::msg()
#20 /var/lib/mediawiki/includes/exception/MWExceptionRenderer.php(107): MWExceptionRenderer::reportOutageHTML()
#21 /var/lib/mediawiki/includes/exception/MWExceptionHandler.php(135): MWExceptionRenderer::output()
#22 /var/lib/mediawiki/includes/exception/MWExceptionHandler.php(239): MWExceptionHandler::report()
#23 /var/lib/mediawiki/includes/MediaWikiEntryPoint.php(222): MWExceptionHandler::handleException()
#24 /var/lib/mediawiki/includes/actions/ActionEntryPoint.php(82): MediaWiki\MediaWikiEntryPoint->handleTopLevelError()
#25 /var/lib/mediawiki/includes/MediaWikiEntryPoint.php(206): MediaWiki\Actions\ActionEntryPoint->handleTopLevelError()
#26 /var/lib/mediawiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#27 {main} 87.157.190.62 20:47, 5 May 2025 (UTC)Reply
Maybe just upgrade your server and/or check your access logs and see whether you should block any IP ranges. Jonathan3 (talk) 22:09, 5 May 2025 (UTC)Reply
Update: This was kind of an embarrassing problem. On the one side was a straggler "CACHE_ANYTHING" at the end of my LocalSettings (must be there for ages and a copy error) and on the other was my storage full, so that the database couldn't finish its objectcache-tasks, which caused 152 sleeping tasks... I deleted the wrong cache option and some old backups, restarted the database and now everything seems fine again. But yes... I should really give my old lady a bigger harddrive. 91.42.82.112 20:43, 6 May 2025 (UTC)Reply

We will be enabling the new Charts extension on your wiki soon!

[edit]

(Apologies for posting in English)

Hi all! We have good news to share regarding the ongoing problem with graphs and charts affecting all wikis that use them.

As you probably know, the old Graph extension was disabled in 2023 due to security reasons. We’ve worked in these two years to find a solution that could replace the old extension, and provide a safer and better solution to users who wanted to showcase graphs and charts in their articles. We therefore developed the Charts extension, which will be replacing the old Graph extension and potentially also the EasyTimeline extension.

After successfully deploying the extension on Italian, Swedish, and Hebrew Wikipedia, as well as on MediaWiki.org, as part of a pilot phase, we are now happy to announce that we are moving forward with the next phase of deployment, which will also include your wiki.

The deployment will happen in batches, and will start from May 6. Please, consult our page on MediaWiki.org to discover when the new Charts extension will be deployed on your wiki. You can also consult the documentation about the extension on MediaWiki.org.

If you have questions, need clarifications, or just want to express your opinion about it, please refer to the project’s talk page on Mediawiki.org, or ping me directly under this thread. If you encounter issues using Charts once it gets enabled on your wiki, please report it on the talk page or at Phabricator.

Thank you in advance! -- User:Sannita (WMF) (talk) 15:07, 6 May 2025 (UTC)Reply

Full images not showing when wiki is accessed from domain

[edit]

I have encountered an issue with displaying original versions of image files when I access my wiki site through a domain, e.g. wiki.mydomain.com. It looks like the page attempts to load the file from my wiki's local IP address, in this case 192.168.1.196. When site is accessed through mentioned IP directly, images work without issues. I have setup wiki behind an nginx proxy, if that is a factor in troubleshooting the issue.

Error message received after image thumbnail is clicked:

There seems to be a technical issue. You can retry if it persists. Error: could not load image from http:// 192.168.1.196/mediawiki/images/9/95/Test_image.jpg

Wiki version information:

MediaWiki 1.41.1
PHP 8.3.6 (apache2handler)
ICU 74.2
MariaDB 10.11.11-MariaDB-0ubuntu0.24.04.2

Eetu1990 (talk) 10:20, 7 May 2025 (UTC)Reply

Custom colour scheme set in css randomly switches on and off

[edit]

My wiki (https://cyberpedia.miraheze.org/wiki/Main_Page) has a custom colour scheme, however most of the time the custom colour scheme is not used, expect for a few things like links. The colour scheme is set via https://cyberpedia.miraheze.org/wiki/MediaWiki:Common.css and https://cyberpedia.miraheze.org/wiki/MediaWiki:Vector.css. Occasionally the custom colour scheme is used, however only for a couple of hours at a time before going back to the non-custom colour scheme. I have asked about this elsewhere and the only response I've got is that I might need to use CSS containers in some undefined way, or that it might have something to do with mobile skins despite me being on desktop. Eldomtom2 (talk) 21:20, 8 May 2025 (UTC)Reply

Hidden Namespace pages

[edit]

Hello,

I would like to block unregistered users from reading TALK pages, VIEW SOURCE pages, VIEW HISTORY pages, TEMPLATE pages and SPECIAL pages + the page Pages_spéciales

I've tried this, but it doesn't always work:


wfLoadExtension( 'Lockdown' );

$wgActionLockdown['history'] = [ 'user' ]; // seems OK

$wgActionLockdown['TalkPage'] = [ 'user' ]; // seems OK

$wgActionLockdown['SpecialPages'] = [ 'user' ]; // not OK

$wgNamespacePermissionLockdown[NS_TALK]['read'] = [ 'user' ]; // seems OK

$wgNamespacePermissionLockdown[NS_TEMPLATE]['read'] = [ 'user' ]; // seems OK

$wgNamespacePermissionLockdown[NS_TEMPLATE_TALK]['read'] = [ 'user' ]; // seems OK

$wgNamespacePermissionLockdown[NS_SPECIAL]['read'] = [ 'user' ]; // not OK


Can you help me, please?

https://www.europe-politique.eu/wiki/

Produit Version
MediaWiki 1.43.1
PHP 8.4.5 (fpm-fcgi)
ICU 63.1
MySQL 8.0.41-32

Lo2b (talk) 21:33, 8 May 2025 (UTC)Reply

I've never used [[Extension:Lockdown] but it looks as though $wgActionLockdown relates to actions (Manual:Parameters_to_index.php#Actions) and "SpecialPages" isn't one. Neither is "TalkPage".
Maybe try -1 instead of NS_SPECIAL? Maybe $wgNamespacePermissionLockdown just doesn't work for special pages. Also the existence of $wgSpecialPageLockdown makes me think you might have to use that for all special pages individually. Jonathan3 (talk) 13:49, 9 May 2025 (UTC)Reply

PDF's and Word docs rejected in my upload?

[edit]

I tied to upload an historica Survey Journal to Wikimedia Commons first in PDF format and that was rejected after I went through all the steps to support and document it, and then I uploaded it in Word format and that was rejected because the newer Word format was not acceptable. What is left? How do I upload this important historical item? NoelSherry (talk) 02:13, 11 May 2025 (UTC)Reply

c:Commons:File types#Textual formats should be relevant, in particular the last paragraph. Otherwise you should ask their Help desk instead, as this is related to Commons' configuration and policies and not to MediaWiki itself. The frontpage there already gives some pointers on where to look for answers. Tactica (talk) 16:47, 11 May 2025 (UTC)Reply