@Tacsipacsi Regarding the sandboxes of templates with template gadgets, when I work in such sandboxes, I generally don't want to load the same gadget as the main template, but a modified version of the gadget, which I usually store in a subpage of my userpage and load from my common.js

Sure, other approaches may be (marginally) better, but realistically speaking, will take years to happen. This approach can be implemented now and wouldn't block or hinder the development of better alternatives. If anything, it would give it some extra push by helping the development of actual tools to be loaded by said alternatives.

Hi! I just submitted 1077955 to add support for templates in the gadget definitions. After the merge of 1005092, me and a few others developed several JavaScript-enhanced templates (see template gadgets and global gadgets). However, although loading gadgets via categories is technically enough, it leads to the creation of many obscure and otherwise useless categories (see every subcategory here and here). This is unnecessary and cumbersome, it would be better if we could load gadgets based on the presence of specific templates, which is generally the intended functionality anyway.

Hi! I very much like the idea, and wouldn't mind to receive an email warning me if one of my tool is down.

In T184633#10119401, @Jonesey95 wrote:

We added the magic word to Template:testcases notice on en.WP yesterday, but when the report updated 22 hours later, pages like https://en.wikipedia.org/wiki/Template:Afd_bottom/testcases were still on the report.

Looks good to me too!

@matmarex Hi! After a very long delay, I finally got around and did this. Hopefully you can code-review it?

f3a17b7cb98b3d8 mostly fixes this because pages with more than 500 categories are generally rare. For wikis that might still face this issues, a possible workaround is documented at https://www.mediawiki.org/wiki/Extension:MsCatSelect#API_high_limits

Done, thanks for the heads up!

@Krinkle Hi! Honestly, I don't remember what reasoning or tests led me to write that comment. At the time I was trying to optimize the performance of appropedia.org and was deep into the docs about async, defer, etc. but now I can't recall the nuances, about which my beliefs might very well have been mistaken. In any case, I was able to improve the performance significantly without using defer, so that's that. Sorry if I can't help, but thanks for asking!

Hi, thanks for the report! I just merged a patch that should fix it, please download the latest master (13.9). Now, as you suggested, the first item of the sidebar will be used as the navigation menu, regardless of the name. Furthermore, if no item is found, the menu will be hidden completely (for wikis that want an extremely simple interface). Let me know of any more issues!

Seems broken again, since March 28. :-(

I, on the other hand, would like to thank Krinkle and everyone else who made this humble patch happen, because even though it may not be perfect, it opens the door to so much useful magic. I started documenting some of it at https://www.mediawiki.org/wiki/Template_gadgets, and look forward to see where all of this will lead us. Cheers!

I'm afraid the hashtag tool seems to not be updating again (since Feb 20). :-(

Strangely enough, TalkBelow doesn't even have a stylesheet.

@Samwalton9-WMF Ah, I see you've unassigned yourself from this task. Does that mean we should find someone else to fix this?

Hi! Thanks for fixing it, but it seems like its broken again, since January 28. Cheers!

Thanks for looking into this! However, I'm currently getting a 502 Bad Gateway error.

This would probably require adding LESS support to TemplateStyles, but I'm not 100% sure.

Hmm, the problem may be related to New Relic, which we're using. I'll mark this issue as invalid until I can update New Relic to the latest version or disable it to confirm that it is the cause. If the issue persist, I may re-open.

@Samwalton9 Ping?

Hi! The hashtags tool seems to have stopped recording changes again, since December 11. See for example https://hashtags.wmcloud.org/?query=proveit

@egardner Thanks! That was VERY useful and I'm already well and away into creating my first tool with Codex.

In T344680#9115373, @egardner wrote:

As far as the equivalent for the code sample you posted, as I mentioned there is still more we need to do before the process is streamlined enough to recommend generally, but you can use Codex components now by doing something like the following:

mw.loader.using('@wikimedia/codex').then(function( require ){
    var Vue = require( 'vue' );
    var Codex = require( '@wikimedia/codex' );
    
    Vue.createApp( {
        data: function () {
            return {
                count: 0;
            }
        },
        template: "<cdx-button @click='onClick'>click me</cdx-button><p>You've clicked {{ count }} times.</p>",
        methods: {
            onClick: function () {
                count++;
            }
        }
    } )
    .component( 'cdx-button', Codex.CdxButton )  // register the component
    .mount( '#my-app' );  // assumes that you have an element with an ID of "my-app" somewhere on the page
});

Tagged the wrong task, sorry.

In T52881#9352286, @gerritbot wrote:

Change 976691 had a related patch set uploaded (by Sophivorus; author: Sophivorus):

[mediawiki/extensions/ParserFunctions@REL1_39] Backport fix of implicit conversion to int

https://gerrit.wikimedia.org/r/976691

I think the issue is that a few lines before (line 817) there's the following:

Sure, makes sense, thanks for your time and answer!

Thanks! I also updated this and now the stats on the page seem up-to-date.

How about a config option for third-party wikis that don't have extremely long articles and may therefore benefit from defer over async?

Yes! This solved the issue that I reported here and had me baffled, thanks! The code you shared didn't quite work for me (perhaps because I'm using REL1_39) but after understanding what's happening and doing a few tweaks, I made it work. Thanks again!!!

