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)

so I did this https://www.sebastian-haselbeck.de/how-i-battled-a-ddos-attack-like-a-complete-idiot/ Rebastion2 (talk) 15:33, 28 May 2025 (UTC)

Keeping Vector 2010--but ditching Vector 2022--on a third-party wiki

If there's really a means of doing so--tried hiding the 2022 option on my site's Special:Preferences as founding bureaucrat, but that interface is still appearing in "useskin" mode--let me know in advance. Pinging @Bawolff/@TheDJ/@Pppery/@Universal Omega/@MacFan4000/@Reception123 just in case. (Based on a recent Miraheze help-desk discussion.) --Slgrandson (talk) 23:34, 15 May 2025 (UTC)

Keeping this up for a bit longer before I receive a reply here, or ask around elsewhere. --Slgrandson (talk) 16:45, 29 May 2025 (UTC)

Vector 2022 dark mode behavior with caching

Does anyone know if you make the "os" setting the default will the caching work correctly? Using regular MediaWiki caching, not Varnish. I remember that was a concern when dark mode was being developed. I want to hear if it is fixed or if there are settings that need to be adjusted. Flounder ceo (talk) 18:18, 22 May 2025 (UTC)

I would be surprised if that was an issue (i dont actually know that much about vector's dark mode). I dont think that what you're describing was the nature of the concern when vector was being developed. Bawolff (talk) 02:53, 30 May 2025 (UTC)

Project in root directory help

I have my mw install in the root directory and followed the advice found in these pages 1, 2, 3 and some advice found in discussions there meaning I have the following:

$wgScriptPath = "";
$wgArticlePath = "/$1";

and in my Apache .conf

 ServerName name.wiki
 ServerAlias www.name.wiki
 DocumentRoot /var/www/wikiname
 ... SSL stuff
 
 RewriteEngine On
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
 RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/index.php [L]
 
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
 RewriteRule ^/?images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/thumb.php?f=$1&width=$2 [L,QSA,B]
 
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
 RewriteRule ^/?images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$ %{DOCUMENT_ROOT}/thumb.php?f=$1&width=$2&archived=1 [L,QSA,B]
 
 <Directory /var/www/wikiname/images>
   Options -Indexes
   AllowOverride None
   AddType text/plain .html .htm .shtml .phtml
   AddType image/webp .webp
   <Files "*.php">
     SetHandler !
   </Files>
   Header set X-Content-Type-Options nosniff
 </Directory>

LocalSettings.php is safe and permissions seem fine, however, I'm able to access random files through the URL in the directory like .txt files and other files like that in directories. How do I go about only having necessary files be web-accessible?

EDIT: This bit of documentation seems like the right direction. Do I have this right?

 ServerName name.wiki
 ServerAlias www.name.wiki
 DocumentRoot /dev/null
 ... SSL stuff
 
 Alias /index.php /var/www/wikiname/index.php
 Alias /api.php /var/www/wikiname/api.php
 Alias /load.php /var/www/wikiname/load.php
 Alias /thumb.php /var/www/wikiname/thumb.php
 Alias /img_auth.php /var/www/wikiname/img_auth.php
 Alias /opensearch_desc.php /var/www/wikiname/opensearch_desc.php
 Alias /images /var/www/wikiname/images
 Alias /robots.txt /var/www/wikiname/robots.txt
 
 <Directory /var/www/wikiname>
   Require all granted
   Options -Indexes
   AllowOverride None
   ... Move rewrites here
 </Directory>
 <Directory /var/www/wikiname/images>
   .. Same as before
 </Directory>

Porcupinez (talk) 13:08, 23 May 2025 (UTC)

@Porcupinez: By .txt files and other files like that in directories, do you mean in the images/ directory, or just the general MediaWiki application files? If the latter, there's no problem with them being accessible. I think ideally you should be able to restrict it to serve only index.php, api.php, rest.php, thumb.php, thumb_handler.php, img_auth.php, and load.php (i.e. get rid of the -d and -f checks you've got above) but some extensions still want to serve images etc directly from their directories. Sam Wilson 01:10, 25 May 2025 (UTC)

