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

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

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)

Hiding special-page links in Minerva.js

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)

@Slgrandson I havent tested, but generally an ISO timestamp will likely work yyyy-mm-dd hh:mm:ss —TheDJ (Not WMF) (talk • contribs) 08:16, 21 April 2025 (UTC)

@TheDJ: If so, which part of the calls is the timestamp appended to? --Slgrandson (talk) 20:58, 21 April 2025 (UTC)

Leaving this message up in case anyone else has a better solution. --Slgrandson (talk) 07:43, 5 May 2025 (UTC)

Error messages in SkyWiki wikis

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)

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)

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

Extensions and skins not working (most of the time)

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.

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

(for anyone looking at this, there are some stacktrace screenshots at phab:T392761) ‍—‍a smart kitten_[meow] 09:50, 28 April 2025 (UTC)

@Astroksiezyc wiki "download and unpack mediawiki," from where ? git, tarball, your linux distro ? —TheDJ (Not WMF) (talk • contribs) 16:47, 2 May 2025 (UTC)

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)

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)

Wikimedia installation repair needed

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)

There are some people listed here: Professional development and consulting. Jonathan3 (talk) 19:09, 29 April 2025 (UTC)

@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)

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)

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

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)

Cannot access the database error appearing on wiki

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)

@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) (talk • contribs) 16:29, 2 May 2025 (UTC)

file:// links after upgrading

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)

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)

upgrade process

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)

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

Some images not showing after Upgrade from 1.31 to 1.43

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)

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)

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)

"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) (talk • contribs) 09:10, 8 May 2025 (UTC)

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

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)

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)

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)

Convert timestamp to human-readable text?

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

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)

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

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)

Upgrade and unrecognized models

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)

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)

Many thanks @Cavila : it works perfectly !

Have a nice day !

~~~~ 2A01:CB04:5EC:D400:1CA2:FF3E:95EB:3AE5 18:52, 5 May 2025 (UTC)

Sorry, I was not logged... Lo2b (talk) 18:54, 5 May 2025 (UTC)

Database Error: too many connections?

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)

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)

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)

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

(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)

Full images not showing when wiki is accessed from domain

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:

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

Custom colour scheme set in css randomly switches on and off

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)

Hidden Namespace pages

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/

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

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)

PDF's and Word docs rejected in my upload?

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)

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)

Scribunto/Lua Internal Error, Signal 11

This Scribunto extension is not working for me at all. First I tried hosting locally on Laragon. The Lua binary failures trying to run under WAMP flavors are legendary discussions. Then I have tried several installs of MediaWiki in versions 1.39 and 1.43 on my InMotion Hosting VPS. Every setting anywhere has been configured over and over again with the prevailing wisdom available. Nothing makes much difference, and unlike any of the other Lua errors (1, 2, 126, 127), signal 11 leaves no trace in the log. Just for fun I have created circumstances to cause those former error codes to be logged--they were. Also $showexceptiondetails reveals nothing extra to see.

I simply do not understand why this will not work properly. Even attempts to create simple module invoke scripts like 'Hello' get caught by the editor emulator when trying to save. The site is up and running, and is purposed to accomplish BOLD edits and new namespace content for inclusion into Wikipedia. At the bottom of the landing page are links that deliver phpinfo and system version info. Any thoughts?

The site is located at PT Wikitor Sandbox. There is one active article listed (using a WP Info_Person box), and demonstrates the Lua failure upon on calling up the person Infobox.

A list of things I have done, and all MediaWiki and PHPinfo report pages is here: https://ae1pt.com/wikitor/index.php?title=Actions_Taken_to_Date

Pragmatist (talk) 15:33, 12 May 2025 (UTC)

Restrict access to certain types of resource-intensive requests

Hi everyone. I don't generally mind even malicious bots scanning my wiki, I rather accept a few overzealous ones rather than over-block IP adresses etc. However, I see spikes of bot traffic that call very very odd and specific URL parameter requests, and those appear to be calling version diffs, certain timespans of related changes etc, in short, requests that (even for human users) often take more than a second or two, and are more resource intensive database calls than just accessing regular sites or more common requests (that are served via several layers of caching). Is there a way to restrict use of such specific requests to logged in users only? I see absolutely no value in having bots crawl these things.

Here are some example requests (seeing hundreds per minute - this is copy and paste not all of this may be malignant):

(as you can see, some things keep re-appearing such as limits, recentchangeslinked, "from" and "days" etc. Honestly, knowing the very limited number of my editors and my wiki, these are not humans accessing these sites. And that's just a snapshot. Help is much appreciated. These do not pop up in the firewall or security software of my server so they must be fairly "regular" bots, but they just get a bit too active...

Rebastion2 (talk) 17:23, 13 May 2025 (UTC)

trying extension:lockdown with

$wgActionLockdown['history'] = ['user'];

$wgSpecialPageLockdown['Whatlinkshere'] = [ 'user' ];

$wgSpecialPageLockdown['Recentchangeslinked'] = [ 'user' ];

see if that does anything... but the way these URLs are directly called... not sure if I am messing around a step too deep Rebastion2 (talk) 17:53, 13 May 2025 (UTC)

OK I found Externsion:Lockdown and Externsion:DisableSpedialPages to theoretically lock these down, but the way they are called (via url paramters, not directly) I think makes these moot, plus, of course it doesnt stop these before php kicks in, so maybe the only thing that will really help me is buy Cloudflare? Rebastion2 (talk) 20:42, 14 May 2025 (UTC)

testing as an anonymous user, the lockdown works even for the URL parameters the bots use, but alas, the sheer amount of bot requests just does it.... too bad Rebastion2 (talk) 20:55, 14 May 2025 (UTC)

School-wide database for Google Drive users?

Hi - thank you for giving me your time. I've browsed the guides but don't have the answer . We have a small non-profit school that uses Google drive and Gmail for all of our business. We'd like to incorporate a private wiki so that we can have/share/look up resources by anyone here, present and future. Is there a way to do this with this platform? Can we host a version in Google Drive somehow, accessible by anyone with our @davincisv.org emails? Or am I barking up the wrong tree with WikiMedia? 2603:3024:151B:9200:B019:92C4:2597:8F80 18:12, 14 May 2025 (UTC)

Mediawiki upgrade path

Hello! I am new to media wiki and I am looking for some assistance in identifying the proper upgrade path for our companies implementation of MW. They are running a very old version (1.17.0) on a Centos 6.10 VM with Apache 2.2.15 and PHP 5.3.3. I need to migrate the implementation to a VM running Ubuntu 22.04 and would really appreciate some guidance on an upgrade path. Please let me know if you need any additional information. I apologize if this information has already been identified on this site, I was unable to locate it. Thanks in advance! Sleepinfire (talk) 12:53, 15 May 2025 (UTC)

See Manual:Upgrading#Frequently_asked_questions. Basically you have to upgrade to 1.35, then to 1.39, and lastly to 1.43. Tactica (talk) 17:44, 15 May 2025 (UTC)