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)

If this gains no movement, I'll try my luck at Skin talk:Vector/2022. --Slgrandson (talk) 22:19, 12 June 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)

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)

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)

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)

Its probably safe to ignore. It might mean one of the extensions you are using have not been updated for php 8.1 Bawolff (talk) 03:51, 7 June 2025 (UTC)

Hi, @Bawolff!

This message is quite curious, we are using only the extensions that come bundled with MediaWiki (included with the upgrade package).

I hope this message doesn't cause any problems.

Thanks for your help! Diegxalv (talk) 20:43, 7 June 2025 (UTC)

I was kind of making an assumption that it was an extension and not core as i thought all the cases in core & bundled extensions were fixed, but perhaps we missed one. In any case, its just a harmless warning and can be safely ignored. In production use, its safe to set error_reporting in php.ini to exclude deprecation warnings. (if you know how to get a backtrace, that could be helpful for fixing it, but no worries if that is difficult). Bawolff (talk) 21:06, 7 June 2025 (UTC)

Writing filters for data items using the Abusefilter extension

We have a wiki with Wikibase data items attached. Many of our data items have one label, which we conventionally store as the English label, but there is nothing stopping people from creating other labels. Item properties determine whether or not a data item is subject to this or can have multilingual labels. How could you go about writing a filter that reports adding such a label?

Our version is 1.43.1. 151.186.181.32 15:34, 6 June 2025 (UTC)

I think I am looking for documentation on Wikibase-specific filter rules such as wbsetlabeldescriptionaliases. 151.186.181.32 11:23, 9 June 2025 (UTC)

About the themes removed in 1.22.

What is stopping me from copying "Standard" over from 1.21 and putting them in 1.39's theme folder? 2A00:23C6:41E6:AC01:3B40:E1AF:DED8:4C58 16:22, 8 June 2025 (UTC)

