MediaWiki talk:Gadget-markblocked.js

Line 62

The case conversion at this line is inconsistent with the case conversion that MediaWiki does. See [1]. This should use something like new mw.Title(user).getMain() instead. A manifestation of this issue can be found at Wikipedia:Sockpuppet investigations/あすぺるがあすぺしゃりすと, where some accounts are not marked as blocked, but they are actually blocked. 0xDeadbeef→∞ (talk to me) 03:42, 10 December 2023 (UTC)

Starting edit request. Please replace

user = user[2].slice(0, 1).toUpperCase() + user[2].slice(1);

with

user = new mw.Title(user[2]).getMain().replace('_', ' ')

0xDeadbeef→∞ (talk to me) 09:26, 14 December 2023 (UTC)

 Done * Pppery * _{it has begun...} 16:28, 14 December 2023 (UTC)

@0xDeadbeef, since we were the ones talking, I'm guessing this change seems to have had the effect of making some other accounts not highlighted, see e.g. Jay Shree Ram Ji at Bikrookanpurgangster and Steph at Unipet at Anne Barrington.... :( Izno (talk) 19:00, 14 December 2023 (UTC)

I think it's names with multiple spaces. One space is fine but two or more seems to be causing this effect. Izno (talk) 22:23, 14 December 2023 (UTC)

Oh oops, changing replace to replaceAll should fix this. 0xDeadbeef→∞ (talk to me) 22:37, 14 December 2023 (UTC)

@0xDeadbeef, replaceAll is from ES2021. Izno (talk) 22:51, 14 December 2023 (UTC)

Ah, sorry as I am currently on my phone, maybe https://stackoverflow.com/a/1144788 would work? 0xDeadbeef→∞ (talk to me) 22:58, 14 December 2023 (UTC)

@0xDeadbeef, it's not critical :), just post a TPER whenever you have a minute on a real computer. Izno (talk) 23:08, 14 December 2023 (UTC)

mw.Title already provides a method to output spaces instead of underscores. Try user = mw.Title.newFromText( user[2] ).getMainText(); (restored the semicolon). Nardog (talk) 00:51, 15 December 2023 (UTC)

It works! Izno (talk) 04:08, 15 December 2023 (UTC)

Um, take out new . Nardog (talk) 04:12, 15 December 2023 (UTC)

Gadget making my browser flip out when loading page history

If this is the code behind "Strike out usernames that have been blocked", when I have it enabled, a page history like this loads in a very unstable manner, sometimes making my browser flip around and sometimes minimize, almost like it has temporarily crashed. I have been using the gadget for a long time, but it has seemed like I've been having problems with this for months. I wish I could pinpoint when the issue started happening. For now, I'm keeping it disabled although I found it quite useful when dealing with vandalism and such. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:21, 9 June 2024 (UTC)

Try temporarily disabling all your user scripts (by blanking common.js) and see if the problem goes away. If so, it may be interacting with a user script in a bad way. Also, what browser, skin, and default # of history entries? I was unable to replicate on Chrome, Vector 2010, and 500 history entries using your example page Medical_school history. –Novem Linguae (talk) 08:36, 9 June 2024 (UTC)

I already took a number of hours today disabling everything one by one, including extensions and all scripts, and narrowed it down to this one. The problem only occurs when this gadget is turned on. I am using Chrome (latest), with skin Vector 2022. The default # of history entries is 1,000, but there is no problem listing that many usually. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 09:18, 9 June 2024 (UTC)

https://en.wikipedia.org/w/index.php?title=Medical_school&action=history&limit=1000&useskin=vector-2022

Unable to reproduce. I wonder if anyone else will chime in here having the same problem.

If you ever have to figure out what script is causing a bug in the future, you can use a technique called "bisecting", where you disable half at one time and see if that fixes it. If so, disable half of that half, etc. until you are down to the offending script. Should be quicker than going one by one.

How are your computer specs? Do you have a 64 bit operating system? Do you have like >8 GB RAM? Loading a page with 20 user scripts and 1000 history entries could be a bit computationally expensive. –Novem Linguae (talk) 10:03, 9 June 2024 (UTC)

