Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.

view · edit Frequently asked questions (see also: Wikipedia:FAQ/Technical) Click "" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212

Facing a new issue today regarding the IP Information Tool where access to some of the non-admin information does not show up in the Special:Contributions page for an IP as it did before. That page now only shows "Version", "Active blocks", and "Contributions". Oddly, the country (not city) location still pops up on the watchlist preview, even though it does not show on the Contributions page. Anyone else seeing similar? Best, CMD (talk) 08:00, 15 May 2024 (UTC)

The IP information drop down has been returning no information for me other than the version (IPv4 vs. IPv6), local block info and contribs for the last two days. It's like it can't access any of the data from whichever database it draws from. Every other field simply states "not available".-- Ponyo^{bons mots} 21:43, 15 May 2024 (UTC)

And regarding my odd note on watchlist preview, this only happens sometimes, with even different edits from the same IP showing me country location in one instance but not another. CMD (talk) 01:50, 16 May 2024 (UTC)

Further learning, I can refresh the same IP contributions page repeatedly and sometimes it will show me the country, sometimes it will show no access. CMD (talk) 03:25, 16 May 2024 (UTC)

Can someone link a page where this has recently happened to them, so that I can try to reproduce? –Novem Linguae (talk) 07:15, 16 May 2024 (UTC)

@Novem Linguae: it happens on any IP contributions page (this one, for example).-- Ponyo^{bons mots} 15:29, 16 May 2024 (UTC)

Thanks, I'm able to reproduce. According to https://phabricator.wikimedia.org/T363118#9804312, "not available" is case #2. This means Spur/Maxmind doesn't have that data. Looking at these fields, they're all populated by Spur. Maxmind and Spur have different coverage, so we may have a location for an IP but no other data for it.. So that one is not a bug and they have no plans to patch it, it looks like. –Novem Linguae (talk) 15:56, 16 May 2024 (UTC)

I don't understand how that data was available consistently for all IPs, then suddenly is missing for nearly all of them. It renders the entire IP contribs drop down useless. Oh well.-- Ponyo^{bons mots} 16:13, 16 May 2024 (UTC)

Someone just commented in the ticket that they think it's happening way more than it used to and they think something is broken. So it may be a bug after all. Here's hoping the devs figure it out. –Novem Linguae (talk) 16:47, 16 May 2024 (UTC)

If I refresh sometimes, sometimes, the location info magically just appears. So the data is there. Sometimes. This is all on the same IP page. The one listed just above if I refresh does show the location 1 time out of 4 or so. Canterbury Tail talk 15:58, 21 May 2024 (UTC)

This has now been split into two separate Phab issues, Phab:T355392 and Phab:T355393. CMD (talk) 01:42, 24 May 2024 (UTC)

I have a sort of "hello, world" MediaWiki coding change I'd like to submit as my first-ever contribution to MediaWiki, and to get myself started and oriented with the system for submitting coding changes. If all goes well with that, I hope to follow that up with a more substantial change sometime, hopefully soon, after that. I already have a Wikimedia developer account, with accounts on MediaWiki and Wikitech. My usernames there, including my SSH access (shell) username, are the same as my English Wikipedia username. Now mw:Gerrit/Tutorial#Configure Git is telling me I need to have my "own Gerrit username". Is this a name which is unique to Gerrit, and not used anywhere else, such as the Toolforge? Also, I see on the Gerrit settings page a "Username" (is that the same as Git's "own Gerrit username"?), "Full name", and "Display name" – how are each of these used? Which of these names are used for the CREDITS page, the list that's updated by updateCredits.php? wbm1058 (talk) 20:35, 17 May 2024 (UTC)reply

Your Gerrit username is more properly your developer account username, which is the same as on Toolforge and other places. For those three fields, username is what you log in as, I don't think Full name is used anywhere, and display name is how your name appears on the Gerrit UI. updateCredits.php seems to parse "git log", so the name used is whatever shows up in Git, which usually is the same as one of the above but not necessarily. * Pppery * _{it has begun...} 20:52, 17 May 2024 (UTC)reply

Full name is actually what's used for sign-ins via web UIs (Wikitech, Toolsadmin). "Username" is only used for SSH access (toolforge / git review). The CREDITS page uses the name from git log, which you'd set through the git config --global user.name command. – SD0001 (talk) 21:22, 17 May 2024 (UTC)reply

Oh, oops, aparently I'm just as confused. * Pppery * _{it has begun...} 21:24, 17 May 2024 (UTC)reply

Thanks. Further complicating naming matters, I see there is an "LDAP" (Lightweight Directory Access Protocol) username. See wikitech:SRE/LDAP. Per wikitech:SRE/LDAP/Renaming users, "We do not rename users (Developer accounts) anymore. It can (and has) lead to various problems and errors all over the many separate systems which consume Developer accounts as their local databases and authentication methods will get out of sync." So I guess I'm stuck for now with the name I have (not that I want to change it). But a reason for proceeding cautiously here. I don't want to stumble into doing something irreversible that I wish I'd done differently later, after I figured out what I was actually doing, rather than signing up for it by trial and error. I don't recall seeing the mw:Developer account page before, and I think I created mine before the Create a Wikimedia developer account form was created. Today I just ran into the Bitu Identity Manager, which shows me "My LDAP properties". (see wikitech:IDM). Phabricator says my LDAP User is "Unknown". I don't know if there's a way I can personally make it known, or whether it being unknown is a problem. – wbm1058 (talk) 22:14, 17 May 2024 (UTC)reply

I think theres basically 2 logins. #1 is the oauth / centralauth / all wikis but wikitech one. #2 is ldap / gerrit / toolforge / wikitech. Lots of synonyms here. I forget if phabricator is one of those two, or a third one. –Novem Linguae (talk) 22:26, 17 May 2024 (UTC)reply

I suppose Phabricator is probably bilingual. Obviously I sign into it using my #1 because my #2 is unknown to the phabulous Phabricator. On the other hand, there must be some developers using it who may not have a #1. – wbm1058 (talk) 22:43, 17 May 2024 (UTC)reply