Planned obsolescence, maybe: Skin:Standard was phased out from MW way back in 2013 (along with several others from Wikipedia's early days), and is no longer supported. Depending on your tastes/opinion, you might want to consider Nostalgia, which Wikimedia keeps around for WP's December 2001 snapshot. --Slgrandson (talk) 02:02, 9 June 2025 (UTC)

Or you just fork the skin and fix it up yourself to work with all the new MediaWiki skin logic. —TheDJ (Not WMF) (talk • contribs) 08:10, 10 June 2025 (UTC)

Random page raises: InvalidArgumentException: Wikimedia\Rdbms\Platform\SQLPlatform::makeList: unexpected nested array

I have the latest version: 1.43.1

See all the details at: Sürüm - Nurpedia.org - İman ve İslam Hakikatlerine Dair Nur Ansiklopedisi

I got the following error when I try to pick a random page from the main page: Dahili hata - Nurpedia.org - İman ve İslam Hakikatlerine Dair Nur Ansiklopedisi

[683598d1451c472d2cb20af2] /wiki/%C3%96zel:Rastgele InvalidArgumentException: Wikimedia\Rdbms\Platform\SQLPlatform::makeList: unexpected nested array

Backtrace:

from /home/yonlenco/nurpedia.org/includes/libs/rdbms/platform/SQLPlatform.php(281)

#0 /home/yonlenco/nurpedia.org/includes/libs/rdbms/platform/SQLPlatform.php(273): Wikimedia\Rdbms\Platform\SQLPlatform->makeList()

#1 /home/yonlenco/nurpedia.org/includes/libs/rdbms/platform/SQLPlatform.php(724): Wikimedia\Rdbms\Platform\SQLPlatform->makeList()

#2 /home/yonlenco/nurpedia.org/includes/libs/rdbms/database/Database.php(3305): Wikimedia\Rdbms\Platform\SQLPlatform->selectSQLText()

#3 /home/yonlenco/nurpedia.org/includes/libs/rdbms/database/DatabaseMySQL.php(644): Wikimedia\Rdbms\Database->selectSQLText()

#4 /home/yonlenco/nurpedia.org/includes/libs/rdbms/database/Database.php(1337): Wikimedia\Rdbms\DatabaseMySQL->selectSQLText()

#5 /home/yonlenco/nurpedia.org/includes/libs/rdbms/database/Database.php(1354): Wikimedia\Rdbms\Database->select()

#6 /home/yonlenco/nurpedia.org/includes/libs/rdbms/database/DBConnRef.php(127): Wikimedia\Rdbms\Database->selectRow()

#7 /home/yonlenco/nurpedia.org/includes/libs/rdbms/database/DBConnRef.php(369): Wikimedia\Rdbms\DBConnRef->__call()

#8 /home/yonlenco/nurpedia.org/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(792): Wikimedia\Rdbms\DBConnRef->selectRow()

#9 /home/yonlenco/nurpedia.org/includes/specials/SpecialRandomPage.php(222): Wikimedia\Rdbms\SelectQueryBuilder->fetchRow()

#10 /home/yonlenco/nurpedia.org/includes/specials/SpecialRandomPage.php(169): MediaWiki\Specials\SpecialRandomPage->selectRandomPageFromDB()

#11 /home/yonlenco/nurpedia.org/includes/specials/SpecialRandomPage.php(80): MediaWiki\Specials\SpecialRandomPage->getRandomTitle()

#12 /home/yonlenco/nurpedia.org/includes/specialpage/SpecialPage.php(728): MediaWiki\Specials\SpecialRandomPage->execute()

#13 /home/yonlenco/nurpedia.org/includes/specialpage/SpecialPageFactory.php(1724): MediaWiki\SpecialPage\SpecialPage->run()

#14 /home/yonlenco/nurpedia.org/includes/actions/ActionEntryPoint.php(504): MediaWiki\SpecialPage\SpecialPageFactory->executePath()

#15 /home/yonlenco/nurpedia.org/includes/actions/ActionEntryPoint.php(146): MediaWiki\Actions\ActionEntryPoint->performRequest()

#16 /home/yonlenco/nurpedia.org/includes/MediaWikiEntryPoint.php(200): MediaWiki\Actions\ActionEntryPoint->execute()

#17 /home/yonlenco/nurpedia.org/index.php(58): MediaWiki\MediaWikiEntryPoint->run()

#18 {main}

Your kind help is really appreciated. Thanks. Alyabby (talk) 11:45, 9 June 2025 (UTC)

The problem is around here in the (SQLPlatform.php file) source code:

public function makeList( array $a, $mode = self::LIST_COMMA ) {

$first = true;

$list = '';

$keyWarning = null;

foreach ( $a as $field => $value ) {

.... (several statements here)

} elseif ( is_array( $value ) ) {

throw new InvalidArgumentException( __METHOD__ . ": unexpected nested array" );

what might have caused to this $value to be an array? Alyabby (talk) 16:47, 13 June 2025 (UTC)

problem of transcluded sections with references defined by name in a {{reflist |refs=

Hi all, In the following example page -> https://commons.wikimedia.org/wiki/Commons:De_minimis , sections of countries are transcluded but the ref définitions were in error for 2.FR 14.IRL 15.Japan and 19.Slovenia transclusions.

One solution I found was to move the ref definitions in the same section where used. This is acceptable in case of uniticy of the ref definition. Ex for Slovenia -> https://commons.wikimedia.org/w/index.php?title=Commons:Copyright_rules_by_territory/Slovenia&diff=prev&oldid=1042377831

But it is not satisfying in other transclusions when the same reference was used in several sections. This leads to copy again the same reference definition in each section where it is used , loosing by this way the benefit of a unique shared déclaration with " {{reflist |refs= ". How to solve that ? Thanks. --Christian 🇫🇷 FR 🚨 (talk) 11:34, 11 June 2025 (UTC)

Spanish decimal separator

I just noticed that the official mw.language library for Spanish 'es' shows the format officially used in Spain. In Spain they use commas as decimal separators, different Spanish-speaking countries use either commas (Spain, Argentina, etc.) or dots (Mexico, Guatemala, etc.). However, the consensus reached in Spanish Wikipedia is to use dots and accept the use of commas in articles written by authors from countries that use commas. WP:NÚMERO

I think that the module should be modified to show dots as decimal separators in accordance with Spanish Wikipedia's guidelines. This affects templates and infoboxes that use modules that get information from Wikidata. Can it be localized in real time depending on the IP? JaimeDes (talk) 04:42, 13 June 2025 (UTC)

Unable to access wiki.openoffice.org after creating a Mediawiki account

I was trying to create and save a book on wiki.openoffice.org and I got the impression, that I needed an "account" to do this. Having created a Mediawiki account via the "Login" link there, I am no longer able to access wiki.openoffice.org. (I get error 403: Forbidden You don't have permission to access this resource).

I am somewhat at a loss now, and I wonder, what I have invoked. I have tried reading the user help and FAQ links without finding any general information about access to *read* established wikis, permissions needed etc.

I would like some help on what do do or set up via the web to be able to access the wiki.openoffice.org.

Thank you. Kirthomaoo (talk) 11:02, 13 June 2025 (UTC)

They are still using MW 1.35 which is long unsupported and their only wiki related help simply points to this site so it wouldn't be surprising that their registration procedure was lacking maintenance. You might try your luck in their forum.

Edit: just noticed this. Tactica (talk) 17:05, 13 June 2025 (UTC)

Thank you very much. That may indeed explain matters. :) Kirthomaoo (talk) 07:33, 14 June 2025 (UTC)

where are the site notice located and translated ?

Hi all. I want to translate in FR banner "Nominate your favorite tools..." currently appearing on MW pages. My question is where is it defined in EN ? and where do I provide the FR text ?

On page -> https://www.mediawiki.org/w/index.php?title=MediaWiki:Sitenotice&action=edit they say to go to translatewiki.net but the link they provide is independant of the message. So how do I search ? Thanks. --Christian 🇫🇷 FR 🚨 (talk) 14:15, 13 June 2025 (UTC)

Since the banner doesn't include a translate link, it's quite likely that it is intended to remain untranslatable.

Also, the "site notice" is not the banner. The "From Wikipedia..." message appended to every Wikipedia article is an example of a site notice thay may be edited and translated. Tactica (talk) 16:43, 13 June 2025 (UTC)

so again, where do we find the the site notice declarations and the translations. More of that it would allow to write a request for translation and reach to a larger community. Can someone answer effectively to the topic ? Thanks. --Christian 🇫🇷 FR 🚨 (talk) 07:14, 14 June 2025 (UTC)