Thanks for the reply! I meant general MediaWiki application files. I edited a bit onto my initial post. Would getting rid of the !-f and !-d flags be enough instead of all that? I would still want to selectively expose files like robots.txt and not break anything with extensions like you mentioned. Porcupinez (talk) 01:19, 25 May 2025 (UTC)

@Porcupinez: I wouldn't bother trying to hide application files. It's all open source anyway! But yeah, with some judicious use of rewrite rules you can hide everything but still have just a few things available. Sam Wilson 09:13, 26 May 2025 (UTC)

@Samwilson Ahh, well, at least it isn't much to worry about. There is a potential issue of LocalSettings.php.save files generated by an IDE, or files potentially blocking the main namespace. I would prefer to, but thankful to confirm it isn't inherently dangerous. Porcupinez (talk) 07:00, 27 May 2025 (UTC)

@Porcupinez: Are you editing with an IDE on prod?! :-P I guess you could add some LocalSettings-specific deny rule, just to be sure. Sam Wilson 07:18, 27 May 2025 (UTC)

@Samwilson I test with a local environment and eventually apply changes with nano? If there's a better alternative please let me know lol Porcupinez (talk) 12:48, 27 May 2025 (UTC)

@Porcupinez: That sounds fine. You might want to add your config files to a Git repo at some point, for easier tracking, but I was more worried that you meant you were e.g. editing in an IDE over SFTP and that somehow temp files were being created on the server. Which might be annoying (although what IDE would do that, I dunno). Sam Wilson 23:23, 28 May 2025 (UTC)

I wouldn't super worry about this,but yes, the alias setup is one way to prevent this sort of thing. There are quite a few others too, such as apaches access control or rewrite rules. See the apache docs for details. Bawolff (talk) 05:49, 1 June 2025 (UTC)

Good to know, thank you! I think I'll run with aliases, and maybe expose the extensions folder to not cause issues there. Seems better to explicitly decide what is exposed. Porcupinez (talk) 00:56, 3 June 2025 (UTC)

Enable editing category of protected articles

Hello,

I have a few thousands of protected articles at a wiki: it is working as a news site and the articles written over a week ago are protected as no further edits need to be made. They are called archived. I am facing an issue with categories. From time to time someone proposes a new category and asks for archived articles categories to be updated to add them to the newly added category. Is there a way to allow a user to edit a protected article, but only for purpose of adding categories, and not for anything else, i.e. not alter its content in any other way?

If not, I will need to either allow the interested users to be sysops with focus on only altering categories; or create a new 'archive keeper' user rights group and edit protection level for thousands of pages so that the 'archive keeper' users can edit them. Gryllida 12:03, 24 May 2025 (UTC)

The only way I can think of doing something remotely like this is Extension:AbuseFilter, which only works by taking away rights you had before, not granting people rights they already had, or to split the categories an article has into a separate non-protected page, both of which are impractical when dealing with a backlog of articles archived not using either system.

That said, nothing stops you (given sufficient consensus) from configuring the wiki to have a separate "archive keeper" group that can edit full-protected pages, and doing so would not need you to reprotect thousands of pages (and can of course be combined with the abuse filter approach to technically only let them edit categories too). * Pppery * _{it has begun} 18:26, 24 May 2025 (UTC)

Enable section archival

Some few months ago on talk pages a feature was added allowing to 'reply' to a paragraph, it also shows 'Latest comment: just now | 1 comment | 1 person in discussion'. Could whatever extension is doing this be extended to allow me to delete and/or archive sections from a talk page in one click? Gryllida 12:06, 24 May 2025 (UTC)

That's Extension:DiscussionTools. Deleting or archiving some partial page content sounds out of scope. Why would someone want to do that manually anyway? Malyacko (talk) 14:38, 24 May 2025 (UTC)

Oh there are plenty of reasons. There's an entire gadget for it (OneClickArchiver). The bigger problem is that there is no real concept of 'archiving' that is standardized, which makes any sort of implementation for all wikis in the world a lot more difficult. —TheDJ (Not WMF) (talk • contribs) 08:07, 27 May 2025 (UTC)

Problem with Short URL-s after uprgade to Mediawiki 1.43.1

