Project:Support desk

My previous attempt to solve an issue with my wiki made some progress and fixed a few errors, but turned up a new one: "Lua error: bad argument #1 to "get" (not a valid title)." The suggestions in the related threads I found (1, 2) mention "JsonConfig", but I've enabled both "JsonConfig" and "JsonConfigLuaSupport" in LocalSettings and have installed the "REL1_43" (1.2.0) version of the former and the error remains. The following is the backtrace:

1. (tail call): ?
2. [C]: in function "error"
3. MWServer.lua:81: ?
4. (tail call): ?
5. (tail call): ?
6. Module:TNT:162 : in function "loadData"
7. Module:TNT:181 : ?
8. (tail call): ?
9. (tail call): ?
10. Module:Uses_TemplateStyles:21 : in function "renderBox"
11. Module:Uses_TemplateStyles:111 : ?
12. (tail call): ?
13. mw.lua:527: ?
14. (tail call): ?
15. [C]: in function "xpcall"
16. MWServer.lua:99: in function "handleCall"
17. MWServer.lua:313: in function "dispatch"
18. MWServer.lua:52: in function "execute"
19. mw_main.lua:7: in main chunk
20. [C]: ?

Any idea what to do to solve this? –Noha307 (talk) 23:44, 6 October 2025 (UTC) Reply

I tried creating a file named "CommonSettings.php" in the "public_html/w" folder and copy-pasting the code from a page on phabricator into it and adding either "require_once("public_html/w/CommonSettings.php");" or "require_once("CommonSettings.php");" to "LocalSettings.php" based on the instructions on Manual:CommonSettings.php, but it didn't work. –Noha307 (talk) 04:11, 20 October 2025 (UTC) Reply

@Noha307: If you aren't aware of it yet, you might have a look at your site's Category:Pages with script errors page since it collects where Lua errors appear.

For example, it lists this page which points to a missing extension, TitleBlacklist, that may help you resolve part of the problem. -- ☠MarkAHershberger ☢(talk)☣ 14:09, 21 October 2025 (UTC) Reply

I'm suffering from the exact same lue error/backtrace message. I also required TitleBlacklist - which I enabled and fixed it's associated error message - but this hasn't fixed the inital Lua error: bad argument #1 to "get" (not a valid title) error. @Noha307, have you been able to fix the issue? ~2025-30174-48 (talk) 22:17, 26 October 2025 (UTC) Reply

@~2025-30174-48 I did the same – download and enable TitleBlacklist – and it didn't fix the Lua error either. I haven't had a chance to browse the pages with script errors category in detail yet though. Would it be possible for you to link to your wiki so I could compare? –Noha307 (talk) 23:56, 26 October 2025 (UTC) Reply

My wiki looked the exact same as yours with the same errors and backtraces - I've solved the issue by fixing the Json extension config in my LocalSettings.

I changed it to the code below from another support thread on here and the error is resolved:

// Safety: before extension.json, these values were initialized by JsonConfig.php if ( !isset( $wgJsonConfigModels ) ) { $wgJsonConfigModels = []; } if ( !isset( $wgJsonConfigs ) ) { $wgJsonConfigs = []; } $wgJsonConfigEnableLuaSupport = true; // https://www.mediawiki.org/wiki/Extension:JsonConfig#Configuration $wgJsonConfigModels['Tabular.JsonConfig'] = 'JsonConfig\JCTabularContent'; $wgJsonConfigs['Tabular.JsonConfig'] = [ 'namespace' => 486, 'nsName' => 'Data', // page name must end in ".tab", and contain at least one symbol 'pattern' => '/.\.tab$/', 'license' => 'CC0-1.0', 'isLocal' => false, ]; // Enable Tabular data namespace on Commons - T148745 $wgJsonConfigInterwikiPrefix = 'commons'; $wgJsonConfigs['Tabular.JsonConfig']['remote'] = [ 'url' => 'https://commons.wikimedia.org/w/api.php' ]; ~2025-30174-48 (talk) 20:56, 27 October 2025 (UTC) Reply