Yes, phab supports sign-in via either of the two. You can still link phab with the other account through Settings > External accounts. – SD0001 (talk) 06:21, 18 May 2024 (UTC)reply

Facepalm I looked at that screen twice and all I saw was date & time settings! Thanks! Now my account is linked with all (two) available providers. – wbm1058 (talk) 10:45, 18 May 2024 (UTC)reply

Shout-out to @BMueller (WMF):. I watched your online presentation given at last month's conference in Portland and thought you might be interested in reading this thread. Enjoyed meeting you in Toronto last year. – wbm1058 (talk) 23:21, 17 May 2024 (UTC)reply

Now I just found and opened the Gerrit Code Review - User Privacy page... so Google, as well as Wikimedia, is part of the loop! layers upon layers – wbm1058 (talk) 11:29, 18 May 2024 (UTC)reply

Hmm, Gerrit is a Dutch male name meaning "brave with the spear", the Dutch and Frisian form of Gerard. And Gerrit (software) was authored by Google. Whereas Git was written by the guy behind Linux. Learn something new every day. wbm1058 (talk) 11:48, 18 May 2024 (UTC)reply

When asked why he called the new software, 'git', British slang meaning 'a rotten person', Torvalds said 'I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git.' Ha! wbm1058 (talk) 12:00, 18 May 2024 (UTC)reply

Google is not part of the loop exactly. Google wrote the software, but it's open-source and the website https://gerrit.wikimedia.org is hosted by Wikimedia with no involvement from Google. * Pppery * _{it has begun...} 13:23, 18 May 2024 (UTC)reply

More from the "I figured out what was happening only after it already happened" department. Wikimedia Code Review https://gerrit.wikimedia.org/r/settings says I registered @ Monday, May 13, 2024, 9:08:55 PM UTC-04:00 ... what? I don't recall doing anything specific to "register" there last Monday. What was I doing at that time? I thought per mw:Gerrit/Tutorial I had to configure Git in order to register for Gerrit, but here I am already registered for Gerrit, and I haven't configured Git yet! O I C. I think I was looking at a previous code review related to the task I'd decided to work on, when I noticed "Sign up" and "Sign in" links on the upper right corner of that page. Clicking "Sign up" took me to this new IDM "Create account" page to create a Wikimedia developer account. Hey, I thought, I think I already have one of those that I needed for Wikitech/Toolforge. So I left that page, and clicked "Sign in". Voila, my Wikitech password got me in. I thought I had simply logged into Gerrit, not registered for it. What I didn't realize was that the "Bitu Identity Manager" would not only sign me in, but register me as well! wbm1058 (talk) 16:12, 18 May 2024 (UTC)reply

SSH keysedit

I already have SSH keys set up for Toolforge at Toolsadmin which I use on PuTTY and WinSCP but not directly from the Windows command prompt.

mw:SSH keys seems to indicate that I can't use my Toolsadmin SSH but will need another one, set up from the Windows command prompt. Correct?

Also, regarding configuring Git personal information. The guide says "You should have to do this only once." Is that literally true, or does it mean once on my desktop and once on my laptop, if I have two machines that I might want to submit code from? wbm1058 (talk) 18:06, 18 May 2024 (UTC)reply

@Wbm1058 You can reuse the same SSH key across multiple projects (in this case toolsadmin and Gerrit). The tutorial assumes that you have not setup the keys before.

Regarding the configuration of Git, you will need to do it once per machine. Sohom (talk) 23:08, 18 May 2024 (UTC)reply

My desktop is still running Windows 7. I know, I know, long in the tooth, but I'm proud to have kept it going for 14 years and would like to make it to 15. It still works for me, for the most part. I've downloaded the production version MediaWiki 1.41.1 and have it running for debugging. I generated my SSH keys with PuTTYgen, since the Windows 7 command prompt does not support the ssh command. I suppose I'd need to use PuTTY on that machine to connect to Gerrit, as I use it to connect to the Toolforge bastion. I think I can figure that out; haven't found documentation on how to use Gerrit on a Windows 7 machine. I haven't set up SSH on my Windows 10 laptop yet (only do Toolforge from my desktop). I don't know how to copy my keys from PuTTY to the required location on Windows 10. Might be easier to generate new keys on Windows 10. I have an ssh-rsa key for Toolforge access; the documentation says to use the ed25519 type for optimum security and performance. Can I use different SSH keys on each machine? wbm1058 (talk) 16:53, 19 May 2024 (UTC)reply

As a matter of fact, you are kind of expected to use different keys per user per machine. That’s why all the ssh settings of toolforge and Gerrit allow you to add multiple public keys. —TheDJ (talk • contribs) 16:58, 19 May 2024 (UTC)reply

What TheDJ said, you are expected different SSH keys across machines. However, if you are using one machine, you can reuse the key across multiple things (I have mine on Github/Gitlab/Toolforge and Gerrit as well as a bunch of private services). Sohom (talk) 18:15, 19 May 2024 (UTC)reply