I've run into issue after upgrading my wiki from 1.42.x to 1.43.1. All pages wive error page 404. Looking through all the guidelines and documentation, it seems, that the problem is with Short URL-s.

Details

• Upgrade was done via cPanel (as was original install of the software).
• No error messages during upgrading.
• Upgrade log is all clean - says no errors.
• Wiki is in subdomain of the main doman. (I'm not inclined to share the side address as is it a private hobby project, but is someone is willing to look into it personally, then I can create temporary credentials if needed.)
• Page is configures so, that content can be seen only by users who have logged in.
• Folder /w or /wiki is not in use.

What I've tried so far

• Editing .htaccess
• Editing LocalSettings.php Current settings are: $wgScriptPath = ""; $wgArticlePath = "/$1"; $wgScriptExtension = ".php"; $wgUsePathInfo = true;
• Cache is not enabled

Server information

• PHP: 8.4.6 (litespeed)
• ICU: 71.1
• MariaDB: 10.6.21-MariaDB-cll-lve-log

Used extensions

• Citizen (2.39.3)
• MinervaNeue
• MonoBook
• Timeless (0.9.1)
• Vektor (1.0.0)
• NumberHeadings
• VisualEditor
• Cite
• VisualData
• FontAwesome

Zängov (talk) 15:00, 24 May 2025 (UTC)

This concerns your webserver configuration. which has to parse the urls correctly and then give the right information to MediaWiki. So that's what you should look into. —TheDJ (Not WMF) (talk • contribs) 08:04, 27 May 2025 (UTC)

There was no changes on server side as much as I'm aware.

Only me pressing the update button in cPanel. Zängov (talk) 15:20, 30 May 2025 (UTC)

I checked the backup and looked up the old version of the MediaWiki was 1.42.6 and it was updated to 1.43.1

@TheDJ Based on the troubleshooting so far I 100% agree, that it has to be something on the server side, but I can't figure out anything else than .htaccess or LocalSettings.php settings and these two were not changed (at least by me). Could it be that upgrade rewrote file .htaccess? Zängov (talk) 15:36, 30 May 2025 (UTC)

You should include your .htaccess and any other config related to rewriting urls. Bawolff (talk) 19:43, 27 May 2025 (UTC)

@Bawolff

LocalSettings.php you can already see in my original post.

Content of .htacess is as follows:

<IfModule mod_rewrite.c>

RewriteCond %{REQUEST_URI} !^/w/rest\.php

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d

RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/w/index.php [L]

</IfModule> Zängov (talk) 15:21, 30 May 2025 (UTC)

Your .htaccess doesnt match your LocalSettings.php, so one of them has to be wrong. If /w is not in use then your .htaccess should not use it. Bawolff (talk) 16:52, 30 May 2025 (UTC)

Awesome. Thank you @Bawolff Got a step closer (to something) 404-errors are gone.

Result is now bunch of error messages (PHP 8.4):

Deprecated: Wikimedia\ScopedCallback::consume(): Implicitly marking parameter $sc as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/scoped-callback/src/ScopedCallback.php on line 57

Deprecated: Wikimedia\ScopedCallback::cancel(): Implicitly marking parameter $sc as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/scoped-callback/src/ScopedCallback.php on line 66

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder@anonymous(): Implicitly marking parameter $doctypeName as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/parsoid/src/Utils/DOMUtils.php on line 50

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder@anonymous(): Implicitly marking parameter $public as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/parsoid/src/Utils/DOMUtils.php on line 50

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder@anonymous(): Implicitly marking parameter $system as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/parsoid/src/Utils/DOMUtils.php on line 50

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder::createDocument(): Implicitly marking parameter $doctypeName as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/remex-html/src/DOM/DOMBuilder.php on line 154

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder::createDocument(): Implicitly marking parameter $public as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/remex-html/src/DOM/DOMBuilder.php on line 154

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder::createDocument(): Implicitly marking parameter $system as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/remex-html/src/DOM/DOMBuilder.php on line 154

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder@anonymous(): Implicitly marking parameter $doctypeName as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/parsoid/src/Utils/DOMCompat.php on line 382

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder@anonymous(): Implicitly marking parameter $public as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/parsoid/src/Utils/DOMCompat.php on line 382

Deprecated: Wikimedia\RemexHtml\DOM\DOMBuilder@anonymous(): Implicitly marking parameter $system as nullable is deprecated, the explicit nullable type must be used instead in /home/*****/vendor/wikimedia/parsoid/src/Utils/DOMCompat.php on line 382

Fatal error: Declaration of MediaWiki\Json\JsonDeserializableCodec::jsonClassHintFor(string $className, string $keyName) must be compatible with Wikimedia\JsonCodec\JsonClassCodec::jsonClassHintFor(string $className, string $keyName): ?string in /home/*****/includes/json/JsonDeserializableCodec.php on line 56

With some PHP-versions I even manage to get to loginpage. Interestingly the error messages are not whown with PHP versions 8.1 and 8.3. Got to login-page. After logging in I got error:

Fatal error: Declaration of MediaWiki\Json\JsonDeserializableCodec::jsonClassHintFor(string $className, string $keyName) must be compatible with Wikimedia\JsonCodec\JsonClassCodec::jsonClassHintFor(string $className, string $keyName): ?string in /home/*****/includes/json/JsonDeserializableCodec.php on line 56

My conclusion here is, that is could be something to do with plugin, that shows the content. Content of Wiki is viewable only after logging in. Special-pages work, but just show that error in top of pages. Am I on the right track here? Zängov (talk) 19:28, 31 May 2025 (UTC)

Aparently not in the right track.

• Errors are shown regardless if user is logged in or not.
• Every other part of the site is displayed, but content of the page.
• I can even open the search and it finds the content and shows the preview, but article is not shown.

I didn't have many extensions installed in the first place. I did some cleanup - no change.

Currently only these extensions are listed in LocalConfig. So basically only 3 are in use.

wfLoadExtension( 'VisualEditor' );

wfLoadExtension( 'TemplateData' );

wfLoadExtension( 'Cite' );

# wfLoadExtension( 'VisualData' ); Zängov (talk) 22:08, 31 May 2025 (UTC)

the deprectation warnings are just warnings and can be ignored (typically that means your version of php is too new for your version of mediawiki). For the fatal error - make sure you installed mediawiki in a fresh location. If you extract the zip/tar file over top of an existing install you can get a mix of two versions which is bad. Make sure that all extensions are updated. If you installed via git, ensure composer dependencies are up to date. Bawolff (talk) 05:39, 1 June 2025 (UTC)

Thanks @Bawolff,

OK. Ignoring warnings.

• All 3rd party extensions are up to date. I assume I don't have to check it with extensions supplied with MediaWiki?
• It was not a fresh installation or fresh location. It was an UPGRADE.
• Both installation and upgrade was done via cPanel/Installatron

Currently I'm stuck with error:

Fatal error: Declaration of MediaWiki\Json\JsonDeserializableCodec::jsonClassHintFor(string $className, string $keyName) must be compatible with Wikimedia\JsonCodec\JsonClassCodec::jsonClassHintFor(string $className, string $keyName): ?string in /home/********/includes/json/JsonDeserializableCodec.php on line 56 Zängov (talk) 13:49, 1 June 2025 (UTC)

Default time format?

Is it 12h or 24h on a fresh install? Is this configurable?

I think it is weird that the Date format Preference option is using 24h but the site could be using 12h... Dengamlapotatisen (talk) 09:35, 27 May 2025 (UTC)

By default, every wiki out there runs on UTC's 24-hour clock (i.e. the wikis' 00:00 corresponds to 8:00 p.m. EDT, 7:00 Central, 5:00 Pacific at this time of year). Don't think I've ever come across an a.m./p.m. option (or the mere thought thereof)... --Slgrandson (talk) 10:26, 27 May 2025 (UTC)