@~2025-30174-48: Thank you so much! Adding that code seems to have fixed it – or at least the most immediate error anyway. I particularly appreciate you specifying which file it goes in as well.

I'm still getting a "the time allocated for running scripts has expired" error after the reflist template loads 66 references, but at least its getting to that point now. –Noha307 (talk) 03:56, 2 November 2025 (UTC) Reply

┌───────────────────────┘
So, according to one thread, I need to change max execution time, which can be found in php.ini. (Although I am suspicious because it seems like it shouldn't take that long to load 66 references. Could there be another cause, such as a missing template or extension that could prolong it?) However, a different page seems to suggest that the change can be made to LocalSettings.php. While I do know where the latter file is, I don't how I should change it. What code do I need to add? –Noha307 (talk) 01:24, 3 November 2025 (UTC) Reply

Hello, I would like to make the sidebar in Vector 2022 visible to all users by default. Right now, it's hidden from anonymous users. How can I change that? Adding $wgVectorDefaultSidebarVisibleForAnonymousUser = true; or $wgVectorFeatures = array( 'collapsiblenav' => array( 'global' => false, 'user' => false) ); to LocalSettings.php doesn't seem to work for me; neither does adding #sidebar {display: block !important;} to Common.css seem to work. Any ideas? Thanks, cheers and all the best! Till Kraemer (talk) 16:07, 17 October 2025 (UTC) Reply

@Till Kraemer, I think you want to look at Menu Pinning Options. I'm not sure where you got the idea for $wgVectorDefaultSidebarVisibleForAnonymousUser from since that isn't anywhere on this site. --☠MarkAHershberger ☢(talk)☣ 01:34, 20 October 2025 (UTC) Reply

@MarkAHershberger, thank you for your reply! Hmm, it looks like the menu pinning options only affect logged-in users, though, and are already set the way I want them by default. I'm looking for an option to show the menus exactly the same way to anonymous users who aren't logged in. I've found the $wgVectorDefaultSidebarVisibleForAnonymousUser setting on Google and apparently it worked for some people one point in time; the AI Overview still suggests to use that setting, but it doesn't work for me. Till Kraemer (talk) 12:17, 20 October 2025 (UTC) Reply

@Till_Kraemer ALWAYS double-check anything the AI Overview gives you (especially as long as it is using a large language model with generative AI—those things are notorious for making up stuff). Especially if it doesn't work, look to make sure it is actually a thing.

$wgVectorDefaultSidebarVisibleForAnonymousUser cannot be found on mediawiki.org (search) and the only reference I can find to it in code search seems spurious (and may be the source of Google's hallucination).

Tracked in Phabricator
Task T366999

With regards to the menu pinning options, I admit I did not test it when I first mentioned it to you, but I just tried setting $wgDefaultUserOptions['vector-appearance-pinned'] = 0; on a site that I had and that menu disappeared. The other options do not appear to work, though. I feel like this is a bug, though, so I've filed one (which was then closed as a duplicate of task T366999). --☠MarkAHershberger ☢(talk)☣ 00:39, 21 October 2025 (UTC) Reply

@MarkAHershberger: Thanks for pointing out that old config variable, I'm removing it from wikispore-config. It was removed from Vector in Gerrit change 904204. Sam Wilson 00:57, 21 October 2025 (UTC) Reply

@MarkAHershberger, thank you so much for your research, the testing and the bug report! It would be so cool to have those options working. In the meantime, there might be a workaround with CSS, but I can't get that to work either, so I just wait for the bug fix. Till Kraemer (talk) 09:55, 21 October 2025 (UTC) Reply

Since settings like $wgDefaultUserOptions['vector-main-menu-pinned'] = 1; currently don't seem to have any effect on anonymous users, is there another way to achieve the default pinned menu state, like on https://sanat.csc.fi/ - maybe via MediaWiki:Common.js? Till Kraemer (talk) 21:31, 2 November 2025 (UTC) Reply

PS: It seems to be that code. Till Kraemer (talk) 07:30, 3 November 2025 (UTC) Reply

I took the liberty of adding this approach to the menu pinning options. Till Kraemer (talk) 08:15, 3 November 2025 (UTC) Reply

Can anyone recommend good settings for Cloudflare? It's mentioned on Manual:Cloudflare#Cache_control but in a very stream-of-consciousness way, or like a conversation that ended before anything got resolved. Thanks.

Also, what about Manual:$wgMainCacheType and the other related variables? Jonathan3 (talk) 13:48, 24 October 2025 (UTC) Reply

@Jonathan3: The caching variables handle caching on the server and speed up the production of the web page. Generally, this is separate from what a CDN like Cloudflare does. For CDN information, you may find the settings in the (legacy-named) Squid variables category helpful. -- ☠MarkAHershberger ☢(talk)☣ 17:44, 24 October 2025 (UTC) Reply

Thank you for that. I won't change any of the caching variables.

Are there any recommended settings on the Cloudflare end, or are their defaults all right?

(削除) I've noticed that a new version of a file doesn't get shown on the wiki File: page immediately, but clearing the cache of that URL via the Cloudflare website worked. Is there a stable extension that would do that automatically? (削除ここまで) [moved this question to its own topic] Jonathan3 (talk) 23:06, 24 October 2025 (UTC) Reply

P.S. I get the impression, admittedly from limited experience and research, that MediaWiki sites are getting hammered by AI crawlers more than most - presumably because we all have such useful information! If that is true, and as Cloudflare does seem to be a very effective answer, it would be great if some "official" thought was put into improving the Manual:Cloudflare page and the recommendations there. Jonathan3 (talk) 23:08, 24 October 2025 (UTC) Reply

Hello, my wiki has been very slow lately. In Cloudflare, I set "Block AI training bots" to "Block on all pages" and activated "Instruct AI bot traffic with robots.txt". Now the wiki is faster again, so I can recommend those settings - I hope Skynet won't be mad at me though ;) Cheers and all the best! Till Kraemer (talk) 11:17, 27 October 2025 (UTC) Reply

I agree that improving Manual:Cloudflare is good idea, but unfortunately that will mostly fall on people who are using Cloudflare. I very much would encourage people to document their experiences and update documentation for situations like this, that are not setups generally used by Wikimedia and MediaWiki developers. Please do not hesitate to edit documentation pages. —TheDJ (Not WMF) (talk • contribs) 14:56, 27 October 2025 (UTC) Reply

Is there any way to control (per page) how the TOC numbers sections? Specifically I would like it to start at 0 or not assign a number. Ham Pastrami (talk) 13:53, 30 October 2025 (UTC) Reply

@Ham Pastrami See Manual:Table of contents Malyacko (talk) 14:48, 30 October 2025 (UTC) Reply

Hello, On the https://joinfediverse.wiki (running MW 1.41.0) we'd like to completely turn off open registrations and only allow registrations with an individual invite-link.
Is that somehow possible and could you point me to the right way forward?
Thanks. PKFP (talk) 15:09, 30 October 2025 (UTC) Reply

@PKFP Set the user rights to disable creating accounts by everyone except admins (which you should be part of). Then you can use Special:CreateAccount when you want to add someone to the wiki - they'll be sent their invitation (such as temp password) by email. Leaderboard (talk) 05:31, 5 November 2025 (UTC) Reply

Thanks. That was easy. Seems to work fine. This topic can be closed. PKFP (talk) 04:54, 7 November 2025 (UTC) Reply

Also read Manual:Preventing access. – Ammarpad (talk) 14:56, 6 November 2025 (UTC) Reply

I've noticed that a new version of a file doesn't get shown on the wiki File: page immediately, but clearing the cache of that URL via the Cloudflare website worked. Is there a stable extension that would do that automatically? (Moved this question from within another section above.) Jonathan3 (talk) 15:34, 31 October 2025 (UTC) Reply

Hi! I've recently installed https://wiki.lilypond.community, a wiki for the LilyPond music typesetter (which is used on Wikipedia through Extension:Score). Pages consist of small snippets of LilyPond code, with explanatory comments and an image of the result. Is there any way to make the lists of search results (e.g., this) display these images? This would be very helpful for users to quickly finding snippets when they don't know the proper keywords. Jean Abou Samra (talk) 16:35, 31 October 2025 (UTC) Reply

LS,

Version 1.44

In a page I made a call to a template called {{Piup | 9} This template looks like:

{{#switch: {{lc:{{{status|Unknown}}}}}</br>
| Unknown = {{=}}Pi Updaten= <!insert Header1 --></br>
| 2 = {{=}}{{=}}Pi Updaten== <!insert Header1 --></br>
| 9 = '''Uw PI updaten/upgraden''' <!insert Header in bold text --></br>
}}</br>

But it returns nothing to the caling page. So questiom, am I missing something and if so what???

Regards Harry Gharryh1957 (talk) 22:18, 2 November 2025 (UTC) Reply

Are the br tags in your actual code or did you just add them for this?

You're sending an unnamed parameter "9" (which the template would see as {{{1}}}) but the switch is testing a non-existent named parameter {{{status}}}, or rather it's testing the string "Unknown", possibly followed by a br tag.

What happens when you add a default row at the end, like |#default=DEFAULT TEXT HERE? Jonathan3 (talk) 20:06, 5 November 2025 (UTC) Reply

Why do pages sort in non-alphanumeric order like this in categories?

• Foo 10
• Foo 8
• Foo 9

The only workaround seems to be adding a sort key to each category reference. ~2025-30714-69 (talk) 09:22, 3 November 2025 (UTC) Reply

Category sorting is alphabetic, not alphanumeric. See Help:Categories and Manual:$wgCategoryCollation --Clump (talk) 13:08, 3 November 2025 (UTC) Reply

Manual:$wgCategoryCollation#Numeric_sorting. For Wikimedia, you can find all wiki's that have numeric sorting enabled, by going to https://noc.wikimedia.org/conf/InitialiseSettings.php.txt and looking for all wiki's that have a collocation configured that ends with "-u-kn". —TheDJ (Not WMF) (talk • contribs) 13:53, 3 November 2025 (UTC) Reply

مشکل ورود به حسابم و نمی‌تونم حساب را بازیابی کنم ~2025-31060-99 (talk) 15:56, 3 November 2025 (UTC) Reply

I have just migrated my wiki from an old version to version 1.44. It has all gone well except that I still have a bold red line around my logo and the link for the Main Page. I assume these were there to remind you to change the logo, which I have done, so how do I get rid of the lines? Here is a link to my wiki: JP1 Remotes Wiki Thanks. Robman94 (talk) 22:04, 3 November 2025 (UTC) Reply

@Robman94 Not sure what you are trying to say - please clarify. Leaderboard (talk) 05:30, 5 November 2025 (UTC) Reply

Are you able to click on the link to my wiki? If so, it should be obvious what I am describing. Robman94 (talk) 19:03, 5 November 2025 (UTC) Reply

@Robman94 No, it is not obvious as I cannot see some red line around some logo after clicking on your link. Please be more specific where you see what, provide a screenshot, inspect the problem via your web browser's development tools, etc. Thanks! Malyacko (talk) 20:58, 5 November 2025 (UTC) Reply

Here is a screenshot: wzVcrVL.png (×ばつ1042) Robman94 (talk) 22:01, 5 November 2025 (UTC) Reply

Are you familiar with what a fresh install of Mediawiki looks like? The default logo and the link to the main page both have think red lines around them, presumably to remind you to change them. The question is, what is supposed to make them go away once you do change them? The fact that you can't see them when you go to my wiki tends to imply that the code that generates the red lines must be stored locally in the cache or something, but I've done ?action=purge already and that didn't clear it. Does anyone here know how that line is generated and how to clear it? Robman94 (talk) 13:55, 6 November 2025 (UTC) Reply

I have never seen those red lines before on any new install, and I'm not seeing them in YOUR wiki neither. However, you can try to inspect them with the browser's developer tools (hit the F12 key in your keyboard) and try to locate from which CSS it comes from. Ciencia Al Poder (talk) 22:31, 6 November 2025 (UTC) Reply

Yeah, I brought up the wiki on a different browser (Firefox) and I don't see them there either, but I do see them using Chrome and Edge. You can see them on the screenshot thought, right? (talk) 02:01, 7 November 2025 (UTC) Reply

I am using 1.41.1, and I tried following the manual and uploaded 1.44.2 to my files and moved all the important stuff there, but my wiki just crashes. I thought it might be the extensions not being up to date so I disabled them, still doesn't work. I am quite inexperienced in this sort of thing, so any help is greatly appreciated!

Also, I can't revert back to 1.41.1 with my backups because the Scribunto extension wouldn't match for some reason and there's nowhere to find the 1.41 Scribunto version, only 1.39, 1.43 and 1.44, so Scribunto lua templates would be broken if I reverted back. Please help! Tang Empire (talk) 05:23, 4 November 2025 (UTC) Reply

@Tang Empire Regarding the 1.41 Scribunto, download wikimedia/mediawiki-extensions-Scribunto at wmf/1.41.0-wmf.15 instead. Leaderboard (talk) 08:17, 4 November 2025 (UTC) Reply

Thank you. By the way, do you have any visual/beginner tutorials on how to upgrade? Because I seriously don't know what I did wrong, and I hope that my wiki will be fixed soon. Tang Empire (talk) 15:47, 4 November 2025 (UTC) Reply

Without more information, hard to tell sorry. Leaderboard (talk) 05:29, 5 November 2025 (UTC) Reply

"tutorials on how to upgrade" - Manual:Upgrading.

"uploaded 1.44.2 to my files and moved all the important stuff there" - I think it's considered better to do it the other way round, i.e. extract the MW files to a new directory then move the important stuff you want to keep to that new directory. Jonathan3 (talk) 20:10, 5 November 2025 (UTC) Reply

Yes, that is what I did, I uploaded 1.44 and moved/replaced stuff like Images and LocalSettings into the 1.44 folder. Also regarding Manual:Upgrading, I couldn’t understand a lot of the language so I asked ChatGPT to simply. I followed these instructions:

You’re replacing your old MediaWiki files with the new ones, but you must not just dump them on top of the old folder.

Instead, you:

Put the new version in a separate, empty folder.

Copy your important stuff from the old folder into it.

Then rename or swap the folders so the new one becomes your live wiki.

1. Back up everything

Make a copy of:

Your database (via phpMyAdmin or mysqldump)

Your old wiki folder, including LocalSettings.php, the images/ folder, and any custom skins/extensions.

2. Download the new version

If you can use the command line (SSH):

That creates a new folder like mediawiki-1.44.2.

If you can’t use command line:

Download the .tar.gz file to your computer.

Extract it using 7-Zip.

Upload the extracted folder to your server using FTP or cPanel File Manager, then extract it there.

3. Move your old settings & content

Inside your old wiki folder, copy these into the new folder:

LocalSettings.php, Images, custom Skins, custom extensions

4. Swap folders

Once your new folder has all the copied content:

Rename your old wiki folder (for example, wiki-old).

Rename your new one to the same name as the old one (for example, wiki).

This way your web address doesn’t change.

5. Fix permissions

Make sure the web server can read/write what it needs:

(Replace apache with your web user if needed.)

6. Run the update script

Go to your wiki folder in command line and run it

This updates your database to work with the new version.

7. Test

Visit your wiki and check Special:Version — it should say 1.44.2. Tang Empire (talk) 20:23, 5 November 2025 (UTC) Reply

Looks right at a glance.

Compatibility says that MW1.44 wants PHP 8 whereas 1.41 is happy with PHP 7.4. There's a difference in SQLite compatibility too.

If you really backed up all your files and the database I don't understand why it wouldn't work again (they do say you haven't backed up until you've checked you can restore, or something like that).

Did you get any error messages when running the update script?

What exact files and folders did you move across?

Can you describe "my wiki just crashes"? Jonathan3 (talk) 13:36, 6 November 2025 (UTC) Reply

Well, in some attempts the update script won't work and just have no reaction, other times it would work. I moved across LocalSettings.php, Skins folder, Extensions folder, Images folder.

By "my wiki just crashes", I mean that my wiki would not load and say "(wiki) can't candle the request right now". I can't remember which error message.

I only have backups once a week, and I've already successfully reverted back to 1.41 using the 1.41 Scribunto this discussion provided, so my site could work again. I might try again next week, and look into SQLite, but I've checked PHP and it's larger than 8. Tang Empire (talk) 15:38, 6 November 2025 (UTC) Reply

Good luck next time! Keep a note of exactly what steps you take and exactly what happens, just in case you need to ask again. Jonathan3 (talk) 21:30, 6 November 2025 (UTC) Reply

P.S. I think that's the HTTP 500 error. There are web pages with ideas on how to deal with that generally. It's mentioned here too: Manual:Common_errors_and_symptoms#HTTP_500_Internal_Error_during_installation. Jonathan3 (talk) 21:33, 6 November 2025 (UTC) Reply

hi again. I tried upgrading again, and you were right, it was a http 500 error. here is what i did step by step, do you perhaps know how to fix it? :

1. run

cd /path/to/your/wiki-parent-folder

wget https://releases.wikimedia.org/mediawiki/1.44/mediawiki-1.44.2.tar.gz

tar xvzf mediawiki-1.44.2.tar.gz

rm mediawiki-1.44.2.tar.gz

into the command line

2. move LocalSettings.php, images, extensions, and skins into mediawiki 1.44.2 folder while overwriting the original 1.44.2 ones.

3. Rename 1.44.2 to public_html and the old one to old

4. run

find ./images -type d -exec chmod 755 {} \;

chown -R apache:apache images

in command line (ran through many file names, all followed by "operation not permitted")

5. run update script

6. get http error 500. run the

find . -type f -exec chmod 644 {} \;

find . -type d -exec chmod 755 {} \;

because i got the error after i ran the update script (i didnt check before). nothing happens.

7. run it again, and this time it gave me something. here is the interaction:

[(me) public_html]$ find . -type f -exec chmod 644 {} \;

find: ‘.’: Permission denied

find: Failed to restore initial working directory: /home/(user)/domains/heterodontosaurus-balls.com/public_html_old: Permission denied

[(me) public_html]$ find . -type d -exec chmod 755 {} \;

find: ‘.’: Permission denied

find: Failed to restore initial working directory: /home/(user)/domains/heterodontosaurus-balls.com/public_html_old: Permission denied Tang Empire (talk) 03:20, 10 November 2025 (UTC) Reply

1) I'm not the host/bureaucrat, just the mediawiki admin for some wiki.

2) Due to a little spam issue I blocked some spammers (or potential spammer).

3) Learned later that some legit user also got blocked.