I did some degree of bisecting along the way where it was more straightforward to keep track of what I turned off and on. Also, I have a 2022 Intel-based PC with Windows 11 (64-bit), a 12-core processor and 24 GB RAM. I have no issue with performance outside of this matter. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:16, 9 June 2024 (UTC)

Further, with this gadget turned off, I see the couple-second hit of my other scripts when the history page loads - but that is an expected hit and the browser doesn't freak out. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:18, 9 June 2024 (UTC)

I just did a fresh test to confirm the issue. I did a load of the above history page. Loaded reasonably as expected. I turned this gadget on in Preferences. Did Ctrl-Shift-R on the history page. The browser as before, flips out for 1-2 minutes before settling down. I turned this gadget off in Preferences. Did Ctrl-Shift-R on the history page. Loaded reasonably as expected. It's always possible this gadget has a conflict with something else, but there's no question I have to keep it turned off to keep the problem from surfacing. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 17:31, 9 June 2024 (UTC)

I don't have anything weird happen on my computer -- I have the same thing enabled and I'm using Firefox on Fedora. jp×g🗯️ 10:55, 10 June 2024 (UTC)

Looking at this with fresh eyes - the following measures didn't make the problem go away:

1. Optimized common.js to better control when scripts load.
2. Turned off all my browser extensions.
3. Commented out all scripts in common.js and vector-2022.js

So what's left is apparently this gadget has a conflict with another gadget, beta or otherwise preference setting. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:40, 10 June 2024 (UTC)

I have just ruled out conflicts with other gadgets and betas as far as ones I'm using. So I'm left with a preference setting somewhere potentially in conflict. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 23:30, 10 June 2024 (UTC)

It also doesn't seem to have any conflicts with Appearance preference settings. I also checked against selected other settings but nothing so far has turned up. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 03:20, 11 June 2024 (UTC)

If anyone has any ideas for something I can check, please let know. I'm going to give up on this for now, as I need to move on to other things. But for the time-being, I am not going to keep the gadget enabled in my setup, as the trippy page loads are just getting on my nerves. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 03:35, 11 June 2024 (UTC)

@StefenTower: Sorry to have been useless here, but know that you have my sympathy with whatever ends up being the problem with this bizarre inexplicable bug -- many such cases, I'm afraid. jp×g🗯️ 08:42, 11 June 2024 (UTC)

@StefenTower Try disabling the gadget in your preferences and loading it via common.js rather than ResourceLoader:

mw.loader.load("//en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markblocked.js&action=raw&ctype=text/javascript");

I once came across a gadget that didn't work properly for certain users, and the approach above somehow circumvented the issue. Although the exact mechanism remained unclear, this suggested that ResourceLoader could do some harm depending on your computer/browser environments. Note that if this approach works for you, we expect that the approach below won't work:

mw.loader.load("//en.wikipedia.org/w/load.php?modules=ext.gadget.markblocked");

Dragoniez (talk) 05:48, 17 June 2024 (UTC)

Thank you for the idea. I tested it, and the problem I'm experiencing is the same as before. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 18:47, 17 June 2024 (UTC)

Sorry to hear that it didn't work. It now seems that your situation is attributed to the gadget itself, not to how the script is loaded. Dragoniez (talk) 08:08, 18 June 2024 (UTC)

@StefenTower I got another clue of the cause of your situation. Enable the gadget, visit Special:Log/block, press F12 on your keyboard, navigate to the console, and see if there's any yellow/red warning. You might have something like Uncaught TypeError: Cannot read properties of undefined (reading 'newFromText'). (You might also want to check the console on pages where you experience the buggish bahaviour). Dragoniez (talk) 17:42, 1 July 2024 (UTC)

On Special:Log/block, I see:

• A single warning This page is using the deprecated ResourceLoader module "jquery.ui". Please use Codex instead.
• A single error Uncaught TypeError: Cannot read properties of undefined (reading '0')
• Hundreds of warnings saying Third-party cookie will be blocked in future Chrome versions as part of Privacy Sandbox.
• A single error Uncaught (in promise) Error: A listener indicated an asynchronous response by returning true, but the message channel closed before a response was received

Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:31, 2 July 2024 (UTC)