it looks like this is in reference to OSM wiki, which had a js gadget to replace dates with 12 hour clock. Bawolff (talk) 19:40, 27 May 2025 (UTC)

Making -/ and \- turn the text it's enclosing into Title case

I want to make -/ and \- give the text they are enclosing the Title casing. But how? Even after adding it to LanguageConverter.php, Parser.php, Preprocessor.php and PPFrame_Hash.php, still, it took no effect.
What other files do I have to edit to add this functionality? Kxeon (talk) 16:06, 27 May 2025 (UTC)

If you're editing files at random without understanding how they work, its not surprising it doesn't work. I doubt anyone can answer this question without knowing what you did and if you did it correctly. Bawolff (talk) 19:41, 27 May 2025 (UTC)

Didn't expect a response just 3 hours after my query. Oops.

Also, since in this case I should post the code I added here, I will.

For LanguageConverter, I did this:

			switch ( $token ) {
				case '-{':
					// Check max depth
					if ( $depth >= $this->mMaxDepth ) {
						$inner .= '-{';
						if ( !$warningDone ) {
							$inner .= '<span class="error">' .
								wfMessage( 'language-converter-depth-warning' )
									->numParams( $this->mMaxDepth )->inContentLanguage()->text() .
								'</span>';
							$warningDone = true;
						}
						$startPos += 2;
						break;
					}
					// Recursively parse another rule
					$inner .= $this->recursiveConvertRule( $text, $variant, $startPos, $depth + 1 );
					break;
				case '}-':
					// Apply the rule
					$startPos += 2;
					$rule = new ConverterRule( $inner, $this );
					$rule->parse( $variant );
					$this->applyManualConv( $rule );
					return $rule->getDisplay();
				case '-/':
					// Check max depth
					if ( $depth >= $this->mMaxDepth ) {
						$inner .= '-/';
						if ( !$warningDone ) {
							$inner .= '<span class="error">' .
								wfMessage( 'language-converter-depth-warning' )
									->numParams( $this->mMaxDepth )->inContentLanguage()->text() .
								'</span>';
							$warningDone = true;
						}
						$startPos += 2;
						break;
					}
				// Recursively parse another rule
				$inner .= $this->recursiveConvertRule( $text, $variant, $startPos, $depth + 1 );
				break;
				case '\-':
					// Apply the rule
					$startPos += 2;
					$rule = new ConverterRule( $inner, $this );
					$rule->parse( $variant );
					$this->applyManualConv( $rule );
					return $rule->getDisplay();
				default:
					throw new UnexpectedValueException( __METHOD__ . ': invalid regex match' );
			}
		}