I think the problem might have been that the repo didn't have the permissions set up. I just fixed that, see https://gerrit.wikimedia.org/r/admin/repos/mediawiki/gadgets/MiniEdit,access

Apparently it's not so simple, gallery thumbnails and plain images are processed before image thumbnails, so in order to lazy-load everything but the first image thumbnail, the code would be:

$wgThumbCount = 0;
$wgHooks['ThumbnailBeforeProduceHTML'][] = function ( ThumbnailImage $thumbnail, array &$attribs, array &$linkAttribs ) {
	global $wgThumbCount;
	$class = $attribs['class'] ?? '';
	if ( strpos( $class, 'thumbimage' ) !== false ) {
		$wgThumbCount++;
		if ( $wgThumbCount === 1 ) {
			return;
		}
	}
	$attribs['loading'] = 'lazy';
};

Again, this idea can be easily customized.

For what's worth, here's a bit of code anyone can add to their LocalSettings.php to lazy-load just the FIRST image of every page:

$wgThumbCount = 0;
$wgHooks['ThumbnailBeforeProduceHTML'][] = function ( ThumbnailImage $thumbnail, array &$attribs, array &$linkAttribs ) {
	global $wgThumbCount;
	if ( $wgThumbCount > 0 ) {
		$attribs['loading'] = 'lazy';
	}
	$wgThumbCount++;
};

It can be trivially modified to lazy-load the first TWO images, or whatever. Hope it helps someone!

Hi, good news! I was able to add valid hashtags to links by simply adding a space before the # (so as to satisfy the Twitter's specification of a hashtag) like so:

Hi, thanks for identifying the cause and the temporary fix! Just to keep you updated, now it seems the tool has stopped recording changes since August 18, cheers!

@Samwalton9 Hi! Ping because it seems you fixed it last time T321635? Cheers!

I second this request. Three of my tools (Proveit, Synchronizer and WikiEdit) would benefit from it.

Fixed, see https://es.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=152440807 and equivalent edits everywhere else

For anyone involved in maintaining cross-wiki modules, there's now the Synchronizer tool for syncing modules across wikis, and the Multilingual Templates and Modules documentation page was updated and re-written to account for this.

I see, thanks!

Thanks! I just gave repository access to l10n-bot and l10n-bot-watcher and requested translation checks at T337749

Hi! Thanks for the report, I was able to reproduce the issue and fixed it, see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UserPageViewTracker/+/920713

Thank you! I've fixed the qqq keys and added a few more messages. Will add many more in the coming days, cheers!

BTW, I see you set the namespace to NS_WIKIMEDIA. That may be an internal issue of yours, but just to clarify, this extension is unrelated to Wikimedia. Also, the extension currently contains very few messages, but in a day or two I'll expand to a couple hundreds. Cheers!

Invitation sent!

Same happening to me. Banners shown on every single page load, causing layout shifts, even on projects where I disabled all banners via preferences. I just ended up adding