On the history page above I used to report this issue, I'm seeing the same errors/warnings, except the last one. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:34, 2 July 2024 (UTC)

With the gadget turned off, I'm seeing the same errors/warnings, except the last one. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:36, 2 July 2024 (UTC)

Just doing a normal test, I seems like the June 30 fixes fixed the problem I was seeing. No flipping out in the web browser. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:42, 2 July 2024 (UTC)

@StefenTower Glad to hear the issue's been somehow resolved (I really wonder how, though).
As for the console messages, none of them suggests that the gadget's doing harm on your browser experience. #1 is nothing (for our purposes), #3 is just a notice from Chrome, #4 is something that we see everywhere on MediaWiki-powered sites. #2 is something you might want to look into, although it presumably has nothing to do with the gadget, as far as I can tell from your reports. There are some clickable elements around the error message, and via them you can actually figure out which script is throwing the error.
Anyway, I had suspected that the issue had to do with the gadget failing to load the mediawiki.Title module properly (along with a bunch of other things that can be improved in the coding). I think I'll propose an overhaul when I have time. Dragoniez (talk) 07:49, 2 July 2024 (UTC)

Uncaught TypeError: Cannot read properties of undefined (reading '0') indicates something is broken. If you look to the right of it, or you click on the arrow to expand it, you may be able to figure out the exact user script or gadget that is broken. It may or may not be markblocked. If we can figure out which script this is, next step would be to post a bug report on that script's talk page.

I had suspected that the issue had to do with the gadget failing to load the mediawiki.Title module properly. Well spotted. I've made this edit to hopefully fix it.

What other ideas did you have in mind for an overhaul? If there's any more safe/quick/easy ones like this, I can look into making them. –Novem Linguae (talk) 12:17, 2 July 2024 (UTC)

The Uncaught TypeError came from a browser extension Typio Form Recovery. It didn't cause the problem I reported here, as it was alleviated even with that extension active, and I had already replicated the issue with all browser extensions turned off at an earlier time. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 16:02, 2 July 2024 (UTC)

Refactoring

@Novem Linguae Thanks so much for the edit. It's going to be long and I'm not ready to spell everything out, but an easy one is that in line 22, the jQuery function is called on a jQuery object (maybe you can replace $( container ) with $content or something, then search for container in the page and replace every occurrence of it with $content). I think the mistake is due to the unconventional naming of the variable. Dragoniez (talk) 13:14, 2 July 2024 (UTC) Oh, and another one, the mediawiki.api module isn't used anywhere. Dragoniez (talk) 13:15, 2 July 2024 (UTC)

 Done –Novem Linguae (talk) 16:43, 2 July 2024 (UTC)

Better add mediawiki.Title to MediaWiki:Gadgets-definition for performance then. Nardog (talk) 13:22, 2 July 2024 (UTC)

 Done –Novem Linguae (talk) 16:38, 2 July 2024 (UTC)

OK, I poked at this for awhile today and got some refactoring done. This gadget is pretty easy to test by visiting https://en.wikipedia.org/wiki/Special:Log?type=block&debug=1, so I can refactor fairly boldly compared to some other gadgets. Let me know if y'all have additional ideas. –Novem Linguae (talk) 18:14, 2 July 2024 (UTC)

$( link ) is repetitive. Declare const $link = $( link ); as Andrybak suggested below.

That said,

if ( $( link ).is( '.mw-changeslist-date, .ext-discussiontools-init-timestamplink, .mw-history-undo > a, .mw-rollback-link > a' ) ) {
	return;
}

could be simplified to

.not( '.mw-changeslist-date, .ext-discussiontools-init-timestamplink, .mw-history-undo > a, .mw-rollback-link > a' )