For Parser, I added:

	public function ucWordsLangConv( $text ) {
		$marker = self::MARKER_PREFIX . "-item-/$this->mMarkerIndex\-" . self::MARKER_SUFFIX;
		$this->mMarkerIndex++;
		$this->ucwords( $marker, $text );
		return $marker;
	}

For Preprocessor, this:

		'-/' => [
			'end' => '\-',
			'names' => [ 2 => null ],
			'min' => 2,
			'max' => 2,
		],

and for PPFrame_Hash, this:

					# Not in RECOVER_COMMENTS mode (extractSections) though.
					$out .= $this->parser->insertStripItem( $contextChildren[0] );
					$out .= $this->parser->ucWordsLangConv( $contextChildren[0] );

Now then. You might be able to see what I used here over and over again. There's probably something horribly wrong here. Maybe I forgot to add a function?

I tried to search for any instances of -{ and }- and the function that it is in, insertStripItem. Kxeon (talk) 16:06, 28 May 2025 (UTC)

@Kxeon: If you want to turn text into title case, I'd suggest a template called 'titlecase' containing something like <span style="text-transform: capitalize;">{{{1}}}</span>. Adding new wikitext syntax is pretty complicated and usually best avoided. Sam Wilson 23:11, 28 May 2025 (UTC)

In terms of built in, there is also support in scribunto extension. There is also the built in {{ucfirst:{{{1}}}}} Bawolff (talk) 02:44, 30 May 2025 (UTC)

It doesn't look like you call ucWordsLangConv from anywhere, so i dont see how it could possibly work (i'd also agree with Sam's point). Bawolff (talk) 02:48, 30 May 2025 (UTC)

mw.user.isTemp is not a function

Hello everybody!

We upgraded our Mediawiki 1.32.2 to 1.43.0 (we first upgraded to 1.39, and then, to 1.43).

We have the "LDAPAuthentication2", "LDAPProvider" and "PluggableAuth" extensions configured to login via LDAP, and the rest of the official extensions of Mediawiki.