4) At this point I got the blocked IP address. Which was in the Private IP range (172.16.x.x .. 172.31.x.x) (this was a potential spammer case)

5) As admin only, I do not know in advance what IP is going to be blocked when I block some spammer (or potential spammer)

Anything I, or the wiki-host(private), can do here ? (other than giving me additional rights)

Anything I can tell the users to do that might be effected by such a Private IP range block. Like, I don't know, maybe how they should adjust there lan/router/modem/??? so mediawiki will not log them as coming from such a Private IP address?

MvGulik (talk) 21:17, 6 November 2025 (UTC) Reply

This looks like the wiki is behind a reverse proxy, and the wiki hasn't been configured correctly to detect the private IP as the reverse proxy (see $wgCdnServersNoPurge and $wgCdnServers) and use the X-Forwarded-For header as the real IP from users. Ciencia Al Poder (talk) 22:35, 6 November 2025 (UTC) Reply

Forwarded to host.

(Will report result although that might take a bit of time)

Thanks. MvGulik (talk) 23:46, 6 November 2025 (UTC) Reply

Thanks again. Problem was fixed. Although in this case it was reported as a problem with it picking up a local docker IP. MvGulik (talk) 11:43, 7 November 2025 (UTC) Reply

I signed up by mistake can someone please delete my account Oliver croll (talk) 23:19, 6 November 2025 (UTC) Reply

See meta:Account vanishing Ciencia Al Poder (talk) 17:01, 7 November 2025 (UTC) Reply