OK, thanks! New state-of-the-art ed25519 keys generated and installed for my Windows 10 laptop (which MSFT tells me will be unsupported after next year, and my hardware is too old to run Windows 11(.

I successfully did a git clone. I'm a bit confused by the instructions at mw:Download from Git#Download for development:

"This clones the entire MediaWiki core repository, synced to the master branch, into a sub-directory named mediawiki"

I previously installed MediaWiki 1.40.1 on my laptop last November at the Toronto wikiconference, by downloading the then-current version from mw:Download, and successfully installed that, for testing.

I want to overwrite my previous 1.40.1 installation with the new files I just git got.

The standard mediawiki directory holds core and data sub-directories.

It doesn't appear that the git download includes any data. It appears to be a core directory, which includes some extra files that aren't part of the mw:Download version. Why don't the instructions say to download to a sub-directory named core rather than a sub-directory named mediawiki?

Oh, I see. mw:Manual:Upgrading#Using Git:

If using Git, export the files into a clean location, and then copy the old customized files into the new location as described in the previous section.

You will also need to install some external PHP libraries using Composer or a provided collection maintained for the Wikimedia wiki farm. More details on installing and updating external libraries can be found in the Git download documentation

So, for some reason, although I can test using 1.40.1 without having any PHP problems, I'll need to figure out this "Composer" thing in order to do development testing.

Hopefully it's not a problem that I'm running the PHP 8.2.12 Development Server – wbm1058 (talk) 23:11, 19 May 2024 (UTC)reply

I think all mediawiki unit tests are passing on php 8.1. Not sure about php 8.2. May want to switch to 8.1 to prevent hard to diagnose bugs. –Novem Linguae (talk) 00:45, 20 May 2024 (UTC)reply

The tests pass on php 8.2 as well 1, – SD0001 (talk) 12:16, 20 May 2024 (UTC)reply

Composeredit

c:\php\mediawiki\core>php maintenance/run.php update.php
Error: You are missing some external dependencies.
MediaWiki has external dependencies that need to be installed via Composer or from a separate repository. Please see
https://www.mediawiki.org?pojem=Manual:Installation_requirements#PHP and
https://www.mediawiki.org?pojem=Download_from_Git#Fetch_external_libraries
for help on installing the required components.

• mw:Manual:Installation requirements#PHP does not mention "Composer". It says "MediaWiki only requires PHP extensions that are enabled in PHP by default." I assume that's why I didn't get this error when I ran update.php on my desktop, where I'm just running the official MediaWiki releases. "If your hosting provider provides a basic LAMP environment without these, you may need to install or enable these manually."
• OK, I'm going to follow the instructions at mw:Download from Git#Fetch external libraries.
• Hmm, I guess I should mw:Download from Git#Update the Git submodules first? wbm1058 (talk) 14:22, 20 May 2024 (UTC)reply

I don't think submodules is what you need. The php maintenance/run.php update.php script just wants you to composer install in the mediawiki directory, that should download the required directories. Sohom (talk) 14:34, 20 May 2024 (UTC)reply

Indeed only the second link is relevant here. I'm clarifying this message in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1034113. Thanks for writing all of this up, it's helpful to see things from a different perspective sometimes. Matma Rex talk 16:07, 20 May 2024 (UTC)reply

c:\php\mediawiki>composer update --no-dev
Composer could not find a composer.json file in c:\php\mediawiki To initialize a project, please create a composer.json file. See https://getcomposer.org/basic-usage

I'm going to reboot my machine and try again. Composer install warned me that I might have a PATH problem. wbm1058 (talk) 15:56, 20 May 2024 (UTC)reply

Judging by your previous comments, you're just not in the directory that Composer expects – try going to c:\php\mediawiki\core, where you (and Composer) should find the composer.json file. Matma Rex talk 16:09, 20 May 2024 (UTC)reply

Yes, thanks, that was it. Once again the instructions misled me: "then run composer update --no-dev from your MediaWiki core directory." It's still running. This step takes significant time! wbm1058 (talk) 16:20, 20 May 2024 (UTC)reply

I think it worked. The console log is long, with a pile of "failed to download" warning messages, but it appears to have successfully worked around all of them. Here's the end of the log, showing just the last 3 of many installations:

  - Installing wikimedia/timestamp (v4.1.1): Cloning 138f3099b4 from cache
  - Installing wikimedia/xmp-reader (0.9.1): Cloning 8338d67969 from cache
  - Installing zordius/lightncandy (v1.2.6): Cloning b451f73e8b from cache
44 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating optimized autoload files
11 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
> MediaWiki\Composer\ComposerVendorHtaccessCreator::onEvent
No security vulnerability advisories found.

I think I'm ready to try running update.php again. – wbm1058 (talk) 16:51, 20 May 2024 (UTC)reply

c:\php\mediawiki\core>php maintenance/run.php update.php
Error: The MinervaNeue skin cannot be loaded. Check that all of its files are installed properly.

1. 0 C:\php\mediawiki\core\includes\GlobalFunctions.php(91): ExtensionRegistry->queue('C:\\php\\mediawik...')
   
2. 1 C:\php\mediawiki\core\LocalSettings.php(166): wfLoadSkin('MinervaNeue')
   
3. 2 C:\php\mediawiki\core\includes\Setup.php(216): require_once('C:\\php\\mediawik...')
   
4. 3 C:\php\mediawiki\core\maintenance\run.php(49): require_once('C:\\php\\mediawik...')
   
5. 4 {main}
   

PHP Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96 Fatal error: Error Loading extension. Unable to open file C:\php\mediawiki\core/skins/MinervaNeue/skin.json: filemtime(): stat failed for C:\php\mediawiki\core/skins/MinervaNeue/skin.json in C:\php\mediawiki\core\includes\registration\MissingExtensionException.php on line 96

Sigh. I didn't need no extensions when testing changes to the official release core page-moving functions. Now I do. – wbm1058 (talk) 18:04, 20 May 2024 (UTC)reply

You shouldn't need any extensions to run MediaWiki core. It's only trying to load the MinervaNeue skin, because you have a line in your LocalSettings.php like wfLoadSkin('MinervaNeue'); (maybe you copied it from your previous installation?). You can remove it or comment it out if you don't want it.

If you do want it, then you can install the skin using Git similarly to how you installed MediaWiki, just replacing the path in the git clone command: instead of mediawiki/core, use mediawiki/skins/MinervaNeue (and make sure to put it in the skins directory, where MediaWiki is looking for it). Similarly for all other skins and extensions. Matma Rex talk 18:13, 20 May 2024 (UTC)reply

Thanks! I just used the default LocalSettings.php that came with the release-version installation. Figuring I only need one skin, I just copied the folder from my backup of the release version, and commented out the others. That did the trick, and the database update looks like it ran successfully. – wbm1058 (talk) 20:28, 20 May 2024 (UTC)reply

MediaWiki internal error.

Original exception: 6d2f7f0574eb09bb447c9687 /index.php/Main_Page Error: Class "ResourceLoaderSkinModule" not found
Backtrace:
from C:\php\mediawiki\core\includes\ResourceLoader\ResourceLoader.php(417)

Another missing piece. The console log looks good, but this come up on the webpage. – wbm1058 (talk) 21:04, 20 May 2024 (UTC)reply

Did you git clone, composer install, and npm ci inside your default skin? Probably skins/Vector –Novem Linguae (talk) 21:17, 20 May 2024 (UTC)reply

The ResourceLoaderSkinModule class was recently renamed (gerrit:994854). It seems that you've just updated your MediaWiki to a version that doesn't have it any more, but one of your skins is an older version that is still using it. This will occasionally happen with skins and extensions.

If you've already installed the skin from Git, running git pull in the affected skin's repository should fix it. If you haven't, it's probably best if you do :) but you can also remove it from LocalSettings.php, or download the latest master snapshot from SkinDistributor/ExtensionDistributor. Matma Rex talk 21:51, 20 May 2024 (UTC)reply

Thanks for the nice, detailed response. mw:Special:SkinDistributor/Vector even offers the "master (latest development version)" but https://extdist.wmflabs.org/dist/skins/Vector-master-685a02f.tar.gz gives me a 404 Not Found error. I'll just figure out how to git it the preferred way ) wbm1058 (talk) 00:23, 21 May 2024 (UTC)reply

Weird, that link works for me now. Maybe it took a few minutes to generate. Matma Rex talk 00:35, 21 May 2024 (UTC)reply

Indeed. Just worked for me too. But rather than tinker with telling my Windows how to unzip that "gz" file ("Look for an app in the Miocrosoft Store"?!), I'm going to mw:Download from Git#Using Git to download MediaWiki skins.

Follow the exact same procedure as for extensions (described in the previous section), but using skins rather than extensions in all URLs and paths. wbm1058 (talk) 01:01, 21 May 2024 (UTC)reply

c:\php\mediawiki\core\skins>git clone https://gerrit.wikimedia.org/r/mediawiki/skins/Vector
Cloning into 'Vector'...
Enter passphrase for key '/c/Users/Bill/.ssh/id_ed25519':
remote: Counting objects: 99, done
remote: Finding sources: 100% (94/94)
remote: Getting sizes: 100% (70/70)
remote: Compressing objects: 100% (1041262/1041262)
remote: Total 37958 (delta 29), reused 37891 (delta 9)
Receiving objects: 100% (37958/37958), 11.37 MiB | 8.91 MiB/s, done.
Resolving deltas: 100% (28242/28242), done.

c:\php\mediawiki\core\skins>

Appears to have worked. – wbm1058 (talk) 01:17, 21 May 2024 (UTC)reply

 Done. Success. I have a development environment which seems to be operating identically with the official-release environment I just replaced. Tomorrow I move to the next step. Make minor "hello, world!" type changes in two files, and then figure out how to submit them for review. FYI, the project I'm working on, where I hope to make more substantial enhancements soon, is discussed on my talk: User talk:Wbm1058#My MediaWiki core developers thread. – wbm1058 (talk) 01:40, 21 May 2024 (UTC)reply

mw:Local development quickstartedit

It's just that the way you have cloned the repo is unconventional. mediawiki/core should be cloned to a directory named "mediawiki", not "core".

I think you will have a lot easier time going through mw:Local development quickstart instead, which unfortunately isn't advertised more prominently. You may want to discard the existing mediawiki install and use the quick start. You have already done step 1, so start with step 2. It's easy! – SD0001 (talk) 16:40, 20 May 2024 (UTC)reply

That "quick start" page has stuff I've already done previously, and insufficient info about stuff I needed to do.

I've had an "official release" version installed on my laptop since November. It makes a lot of sense to me to have started that way, because as complicated as installing the official release was, installing the developers' version is way more complicated yet.

• I've had PHP installed directly on Windows for over a decade now. My bots use that.
• There was no need for me to update my php.ini file to load the required PHP extensions. I already did that a long time ago. The problem is that this "composer" system basically "ignores" that, it seems to me.
• It just says to "use Git" to clone the core, as if that's easy. No it wasn't. See above for what steps I went through to figure it out.
• I installed SQLite already last year; I don't need to do that again.
• I already knew how to start my server, though I was told by someone to use "localhost:80" in Boston in 2019, not "localhost:4000". I don't know whether it matters which number I use there.

What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. – wbm1058 (talk) 17:28, 20 May 2024 (UTC)reply

1 and 2. yes I said as much - you have already done step 1.
3. There's no need to configure git before cloning repos. The steps from mw:Gerrit/Tutorial#Configure_Git are only to prepare for pushing changes.
4. composer mw-install:sqlite is not for installing sqlite (not required). Instead it initialises MediaWiki itself with sqlite as the db backend. This is a shortcut to avoid going through the web installer.
5. Running something on port 80 is only advisable on linux. On Windows/macOS, it's better to use a non-reserved port (> 1023) to avoid issues with firewalls.
What I need is a "quickstart" page for upgrading from an "official release" version to the developers' version. The easiest way to do that is to delete or forget about the release version and setup the developers' version from scratch. – SD0001 (talk) 17:56, 20 May 2024 (UTC)reply

What I did need to do before cloning was download and install Git, and setup SSH to use it. None of that was necessary to download and install the release version, which makes installing the release version an easier task.

Oh I see. a shortcut to avoid going through the web installer... well, now I know. I was wondering how that was done. But now, water under the bridge. I'd like to keep the database I started last year, for sentimental reasons, and just upgrade. I think upgrading should be easier than installing from scratch every time.

I've noted that my server runs really slowly on my system. Wrote that off as bloatware overwhelming my 14-year old processor, but, now that you mention it, could be a symptom of firewall intervention. I'll switch to port 4000 and see whether that runs faster.

I also noticed mw:Gerrit/Tutorial/tl;dr, and have kept that open in another browser window for comparison and reference. – wbm1058 (talk) 20:17, 20 May 2024 (UTC)reply

git-reviewedit

Per instructed at mw:Gerrit/Tutorial#Setting up git-review:

c:\php\mediawiki\core>git review -s --verbose
git: 'review' is not a git command. See 'git --help'.

c:\php\mediawiki\core>git-review -s --verbose
'git-review' is not recognized as an internal or external command, operable program or batch file.

?? – wbm1058 (talk) 14:09, 21 May 2024 (UTC)reply

• To use git review, you have to be in a git clone directory that already contains a (possibly hidden) .gitreview configuration file (see Setting up a repository for git-remote) — hmm wbm1058 (talk) 14:48, 21 May 2024 (UTC)reply

It looks like the directory where git-review got installed is not in your %PATH% environment variable. First of all, try closing the command-line window and opening it again, and retry – maybe it is just seeing outdated env variables.

If that doesn't help, you'll need to change that env variable, the option to do that is somewhere in your operating system settings. Add the directory where git-review is, probably something like like C:/Python310/Scripts/ (that's where it is on my machine). Note that you need to open a new command-line window every time for the changes to take effect when testing.

(If I recall, there's a checkbox to do that automatically when you install Python, which you may have left unchecked. You can also try reinstalling Python and finding that checkbox.) Matma Rex talk 15:04, 21 May 2024 (UTC)reply

Yes, I checked the box on the Python installation. Closing my command window and opening a new one did the trick, of course. The instructions could explicitly say to do that. Thanks again for all your help – wbm1058 (talk) 15:20, 21 May 2024 (UTC)reply

• That directory has a .gitreview file in it, with the following content:
  

host=gerrit.wikimedia.org
port=29418
project=mediawiki/core.git
track=1
defaultrebase=0

Is that good? wbm1058 (talk) 14:58, 21 May 2024 (UTC)reply

review installation logedit

c:\php\mediawiki\core>git review -s --verbose
2024-05-21 11:12:37.452765 Running: git config --get gitreview.remote
2024-05-21 11:12:37.468379 ... gitreview.remote = origin
2024-05-21 11:12:37.468379 Config'remote' = origin
2024-05-21 11:12:37.468379 Running: git config --get gitreview.branchauthor
2024-05-21 11:12:37.499631 Config'branchauthor' = name
2024-05-21 11:12:37.499631 Running: git symbolic-ref -q HEAD
2024-05-21 11:12:37.530879 Running: git for-each-ref --format=%(upstream) refs/heads/master
Following tracked origin/master rather than default origin/master
2024-05-21 11:12:37.609011 Running: git config --get gitreview.scheme
2024-05-21 11:12:37.671503 Config'scheme' = ssh
2024-05-21 11:12:37.671503 Running: git config --get gitreview.hostname
2024-05-21 11:12:37.687125 Config'hostname' = gerrit.wikimedia.org
2024-05-21 11:12:37.687125 Running: git config --get gitreview.port
2024-05-21 11:12:37.718370 Config'port' = 29418
2024-05-21 11:12:37.718370 Running: git config --get gitreview.project
2024-05-21 11:12:37.749619 Config'project' = mediawiki/core.git
2024-05-21 11:12:37.749619 Running: git log --color=never --oneline HEAD^1..HEAD
2024-05-21 11:12:38.687096 Running: git remote
2024-05-21 11:12:38.765224 Running: git branch -a --color=never
2024-05-21 11:12:38.890218 Running: git rev-parse --show-toplevel --git-dir
2024-05-21 11:12:38.937083 Running: git config --get core.hooksPath
2024-05-21 11:12:38.983962 Running: git config --get core.hooksPath
2024-05-21 11:12:39.015203 Running: git submodule foreach cp -p .git\hooks\commit-msg "$(git rev-parse --git-dir)/hooks/"

c:\php\mediawiki\core>

I don't see the "found origin push URL" and "fetching commit hook" that the instructions said I should see. – wbm1058 (talk) 15:47, 21 May 2024 (UTC)reply

The instructions are probably outdated and everything is probably okay. git-review is being somewhat actively developed, and the example output in mw:Gerrit/Tutorial#Setting_up_git-review has a 2019 date. If it didn't work, you'll find out later if you get an error complaining about a missing Change-Id line. Matma Rex talk 20:57, 21 May 2024 (UTC)reply

I don't know whether that's a problem or not, but I proceeded as if it wasn't.

c:\php\mediawiki\core>git pull --rebase origin master
Enter passphrase for key '/c/Users/Bill/.ssh/id_ed25519':
remote: Counting objects: 11860, done
remote: Finding sources: 100% (60/60)
remote: Getting sizes: 100% (26/26)
remote: Compressing objects: 100% (108354/108354)
remote: Total 60 (delta 35), reused 35 (delta 28)
Unpacking objects: 100% (60/60), 36.46 KiB | 13.00 KiB/s, done.
From ssh://gerrit.wikimedia.org:29418/mediawiki/core

* branch master -> FETCH_HEAD

2d68215ff7a..25895192125 master -> origin/master

Successfully rebased and updated refs/heads/T12814-hello.

c:\php\mediawiki\core>git review -R
wbm1058@gerrit.wikimedia.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

If you get a Permission denied (publickey). fatal: Could not read from remote repository., review the instructions at mw:SSH keys#Add SSH Private key to use with Git to make sure your ssh agent is running and your identity is added. If you close your Git Bash shell, you will be signed out and need to re-follow these instructions each time.

c:\php\mediawiki\core>eval `ssh-agent`
'eval' is not recognized as an internal or external command,
operable program or batch file.

Is there a way to run git bash from the Windows cmd prompt?

Inside a git bash window:

Bill@Mobile-laptouch MINGW64 ~
$ eval `ssh-agent`
Agent pid 272

Bill@Mobile-laptouch MINGW64 ~
$ ssh-add ~/.ssh/id_ed25519
Enter passphrase for /c/Users/Bill/.ssh/id_ed25519:
Identity added: /c/Users/Bill/.ssh/id_ed25519 (wbm1058-wikipedia@yahoo.com)

Then I went back to Windows command window, tried "review" again, and still got the "permission denied" error. – wbm1058 (talk) 20:28, 21 May 2024 (UTC)reply

I haven't seen this exact error before, and your setup is rather different from mine, so this is a guess, but: the eval `ssh-agent` command actually works by setting environment variables, which everything else on your system can read to access the SSH agent. Maybe you just need to close and reopen the command prompt window again, so that it sees the new env variables? Matma Rex talk 21:02, 21 May 2024 (UTC)reply

"Is there a way to run git bash from the Windows cmd prompt?" You can run something like "C:\Program Files\Git\usr\bin\bash.exe" from the command prompt, and it will run, but this is unlikely to do anything good. It will probably be confused about text encodings, file paths, and ANSI escape codes. (On Windows 10, they're slightly less incompatible.) Can you say why you want to do it? Matma Rex talk 21:15, 21 May 2024 (UTC)reply

(edit conflict) I just tried doing it from my git bash window instead of command prompt...

Bill@Mobile-laptouch MINGW64 /c/php/mediawiki/core (T12814-hello)
$ git review -R
remote:
remote: Processing changes: new: 1 (\)
remote: Processing changes: new: 1 (|)
remote: Processing changes: new: 1 (/)
remote: Processing changes: new: 1 (-)
remote: Processing changes: new: 1 (\)
remote: Processing changes: new: 1 (|)
remote: Processing changes: refs: 1, new: 1 (|)
remote: Processing changes: refs: 1, new: 1 (|)
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1034588 Show the page name on the MovePage checkbox for "Yes, delete the page" NEW
remote:
To ssh://gerrit.wikimedia.org:29418/mediawiki/core.git

* new reference HEAD -> refs/for/master%topic=T12814-hello

I guess that worked?! wbm1058 (talk) 21:11, 21 May 2024 (UTC)reply

Yep, that worked. * Pppery * _{it has begun...} 21:15, 21 May 2024 (UTC)reply

Yeah, just doing everything from the Git Bash window is probably the best way to have the least amount of weird issues. Matma Rex talk 21:16, 21 May 2024 (UTC)reply

Time for a lager! Cheers! :) wbm1058 (talk) 21:25, 21 May 2024 (UTC)reply

Rebaseedit

Matma Rex, responding to your request at code review to edit another file. Per the instructions at mw:Gerrit/Tutorial#Rebasing, I clicked on the REBASE button in Gerrit's web interface, and it responded with a "Confirm rebase" box with radio buttons for "Rebase on top of the master branch" or "Rebase on a specfic change, ref, or commit". I'm unclear on which I should choose, and whether to check the "Allow rebase with conflicts" box. "It's best to make rebase updates a separate patch, so that your code reviewers have an easy time seeing what changes you've made."

"Hard reset and checkout the change with this command: (BEWARE: git review -d performs a hard reset that destroys all local changes. Stash or commit changes first which you wish to preserve!)" – what is meant by "stash" a change? That term only appears that one place on that page; it's not defined there. – wbm1058 (talk) 21:22, 22 May 2024 (UTC)reply

That patch doesn't have a merge conflict so you don't need to worry about rebasing it at all. And "stash" in that context refers to the git stash command. * Pppery * _{it has begun...} 23:17, 22 May 2024 (UTC)reply

Don't I want to amend / add a file to my existing commit rather than add a second commit to my existing branch? Branches and commits, I'm still not comfortable with the terminology and how they fit together.

Funny, when I entered 'git' to get the usage and list of "common git commands" it didn't list "stash". – wbm1058 (talk) 00:46, 23 May 2024 (UTC)reply

For gerrit and git review, yes. For patchset 2 or higher, you'll want to git stage, then git commit --amend, then git review -R –Novem Linguae (talk) 02:13, 23 May 2024 (UTC)reply

Ack, though I see the term "stage" several times in mw:Gerrit/Tutorial, I don't see any explicit "git stage" command. Oh (looking it up), that's a synonym for "git add".

I was looking at mw:Gerrit/Tutorial#Amending a change (your own or someone else's), and mw:Gerrit/Tutorial#Rebasing is a subsection of that section. The way I'm reading it, it implies that rebasing is a mandatory, not optional, step that's part of the "amending a change" process.

Oh, I see. the --amend tells it to amend my first commit rather than add a second commit. – wbm1058 (talk) 03:02, 23 May 2024 (UTC)reply

I think if you do git review without the -R, it will auto rebase. But i was taught not to auto rebase, and just to do it manually when needed. –Novem Linguae (talk) 03:05, 23 May 2024 (UTC)reply

I think a few things on that tutorial page are outdated – both Gerrit and git-review have had some changes related to rebases since it was written, and they mostly removed the footguns that this page tries to teach you to avoid. I'll have to read it more carefully and update it. Generally, you shouldn't have to think about rebasing, or do anything to avoid it, or click the "Rebase" button, unless you see an error somewhere telling you that there is a merge conflict in your change. Matma Rex talk 15:48, 23 May 2024 (UTC)reply

Thanks, that makes sense. In baseball, a runner taking a big lead off first base sometimes needs to rebase when he sees a pitch conflict (pitch going to first base rather than home plate). Ha! wbm1058 (talk) 17:14, 23 May 2024 (UTC)reply

I removed all of the bad and outdated advice from that section: 2345 and added some good advice instead: 6. Hope that helps explain it. I concede that it is not entirely unlike baseball. Matma Rex talk 23:14, 24 May 2024 (UTC)reply

I recently noticed that the CSS style background:transparent seems to turn the text color dark gray when combined with the class thumbinner and viewed through the beta vector night mode. Does anyone know why this happens? Andumé (talk) 20:12, 20 May 2024 (UTC)reply

The text color generally is a dark grey. Can you be more specific ? —TheDJ (talk • contribs) 09:58, 21 May 2024 (UTC)reply

In general however, if you define a background color, you should ALWAYS define a text color and vice versa, if you want to avoid problems with night/dark mode. —TheDJ (talk • contribs) 10:00, 21 May 2024 (UTC)reply

In dark mode, there is some blanket CSS for "it has a background but is relying on inherited color" which obviously doesn't work in a lot of places. Izno (talk) 17:13, 21 May 2024 (UTC)reply

Link classifier missing in Vector 2022edit

The Link Classifier which if I recall is maintained by Anomie has disappeared from my Vector (2022) skin. I use this frequently and have just now noticed it, so I is likely something very recent. I switched back to Vector (2010) just to check and it was still available there. Any suggestions about how to get this back in Vector (2022)? older ≠ wiser 21:29, 20 May 2024 (UTC)reply

WMF has recently changed the software so that in Vector 2022 personal Javascript/CSS are loaded only from Special:MyPage/vector-2022.js and Special:MyPage/vector-2022.css. You are loading it only in Special:MyPage/vector.js. You will need to copy whatever you want from there to the vector-2022 version, or to your Common.js at Special:MyPage/common.js (which is the best place for it - scripts are/should be responsible for loading where they should; styles may vary more so they may not be as obvious to move). Remove it from vector.js if you add it to common.js. Izno (talk) 22:06, 20 May 2024 (UTC)reply

Thank you. That worked. older ≠ wiser 23:40, 20 May 2024 (UTC)reply

Thanks, this probably should solve the above problem as well. I will try later today. Ymblanter (talk) 08:36, 21 May 2024 (UTC)reply

Copied Ymblanter's comment from above:

Not sure whether it is related but I am using one of the user scripts (do not have time now to search which one) which, in particular, highlights in pink pages proposed for deletion. The highlighting is gone today (checked on two different devices, different browsers), which gives me a HUGE headache for CFD handling. Ymblanter (talk) 08:35, 21 May 2024 (UTC)

Izno (talk) 17:09, 21 May 2024 (UTC)reply

Prompt for edit summary on rollback from watchlist?edit

Hi there, long time fan, first time caller...

I very much like having a link on my watchlist page that will allow me to perform rollback while prompting me for a custom edit summary. My JS pages were a bit of a mess, but I believe I'd been using User:Nageh/rollbackSum.js for this purpose.

Earlier this week the 'sum' links provided by that script disappeared for me. Nageh (talk · contribs) hasn't edited since 2014 and, while I tried a few other scripts that I found, none of them seemed to re-add such a link to my watchlist either. Has something changed that makes this no longer possible? The ability to add a custom edit summary when doing rollback from my watchlist is very valuable to me, so it would be a shame if the upshot was that this simply is no longer possible. Thanks for your help! DonIago (talk) 03:43, 24 May 2024 (UTC)reply

@Doniago, see section header of which I've made your question a subsection. Izno (talk) 15:27, 24 May 2024 (UTC)reply

Thanks Izno. I've tried copying a version of rollback.js to my common.js page with no evident change at this time. DonIago (talk) 16:12, 24 May 2024 (UTC)reply

The line above it has no ; and misspells importScript with a lowercase s. This may or may not cause issues. Izno (talk) 16:32, 24 May 2024 (UTC)reply

Thanks Izno! I'm not sure which of the changes I made per your notes fixed it, but it seems to be fixed! DonIago (talk) 16:55, 24 May 2024 (UTC)reply

MediaWiki message delivery 23:01, 20 May 2024 (UTC)reply

Based on a quick search, it looks like the heading change will affect almost 300 scripts, many of which have inactive maintainers. Some arbitrary highlights from the top of the list include:

• Awesome Aasim's User:Awesome Aasim/rcpatrol.js
• BrandonXLF's User:BrandonXLF/FFUHelper.js
• Cacycle's User:Cacycle/wikEd.js, User:Cacycle/wikEd dev.js, and User:Cacycle/wikEd.user.js
• DannyS712's User:DannyS712/DiscussionCloser.js, User:DannyS712/SectionRemover.js, and User:DannyS712/SectionMover.js
• Enterprisey's User:Enterprisey/reply-link.js, User:Enterprisey/copy-section-link.js, User:Enterprisey/archiver.js, User:Enterprisey/strike-archived.js, User:Enterprisey/section-watchlist.js, and User:Enterprisey/section-redir-note.js
• Equazcion's User:Equazcion/OneClickArchiver.js, User:Equazcion/TeahouseRespond.js, and User:Equazcion/NewSectionSummary.js
• Evad37's User:Evad37/OneClickArchiver.js and MediaWiki:Gadget-XFDcloser-core.js
• Mr. Stradivarius's User:Mr. Stradivarius/gadgets/SignpostTagger.js
• PhantomTech's User:PhantomTech/scripts/AFCRHS.js
• SD0001's User:SD0001/RFUD-helper.js
• Terasail's User:Terasail/COI Request Tool.js
• Technical 13's User:Technical 13/Scripts/OneClickArchiver.js
• The Earwig's User:The Earwig/permalink.js and User:The Earwig/afc-helper.js
• The Evil IP address's User:The Evil IP address/hdedit.js

Plus many, many more. --Ahecht (TALK
PAGE) 19:22, 21 May 2024 (UTC)reply

A quick way to test these scripts right now, is to enable the Parsoid beta option (which already uses the new html structure) and to disable DiscussionTools, which uses a partial form of the new heading structure. —TheDJ (talk • contribs) 08:39, 22 May 2024 (UTC)reply

Indeed, you can already see it in Parsoid mode (but note that there are other differences – e.g. Parsoid output has <section> tags around each section, which may require a separate set of updates in some scripts).

Disabling DiscussionTools doesn't actually change anything though. The HTML structure is the same whether it's enabled or disabled, only the styles are different. Also, note that it uses a "hybrid" heading structure currently when using the default parser, as you say, but it uses the new structure when using Parsoid.

So in short, you can just use Parsoid mode to test these scripts today here on English Wikipedia, but beware that there may be extra issues. But if they work with Parsoid, they will work with the new headings too. Matma Rex talk 11:25, 22 May 2024 (UTC)reply

The technical 13 script was blanked, so we don't have to worry about that one.

Will the fact that they're rolling this out for only some wikimedia-deployed skins at this time make the patch more complicated? If I'm reading it right, the scripts may temporarily have to support both heading styles. –Novem Linguae (talk) 09:16, 22 May 2024 (UTC)reply

Yes, it does, and they have to. Matma Rex talk 11:20, 22 May 2024 (UTC)reply

At a glance, it seems that User:Mr. Stradivarius/gadgets/SignpostTagger.js already supports the new style, as it uses $( '#bodyContent h2:first' ).text() as a backup if $( '#bodyContent h2:first span.mw-headline' ) doesn't exist (line 291). — Mr. Stradivarius ^{♪ talk ♪} 13:09, 22 May 2024 (UTC)reply

Fixed RFUD-helper. Thanks for the ping. – SD0001 (talk) 18:33, 22 May 2024 (UTC)reply

This is going to break both my edit request scripts, I will try to fix them at the weekend. Terasail^✉️ 18:41, 22 May 2024 (UTC)reply

I'm trying to create some info-boxes on a small hobby wiki. It had been running fine on "freewiki.in" but that domain disappeared last year. I've re-created it on a domain I control using MediaWiki v1.41.1. I've put up all the article text from .XML backups, but all the formatting is gone.
The software manual at https://www.mediawiki.org?pojem=Global_templates/Taxonomy explains how to use {{ambox}} but not the code required for it to work. It sends me to Wikipedia, to https://en.wikipedia.org?pojem=Module:Message_box. That, finally, has 600+ lines of code.
Where does this code go? Somewhere on the wiki? Somewhere on the server in one of the .PHP files? There's gotta be a step-by-step procedure somewhere but I can't find it. And I'm not about to do my experimenting here on Wikipedia...
Answers can be here, if this is of general interest. If not, I'd be perfectly happy getting help at my talk page. SandyJax (talk) 13:05, 21 May 2024 (UTC)reply

It goes exactly where it is here, on the page Module:Message box. Snowmanonahoe (talk · contribs · typos) 16:42, 21 May 2024 (UTC)reply

... but otherwise requires only the use of mw:Extension:Scribunto and mw:Extension:TemplateStyles. Izno (talk) 17:08, 21 May 2024 (UTC)reply

If you preview code, e.g. an infobox call, then the bottom of the window shows all transcluded templates and modules at "Templates used in this preview". It can be a long list, and the list can change if the same template is called with different parameters or circumstances (e.g. the namespace it's called from). Some of the infobox styling in the English Wikipedia is in MediaWiki:Common.css which is not listed at "Templates used in this preview" since it's not transcluded but used in another way. PrimeHunter (talk) 18:30, 21 May 2024 (UTC)reply

Resolved

Immediate assistance required because template:dagger currently outing this †. Anoop Bhatia (talk) 01:14, 22 May 2024 (UTC)reply

Link to an edit request about it: Template talk:Dagger#Template-protected edit request on 22 May 2024. – 2804:F1...10:A60F (talk) 02:37, 22 May 2024 (UTC)reply

It is not malfunctioning, it is doing what it is supposed to do, to notify everyone about the ongoing discussion. But I can see how this can be disruptive to the reading experience when it is being used multiple times within a short space, i.e. at Atlanta Braves#Braves Hall of Fame. – robertsky (talk) 03:45, 22 May 2024 (UTC)reply

@Robertsky: Thanks 👍🏻. Anoop Bhatia (talk) 04:03, 22 May 2024 (UTC)reply

SUBJECT

The IPA in Wikipedia comes with some errors.

I am quite happy that Wikipedia uses the IPA as a pronunciation guide. I know the IPA moderately well, so its use is convenient for me. Promoting the IPA in Wikipedia might also encourage people to learn it, which probably might not be a bad idea.

I think that the use of the IPA in Wikipedia might often or consitently make some errors. I don’t see these errors being made in Wiktionary though. The IPA there seems to be largely fine.

the approximant rhotic (also the approximant alveolar)

/ɹ/

The English language uses primarily for a rhotic the approximant alveolar which in the IPA is represented as: /ɹ/.

In Wikipedia, this rhotic seems to always get represented by /r/, which actually represents the rolled “r”, as the “r” in the Spanish word “perro”.

I’ve suspected that this error is deliberate in that maybe the people setting up the IPA transcriptions are concerned that an upside down “r” might confuse people. Although, this doesn’t make very good sense since much of the rest of the IPA will still confuse people who are not familiar with it.

From Wikipedia showing the incorrect /r/ use :

Tripoli (/ˈtrɪpəli/; Arabic: طرابلس الغرب, romanized: Ṭarābulus al-Gharb, lit. 'Western Tripoli')

From Wiktionary using the correct /ɹ/. use :

entourage

Pronunciation

(UK) IPA(key): /ˈɒn.tʊ.ɹɑːʒ/, /ˈɑ̃ː.tʊ.ɹɑːʒ/

(US) IPA(key): /ˈɑn.tə.ɹɑʒ/

/ɑ/, /a/, /æ/

These might be described as the “basic a” vowels: /ɑ/, /a/, /æ/

/a/ and /æ/ are similar and are like the “a” in “cat”.

/a/ is more open and might be more typical for Received Pronunciation or a British English. /æ/ is similar sounding but just with an articulation that is a bit more close (closed jaw) and is probably more typical for General American English or Standard Canadian English. Distinguishing between these two is not too much of a big deal, I don’t think for general pronunciation purposes.

The /ɑ/, described as a back, open, unrounded vowel, is like the “o” in the English word “top”. This vowel is more of what is considered an “a” vowel in languages such as Spanish, Italian, and other languages. This /ɑ/ though is significantly different from the /a/ and /æ/. Zdroj:https://en.wikipedia.org?pojem=Wikipedia:Village_pump_(technical)
Text je dostupný za podmienok Creative Commons Attribution/Share-Alike License 3.0 Unported; prípadne za ďalších podmienok. Podrobnejšie informácie nájdete na stránke Podmienky použitia.