We can't logout on special pages or on the home page, for example. It does not affect the applied skin.

We have enabled the following PHP configuration ($wgShowExceptionDetails = true;error_reporting( -1 );ini_set( 'display_errors', 1 );)  but it does not show any error messages.

This is the message we see when we click on "logout": "The session is being closed. Please wait a few seconds".

And we get in the devtools the following message:

ready.js:195:15
Uncaught TypeError: mw.user.isTemp is not a function
logoutViaPost ready.js:195
fire mediawiki.base.js:566
js ready.js:219
> jQuery 8
js ready.js:218
> jQuery 13
runScript load.php:12
execute load.php:14
doPropagation load.php:6
(Asíncrono: requestIdleCallback handler)
setAndPropagate load.php:7
impl load.php:20
<anonymous> jQuery

We did not find any information on this.

Thanks! Diegxalv (talk) 11:49, 29 May 2025 (UTC)

@Diegxalv Something is out of sync. Newer versions of MediaWiki provide that core javascript function, and clearly some of your other core javascript files know about it. My suspicion is that you installed the newer version on top of the older version, and some old files were not removed, or the copy of the new files was not completed. I would double check your upgrade process. —TheDJ (Not WMF) (talk • contribs) 08:51, 30 May 2025 (UTC)

Hi @TheDJ! I will repeat the upgrade process to discard it. Thank you so much for your message! Diegxalv (talk) 14:14, 6 June 2025 (UTC)

url + search return=upper→lower-case. how?

xx messenger begins lower case - I fixed the article title with  {{ lowercase title }} the url and search returns (I used Qwant) are though capitalized - page move is causing the url to mismatch the title. Onemillionthtree 06:16, 30 May 2025 (UTC) 06:18, 30 May 2025 (UTC) 06:21, 30 May 2025 (UTC) Onemillionthtree (talk) 05:26, 30 May 2025 (UTC)

Yes, this is expected, those cannot be 'fixed' and they cannot adhere to the 'lowercase title' instruction. —TheDJ (Not WMF) (talk • contribs) 08:46, 30 May 2025 (UTC)

I think that is ridiculous as this means the mistake cannot be solved - but we as humans created this situation - an encyclopedia-coding- as a solution not a problem - someone made the situation with no possible solution? I think there must be a solution - what is the coding rule that stops pages being moved into non capital letter articles? to then recode that rule to allow non-capital - that would be a way to solve the problem! Where is the location of the code? The isn't any reason that the code-rule "always capital letters" should exist - obviously because it is enforcing an error. Onemillionthtree (talk) 15:57, 30 May 2025 (UTC)

because we decided that is the way we wanted to do things. It is configurable (e.g. wiktionary allows lowercase) but wikipedia doesnt want that. Bawolff (talk) 05:44, 1 June 2025 (UTC)

It's not like I'm asking for immediate immortality or some other extremely difficult/impossible thing to occur - we as humans can't shouldn't settle for - life with an error as a situation which is normal - this isn't a good. It is defined as a bad - as bad - stupid, wrong, a mistake - no intelligent human accepts this situation. Onemillionthtree (talk) 16:00, 30 May 2025 (UTC)

Manual:$wgCapitalLinks "Set this to false to avoid forcing the first letter of page titles (including included pages, images, and categories) to capitals." - but is set as "true". ldid=329483 12:19, 13 June 2010 was "false" Reverted by Encoderoperations (talk) to last revision by Diego Grez 13 June 2010 = "true". "false" 00:35, 17 January 2016 - "true": "7 January 2016 by Haokan.h1o2r3v4a5t (talk | contribs) (corrected a mistake)" Onemillionthtree (talk) 13:27, 31 May 2025 (UTC)

All else times were "true" - why not "false" ? Onemillionthtree (talk) 13:31, 31 May 2025 (UTC) @Quiddity:

User email authentication not working: something removes email address and token from user table

Hello,

I hope someone can help me. My mediawiki installation (1.39.10) started to behave strange a couple of days ago. Before that it worked as it should. Strangely enough, I don't recall making any updates to mediawiki or the extensions at that time.