either after $container.find( 'a' ) or before .each( ( i, link ) => { Nardog (talk) 03:39, 3 July 2024 (UTC)

 Done –Novem Linguae (talk) 04:17, 3 July 2024 (UTC)

Come to think of it, each could be filter with return true at the end and .addClass( 'userlink' ) after that. That way $link isn't needed at all (with getAttribute in place of attr). Nardog (talk) 04:27, 3 July 2024 (UTC)

I'll post my version once. Forked from yesterday's version (2024-07-02T18:10:38). Details:

1. mw.loader.using (Special:Diff/1232299818)

   I once came across a situation where a newly-created gadget adapted from a user script failed to load modules in the absence of mw.loader.using although they were written out in gadgets-definition. This is a story back in August 2022 so there might have been some updates in ResourceLoader, but it'd still be safer to manually load dependent modules.

2. mbNoAutoStart (Special:Diff/1232301972)

   This is related to the generation of a portlet link and this requires the DOM and mw.util to be ready. But the relevant codes have been placed before the module loader since long ago. Also, when the config is set to true, the current version doesn't work on minerva because the skin doesn't have #p-cactions.

3. Array.prototype.includes (Special:Diff/1232302154)

   I think it's better to limit ourselves to ES6 and use Array.prototype.indexOf instead of Array.prototype.includes because it's an ES2016 feature. (+There's a redundant space in wgAction)

4. Aliases for Special:Contributions (Special:Diff/1232302154/1232323879)

   [[internal wikilink]]s are converted to <a /> tags by the wikitext parser, and special page names that occur in them are translated to the canonical special page name in their hrefs:

   • [[Special:Contribs/Dragoniez]] => /wiki/Special:Contributions/Dragoniez

   This is why user links like above are marked up without any issues. But, this is not the case for [external link]s:

   • [//en.wikipedia.org/wiki/Special:Contribs/Dragoniez] => .../wiki/Special:Contribs/Dragoniez

   Because of this, special page aliases should be fully specified with a regex. This is also motivated by the fact that it is pretty common to use (domain-internal) external links in templates and lua modules, in combination with the plainlinks class.

   (TODO) And, although below is complicated and not easy, it'd be better to collect aliases for special: from wgNamespaceIds and separate them from window.markblocked_contributions. Otherwise, users who import this gadget will have to specify a regex string rather than a plain string, e.g. Speciale?:(?:Edit|Contrib(?:ution)?s|Contributi(?:Utente)?) for the Italian Wikipedia. What worsens the issue is that there must not be any capturing group in the regex string, otherwise the return value of RegExp.prototype.exec in getUserLinks will be messed up. So, the config value should rather be an array of plain strings. But as I said, it's not easy to make this change because we would have to go to a bunch of other wikis to update user configs, and this can only be done by global interface editors.

   • Helper code to fetch aliases for Contributions (can be copied and pasted into the console):

   new mw.Api().get({
   	action: 'query',
   	meta: 'siteinfo',
   	siprop: 'specialpagealiases',
   	formatversion: '2'
   }).then((res) => {
   	const aliases = (res?.query?.specialpagealiases || []).filter((obj) => obj.realname === 'Contributions')[0]?.aliases;
   	console.log(aliases);
   });
   

5. mw.Api refactoring (Special:Diff/1232328093)

   Nothing special here. I also moved up regex declarations because they needn't be initialized every time we collect user links. I've also noticed that $( this ).attr( 'href' ) is a bit tricky.

Still midway but I'll stop updating my version for now. Dragoniez (talk) 05:36, 3 July 2024 (UTC)

Array.prototype.includes can be used as we now require ES2017. Nardog (talk) 05:58, 3 July 2024 (UTC)

While it won't break the minifier in this case because it's not unique syntax, technically we shouldn't be writing above ES6 if we want to follow mw:Compatibility#General information for the modern layer. Although I'm not thrilled about writing ancient code all the time, and sometimes I forget. Maybe locally I should turn back on the es-x linter rules that I disabled. –Novem Linguae (talk) 06:42, 3 July 2024 (UTC)

It's not about the minifier. MW already stops running JavaScript if the browser doesn't support ES2017. Nardog (talk) 08:12, 3 July 2024 (UTC)

My rationale behind #3 is that we should use a JS version compatible with as many browsers as possible, especially in gadgets. Now that MediaWiki has started using ES6, there's no point in writing scripts in ES5, but it would still be better to avoid using versions beyond ES6, in my opinion. Dragoniez (talk) 08:28, 3 July 2024 (UTC)

MediaWiki core itself uses Array includes(). The ES version from mw:Compatibility is only a baseline requirement. Any feature that is supported in all ES6 browsers – such as Array includes() – is safe to use. There are even some ES2018 features like Promise.finally which are not just supported but also required. – SD0001 (talk) 18:11, 6 July 2024 (UTC)

Are you sure? eslint-config-wikimedia has a rule called "es-x/no-array-prototype-includes" that is set to warn for this. Because the official linter complains about using >ES6, I think this is good evidence that we are not supposed to do it.

Any feature that is supported in all ES6 browsers – such as Array includes() – is safe to use. I don't think Array.includes() is part of ES6. I think it is part of ES7. –Novem Linguae (talk) 18:24, 6 July 2024 (UTC)

Yes, it is of ES7 - ECMAScript version history#7th Edition – ECMAScript 2016. We should write code compatible to what the official Wikimedia guidelines say. — DaxServer (t·m·e·c) 19:30, 6 July 2024 (UTC)

I didn't mean to imply it's part of ES6, just that it is supported in all ES6 supporting browsers.

What ES version it was added in doesn't really matter – mw:Compatibility#Browser_support_matrix specifically lists the browsers that are supported. If a function is implemented in all of them, IMO we should use it. – SD0001 (talk) 20:44, 6 July 2024 (UTC)

No JavaScript modules will run in a browser that does not support Promise.prototype.finally, so if this gadget executes at all, Array.prototype.includes is all but guaranteed to be supported. It's pointless to avoid it. Nardog (talk) 14:59, 7 July 2024 (UTC)

 Done for #1 and #3. Holding off on #2, #4, #5 due to complexity and merge conflicts. If you want, we can talk about these one at a time. So for example #2... sounds like this fixes a bug in minerva? What are the steps to reproduce? Feel free to rebase it. –Novem Linguae (talk) 07:14, 3 July 2024 (UTC)

Sorry for the complexities. Try adding window.mbNoAutoStart = true; to your commonjs, and see if the intended portlet link will be generated on different skins. It won't on minerva because there's no #p-cactions on it, meaning that mw.util.addPortletlink returns null.
I'll decompose #2 into 4 steps:

1. Move up mw.util.addCSS (stylistic; Special:Diff/1232342761)
2. Separate the hook handler as a function (Special:Diff/1232343621)
3. mw.util.addPortletlink should be placed inside $.when, which loads the DOM and modules. (Special:Diff/1232343914)
4. Add a null handler for mw.util.addPortletlink. (Special:Diff/1232344339)

This is an overview of what I wanted to suggest in #2 above. Dragoniez (talk) 08:05, 3 July 2024 (UTC)

When I mentioned "overhaul", I had (and still have) an idea of adding a new feature to mark up blocked IP ranges as well (in a way that won't affect performance, unlike #Interface-protected edit request on 29 October 2022). But this idea, along with my #4 point above, may seem to be beyond the scope of "refactoring", so I'll hold off discussing them further until we've finished the refactoring. Dragoniez (talk) 22:52, 5 July 2024 (UTC)

I won't have much time in the coming weeks and will probably not be able to get to this. You may want to use {{IAER}} to attract additional interface admins, who can review your code and deploy your changes. Thanks for your work on this. –Novem Linguae (talk) 03:16, 19 July 2024 (UTC)

@Novem Linguae I appreciate all your help. During our discussion here, Tech news has started to mention Temporary Account more frequently, and we will probably need to update this gadget once the feature is rolled out. I've started to think we can put off the refactoring until then (and I've also started to feel a bit sorry for having to ask for edits repeatedly. I kind of wish enwiki could grant non-sysops interface-admin rights; just talking to myself). Dragoniez (talk) 14:14, 23 July 2024 (UTC)

Temporary accounts may work without modifications. To the gadget, temporary accounts may just look like regular accounts. There's only a couple javascript functions affected. There's an upgrade guide somewhere on mediawiki wiki.

You can make lots of IAER requests without feeling bad. Just do it one at a time, and in bite size chunks. –Novem Linguae (talk) 19:41, 23 July 2024 (UTC)

Alright, will do, one by one and little by little. Dragoniez (talk) 06:41, 24 July 2024 (UTC)

Just a suggestion - would you prefer making the changes using git? This is kind of what git is built for. If so, I can set up a repo on https://gitlab.wikimedia.org/repos/gadgets. SDZeroBot 13 can then configured to auto-request on-wiki edits as and when new commits are pushed to gitlab. – SD0001 (talk) 06:49, 24 July 2024 (UTC)

@SD0001 That sounds like a great idea. Could you set that up? Thanks. Dragoniez (talk) 06:58, 24 July 2024 (UTC)

Done, https://gitlab.wikimedia.org/repos/gadgets/markblocked. You don't appear to have a gitlab account, though. You can create one by going through mw:GitLab/Workflows/Registering an account on GitLab. Once it's approved, ping me and I'll add access for you to the repo. – SD0001 (talk) 07:06, 24 July 2024 (UTC)

@SD0001 Just got an email that says I've been approved. I made my dev account long ago to run a bot on Toolforge but it appears like I didn't hook it up to gitlab back then. Dragoniez (talk) 08:43, 24 July 2024 (UTC)

Access added. Also configured SDZeroBot to try keep onwiki in sync with the main branch – edit requests are raised hourly, and only when there's no existing edit request open on the page. – SD0001 (talk) 09:43, 24 July 2024 (UTC)

while we're at it, add

{
	headers: {
		'Promise-Non-Write-API-Action': 'true'
	}
}

perhaps when switching to mw.Api. See mw:API:Etiquette#Other notes. Nardog (talk) 11:36, 3 July 2024 (UTC)

But we are not POSTing? — DaxServer (t·m·e·c) 14:16, 3 July 2024 (UTC)

Yes we are. 50 user names would be too long for GET. Nardog (talk) 23:39, 3 July 2024 (UTC)

Blimey, I failed to notice the $.post.. lol — DaxServer (t·m·e·c) 08:42, 4 July 2024 (UTC)

Return of the flip-out

Now, some change since yesterday has my browser flipping out again on history pages and it is this gadget. Turned off again. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:19, 3 July 2024 (UTC)

We temporarily removed and then re-added mw.loader.using. It might be fixed again. Feel free to retry if you want. –Novem Linguae (talk) 21:58, 3 July 2024 (UTC)

Retried. Still flipping out. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:22, 3 July 2024 (UTC)

Load mediawiki.util first

Please replace the entire content with that of Special:Permalink/1232344339 (diff, details). This fix addresses the problem of mw.util.addPortletLink being called before the mediawiki.util module is loaded, and provides a way to start the script when mbNoAutoStart is enabled, even on skins that lack #p-cactions (like minerva). Dragoniez (talk) 06:41, 24 July 2024 (UTC)

 Not done for now: See #Sync request 24 July 2024. Feel free to followup upstream. Izno (talk) 21:45, 28 July 2024 (UTC)

Timestamps being decorated

With the changes to the timestamps to make them permalink links, (see: meta:Tech/News/2024/26), all timestamps on user talk pages are being decorated when visiting blocked users' talk pages. The timestamps should not be decorated. – robertsky (talk) 02:19, 28 June 2024 (UTC)

• I remember I fixed this for MarkBLockedGlobal on ja:Special:Diff/99120922. Please make the following change:

  if ( $( link ).hasClass( 'mw-changeslist-date' ) || $( link ).hasClass( 'ext-discussiontools-init-timestamplink' ) || $( link ).parent( 'span' ).hasClass( 'mw-history-undo' ) || $( link ).parent( 'span' ).hasClass( 'mw-rollback-link' ) ) {
  	return;
  }
  

  This will do the job. (Note: It's better to have a variable for $( link ) because there's no need to call the jQuery function multiple times and this is inefficient.) Dragoniez (talk) 15:08, 29 June 2024 (UTC)

With the variable suggestion:

	$contentLinks.each( ( i, link ) => {
		const $link = $( link );
		if ( $link.hasClass( 'mw-changeslist-date' ) || $link.hasClass( 'ext-discussiontools-init-timestamplink' ) || $link.parent( 'span' ).hasClass( 'mw-history-undo' ) || $link.parent( 'span' ).hasClass( 'mw-rollback-link' ) ) {
			return;
		}
		url = $link.attr( 'href' );
		if ( !url ) {
			return;
		}
		const articleMatch = articleRegex.exec( url ),
			scriptMatch = scriptRegex.exec( url );
		if ( articleMatch ) {
			pageTitle = articleMatch[ 1 ];
		} else if ( scriptMatch ) {
			pageTitle = scriptMatch[ 1 ];
		} else {
			return;
		}
		pageTitle = decodeURIComponent( pageTitle ).replace( /_/g, ' ' );
		user = userTitleRegex.exec( pageTitle );
		if ( !user ) {
			return;
		}
		const userTitle = mw.Title.newFromText( user[ 2 ] );
		if ( !userTitle ) {
			return;
		}
		user = userTitle.getMainText();
		if ( ipv6Regex.test( user ) ) {
			user = user.toUpperCase();
		}
		$link.addClass( 'userlink' );
		if ( !userLinks[ user ] ) {
			userLinks[ user ] = [];
		}
		userLinks[ user ].push( link );
	} );

—⁠andrybak (talk) 15:22, 29 June 2024 (UTC)

Can be simplified to if ( $link.is( '.mw-changeslist-date, .ext-discussiontools-init-timestamplink, .mw-history-undo > a, .mw-rollback-link > a' ) ) { Nardog (talk) 01:12, 30 June 2024 (UTC)

 Done * Pppery * _{it has begun...} 15:14, 30 June 2024 (UTC)

I am not now getting a javascript error practically every second. line 10 > eval at line 2: Uncaught ReferenceError: $link is not defined. HouseBlaster (talk · he/they) 15:23, 30 June 2024 (UTC) (fixed typo which very much affected the meaning of my comment at 16:16, 30 June 2024 (UTC))

Seems to have been fixed; ignore me... HouseBlaster (talk · he/they) 15:27, 30 June 2024 (UTC)

Yep, I caught the same error and fixed it at 15:18 (but you must have been seeing some old cache). * Pppery * _{it has begun...} 16:12, 30 June 2024 (UTC)

I think these fixes addressed the problem I reported above. At least so far. Thank you! Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 04:43, 2 July 2024 (UTC)

Sync request 24 July 2024

Please sync MediaWiki:Gadget-markblocked.js with User:SDZeroBot/sync/MediaWiki:Gadget-markblocked.js (diff). This brings it in sync with the upstream changes at gitlab:repos/gadgets/markblocked/-/raw/main/markblocked.js (hist).

This edit request is raised automatically based on the configuration at User:SDZeroBot/Gadgets-sync-config.json. Thanks, SDZeroBot (talk) 10:18, 24 July 2024 (UTC)

Not sure who inspired this particular edit, but sending a user to the /raw/ page (now in the text of the gadget) isn't useful at all for someone who doesn't know what they're doing. The user should be directed to the main repo listing. Izno (talk) 21:48, 28 July 2024 (UTC)

Sync request 28 July 2024

Please sync MediaWiki:Gadget-markblocked.js with User:SDZeroBot/sync/MediaWiki:Gadget-markblocked.js (diff). This brings it in sync with the upstream changes at gitlab:repos/gadgets/markblocked/-/raw/main/markblocked.js gitlab:repos/gadgets/markblocked/-/commits/main/markblocked.js.

This edit request is raised automatically based on the configuration at User:SDZeroBot/Gadgets-sync-config.json. Thanks, SDZeroBot (talk) 22:18, 28 July 2024 (UTC)

 Done by User:Izno. — xaosflux ^Talk 00:12, 29 July 2024 (UTC)

@Xaosflux, no, somehow, apparently not. See below. It thinks there is still a delta. Izno (talk) 02:32, 29 July 2024 (UTC)

Is switching to GitLab / SDZeroBot a good idea?

cc SD0001. For multiple gadgets, these SDZeroBot edits are starting to hit my watchlist via intadmins granting the requests. Is moving to GitLab and using SDZeroBot to keep things in sync a good idea? I see a couple downsides to this system:

1. We are adding complexity to low traffic gadgets. There is definitely a tradeoff here. I talk about it a bit in User:Novem Linguae/Essays/Pros and cons of moving a gadget to a repo.
2. These updates are likely to spam gadget talk pages. Shouldn't this be an intadmin bot instead of raising edit requests every time?
3. I am not familiar with GitLab yet. This is yet another technology I am going to have to learn. Sigh.
4. Wikimedia GitLab does not allow using its built-in issue tracker, instead forcing folks to use Phabricator. This fragments tickets from PRs, which introduces an inefficiency.

I have made 39 edits directly to the source code of the MarkBlocked gadget. One practical result of moving this to GitLab is all of my edits to this gadget are going to stop completely until I figure out the new system. –Novem Linguae (talk) 23:09, 28 July 2024 (UTC)

Unless you are asking only about this gadget, this isn't the best venue for that discussion. — xaosflux ^Talk 00:13, 29 July 2024 (UTC)

On closer inspection, MediaWiki talk:Gadget-autonum.js, the other gadget I saw on my watchlist, is syncing to mediawiki wiki instead of GitLab. So I guess this gadget is the only one I want to discuss at the moment. –Novem Linguae (talk) 01:10, 29 July 2024 (UTC)

Shouldn't this be an intadmin bot instead of raising edit requests every time? was discussed at some point or another. Users approving changes at gitlab or elsewhere may not be int admins locally (you are).

Probably this bot or another could have a useful extension point where some sort of OAuth support is added so that a change can be supported directly. Izno (talk) 01:51, 29 July 2024 (UTC)

I think the decision should be made by the gadget's contributors which in this case appears to be @Dragoniez and yourself. Dragoniez suggested above they prefer git.
I am not familiar with GitLab yet. ... One practical result of moving this to GitLab is all of my edits to this gadget are going to stop completely until I figure out the new system. It's just another git-based tool where the same commands you're familiar with from github (git commit, git push, etc) will work. We're not using any gitlab-specific features.
Wikimedia GitLab does not allow using its built-in issue tracker, instead forcing folks to use Phabricator. There's no need to change the issue-tracking venue, which is this talk page. We're not being being forced to phab if we don't want to.
These updates are likely to spam gadget talk pages. An auxiliary talk page, say MediaWiki talk:Gadget-markblocked.js/sync requests, can be used in the bot config, if we don't want to spam the main talk page. – SD0001 (talk) 11:03, 29 July 2024 (UTC)

Actually, I wasn't quite expecting the warning header to be added. Is it possible for your bot to sync on-wiki changes to GitLab to track changes in a mutual way? When I need to file edit requests I just need to push changes to GitLab, this is a great thing for me, but I'm hesitant to "compel" anyone to use the external site. Dragoniez (talk) 18:29, 30 July 2024 (UTC)

Sync request 29 July 2024

Please sync MediaWiki:Gadget-markblocked.js with User:SDZeroBot/sync/MediaWiki:Gadget-markblocked.js (diff). This brings it in sync with the upstream changes at gitlab:repos/gadgets/markblocked/-/raw/main/markblocked.js gitlab:repos/gadgets/markblocked/-/commits/main/markblocked.js.

This edit request is raised automatically based on the configuration at User:SDZeroBot/Gadgets-sync-config.json. Thanks, SDZeroBot (talk) 00:18, 29 July 2024 (UTC)

 Not done @SD0001: the diff above says no change to make, please validate. I disabled this in User:SDZeroBot/Gadgets-sync-config.json for now as well (which seems like it was added by the bot too). — xaosflux ^Talk 09:32, 29 July 2024 (UTC)

Regarding that "by the bot" note, I'm now assuming that is due to userspace json page protections, if possible perhaps putting your username in the edit summary next time would be useful (not saying it is necessary). — xaosflux ^Talk 15:59, 29 July 2024 (UTC)