What happens: when a new user registers or an existing user changes the email address ( $wgEmailAuthentication=true ), the authentication email is sent and received ok, but when clicking on the authentication link, it is for most of the times (not always!) expired.

I queried the user table in mysql, and when I create a new user, I can see the "user_email" as well as the "email_token" and "email_token_expires" columns get appropriate values. But when I redo the query after a couple of seconds, all the email related values are "NULL". So for some reason something is removing them right after they are saved in the table.

I receive no error messages ( error_reporting( -1 ); ini_set( 'display_errors', 1 ); ) and can't find anything relevant in any logs. Does anyone have a clue on what is going on, or on how I could try to debug this?

Lindholmm (talk) 14:18, 30 May 2025 (UTC)

check if it still happens after removing all extensions. Check also if setting $wgMainCacheType = CACHE_NONE; has any effect (you dont want that setting in general it will make your wiki super slow, but it might help narrow down causes). Bawolff (talk) 05:41, 1 June 2025 (UTC)

After checking all these and server and database and php timezones etc. without any luck, I think I have come up with the cause: something is "clicking" the cancellation link in the authentication email right after it has been sent. Someone (probably my company's IT department) may have installed a new spam filter to the mail server that scans links in outgoing mails?

Anyway, if I remove the cancellation link from Mediawiki:Confirmemail body the email address won't disappear from the user table, but it will instead get automatically authenticated. So I'm pretty sure something is automatically clicking through the links in the emails.

I probably can ask my IT department to exclude my authentication emails from the filter. But it would be better to change the authentication and cancellation page Special:ConfirmEmail to have a button that needs to be clicked before the authentication/cancellation actually takes place.

Do I have to code this myself or is there a setting or an extension that does this?

Lindholmm (talk) 06:33, 1 June 2025 (UTC)

This is now confirmed. The new virus/spam filter attached to my company's SMTP server checked the links in outgoing emails, first causing the confirmation of the account (first link in the email) and immediately after, the invalidation of the account (second link in the email). When we excluded the links with Special:ConfirmEmail and Special:InvalidateEmail from being checked by the virus/spam filter, everything returned to normal.

I have no idea how common it is to have a virus/spam filter that checks links this way, but apparently, it can happen. I think it would be safer to change the behavior of Special:ConfirmEmail and Special:InvalidateEmail so that there is a button that must be pressed (by a human) before the actual confirmation or invalidation takes place.

Lindholmm (talk) 13:06, 2 June 2025 (UTC)

how to run a SQL query to search through all text on my site to find a 'string'

as a follow-up to: Topic:Ridpx5qa0ie4ll0a

SELECT page.page_namespace, page.page_title
FROM page
JOIN revision ON revision.rev_page = page.page_id AND revision.rev_id=page.page_latest
JOIN slots ON slots.slot_revision_id = revision.rev_id
JOIN slot_roles ON slot_roles.role_id = slots.slot_role_id
JOIN content ON content.content_id = slots.slot_content_id
JOIN text ON text.old_id = CAST(SUBSTRING_INDEX(content.content_address, ':', -1) AS UNSIGNED)
WHERE slot_roles.role_name = 'main' 
AND LOWER(text.old_text) LIKE '{{MultiClass Object\n%';

Note that CAST statement in the last JOIN ON. Turns out that content.content_address prefixes all of its values with "tt:" such that the JOIN text ON text.old_id=content.content_address won't work unless you strip out the "tt:" first. Revansx (talk) 21:21, 30 May 2025 (UTC)

@Revansx just FYI, and to subscribe you to this thread, I've moved this here from the subpage which should've been a redirect! Cheers. Quiddity (WMF) (talk) 22:13, 30 May 2025 (UTC)

Upgrading stuck at MigrateRevisionActorTemp

Hello, I'm trying to upgrade to MediaWiki 1.43.1 from an older installation, 1.34.0. I've run the built-in web script at /mw-config, but it is getting stuck trying to upgrade the database.

...user_editcount in table user already modified by patch patch-user-user_editcount.sql.
Running MigrateRevisionActorTemp...
Run update.php to create rev_actor.

An error occurred:
Execution of MigrateRevisionActorTemp did not complete successfully.

Running applicable php scripts at the command line results in no output:

[user@server mediawiki-1.43.1]# php maintenance/update.php
[user@server mediawiki-1.43.1]# php maintenance/migrateRevisionActorTemp.php
[user@server mediawiki-1.43.1]# 

I've searched but not found any other instances of this happening to someone else. Thanks for any help! Nodoho (talk) 14:41, 31 May 2025 (UTC)

Update: Turns out PHP errors were being suppressed, here is why the update.php script exited silently. Will work on tracking down the solution to this issue. Nodoho (talk) 14:45, 31 May 2025 (UTC)

[31-May-2025 10:43:26 America/New_York] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mcrypt.so' - /usr/lib64/php/modules/mcrypt.so: cannot open shared object file: No such file or directory in Unknown on line 0
[31-May-2025 10:43:26 America/New_York] PHP Parse error:  syntax error, unexpected 'class' (T_CLASS), expecting identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' in /site/mediawiki-1.43.1/maintenance/update.php on line 132

Got mcrypt working, but still running into trouble with the second error above. Here is the line with the error:

$composerLockUpToDate = $this->runChild( CheckComposerLockUpToDate::class );

and the context in update.php:

		// Check external dependencies are up to date
		if ( !$this->hasOption( 'skip-external-dependencies' ) && !getenv( 'MW_SKIP_EXTERNAL_DEPENDENCIES' ) ) {
			$composerLockUpToDate = $this->runChild( CheckComposerLockUpToDate::class );
			$composerLockUpToDate->execute();
		} else {

Looks like command-line php is stuck, for some reason, at version 5.4.16, and suspecting that is the cause of the error. Been stuck in dependency difficulties while trying to compile PHP 8.4, currently cannot get the ./configure script to see the latest recently installed libxml2. Taking a break. Hoping this will eventually fix the above problem at any rate, and leaving everything above in case someone else encounters this issue. Nodoho (talk) 15:35, 31 May 2025 (UTC)

Returning to say that I successfully upgraded to MediaWiki 1.43.1. Did 1.35.5, then 1.39.12, then finally 1.43.1, with a mix of running maintenance/update.php and mw-config web script, troubleshooting lots of errors along the way—including getting php8 up and running. Hope this helps someone else in the future. Nodoho (talk) 12:10, 1 June 2025 (UTC)

Use external font for a Wikimedia wiki

Hi, I am currently want change font on a Wikimedia wiki to Cascadia Mono via js and css files, however sometimes it stills have default fonts. Could it possible to change to that font everywhere (e.g. like heading, titles, special pages, etc.).

Here link to my js and css files:

CSS: m:User:DinhHuy2010/global.css JS: m:User:DinhHuy2010/global.js

Thanks. DinhHuy2010 (talk) 13:13, 2 June 2025 (UTC)

Try adding a !important to the css decleration. Bawolff (talk) 02:44, 4 June 2025 (UTC)

@Bawolff Thanks, it works! DinhHuy2010 (talk) 12:29, 5 June 2025 (UTC)

Installing Hridoy

Hi, I am Installing Hridoy currently want change font on a Wikimedia wiki to via js and css files, however sometimes it stills have default fonts. Could it possible to change to that font everywhere (e.g. like heading, titles, special pages, etc.). INSTALLING HRIDOY (talk) 09:26, 2 June 2025 (UTC)

navigation pane moves with EDGE

I have to use the edge browser.  When I do the left side navigation panes go to bottom of page and not next to main body.

170.85.70.254 18:51, 3 June 2025 (UTC)

htmlspecialchars() in HtmlArmor.php file

Hi,

We upgraded our Mediawiki to 1.43.1.

Everything is working but when we enabled the following PHP configuration ($wgShowExceptionDetails = true;error_reporting( -1 );ini_set( 'display_errors', 1 );) , it shows us the following message:

Deprecated: htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/wiki/includes/libs/HtmlArmor.php on line 59

Our PHP version is 8.1.32 (MediaWiki 1.43 requires PHP 8.1.0 or later).

We did not find any information on this.

Thanks! Diegxalv (talk) 14:21, 6 June 2025 (UTC)