I mentioned the CreateRedirect error on its talk page (sorry, I didn't realise this was a hidden security task! I shouldn't've advertised it publicly), and it looks like the issue has been fixed: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CreateRedirect/+/780567

I'm not a member, just watching that project.

It sounds like the logo issue is fixed now.

Yes, as documented at https://www.mediawiki.org/wiki/Skin:WMAU

Oh, and in case it's not obvious from the above link: we're running this skin in production on https://wikimedia.org.au

This is one of yours. Any issues/comments/things we should know?

I'll have a look at improving it.

@RhinosF1 nope, I've used it a bit, but am not the maintainer. I'm not sure who to ping, but it looks like they manage issues on Github: https://github.com/SemanticMediaWiki/Mermaid/issues

The code here looks sort of old-ish, but fine from what I can see. However, an error is being thrown about the registration of the parser functions:

This looks fine to install, I think.

I haven't delved completely into the code here, but it looks pretty good from what I can see. I think this is good to install.

It requires the BlueSpiceFoundation extension, so it sounds like this is not possible.

I'm glad you like the Genealogy extension!

the pages still show up on Special:Nuke for some reason, even though they're """deleted"""

I shifted totally the focus of my wiki and over 500 templates that I imported originally doesn't have any use now

even if I delete the articles, they aren't really deleted

Wikipedia doesn't seem to be using SaneCase, so I'm wondering if it uses a better alternative? I'm trying to achieve the same thing where links aren't case-sensitive.

A few things:

It creates its own web entry point, extensions/Avatar/avatar.php, as well as a custom file-upload process. Both of these things are a security risk. I'm not saying that there's any particular vulnerability with either of them (I haven't looked). There are other, more secure and well-known, ways of doing what it's trying to do.

Sorry I've not been reviewing much lately. There are too many fun projects in life!

I don't think Diagrams is suitable for the Miraheze environment, as it requires the installation of a separate web service.

PR: https://github.com/miraheze/mediawiki/pull/133

You are marked a maintainer for it so do you want to have a look?

GraphViz is not compatible with 1.33 (see https://phabricator.wikimedia.org/T226616 ), but if you want to get started with Genealogy now you can enable the Mermaid extension and use |format=mermaid in the tree parser function. It's a slightly clunky layout sometimes though, and slows down page load times.

That was quick!! :) Thanks.

It looks like Miraheze is at 1.34 now, is that right?

There's a couple of tweaks required it sounds like; I'm going to look into them first and release a new version of this — and then will update the version here. (Doing that is just a matter of updating the Git submodule in https://github.com/miraheze/mediawiki isn't it?)

It doesn't seem to be installed on publictestwiki.com

Sorry to hear it's not working. What's the error? Anything in the browser console? Does the toolbar button get added correctly?

You can find the name of the message to modify on any page with the ?uselang=qqx special language code. For example, if you want to change the message shown for invalid special page names, go to e.g. https://en.wikipedia.org/wiki/Special:BadPageName?uselang=qqx and see that the message is nospecialpagetext (the BadPageName is just a random string that is not a valid special page name; it could be anything).

@DekuPH2006AJHalili I read that, but it doesn't explain why this is better than just modifying the mediawiki:noarticletext message, which is displayed when a page is not found. It seems that the extension requires setting up a separate 404 handler for the webserver, pointing to the extension's special page. But MediaWiki already has a built-in page that it displays in those situations.

I'm probably missing something, but what's the point of Special404? It seems to be about the same as modifying the core noarticletext message. It also requires modifying the web server configuration, so I'm not sure if it's appropriate for the Miraheze environment.

(Thanks to Reception123 for relaying my message earlier; I was locked out of Phabricator here.)

@Void no you could still do things like this:

Thanks for that. WMAU is sending a donation to Miraheze in appreciation.

So the Committee has decided not to proceed with the migration.

I haven't had a chance to look at https://www.mediawiki.org/wiki/Extension:Multi-Category_Search yet, but in the meantime would the existing DPL extension be of any help? e.g.

Does this extension provide any functionality that's not already available in Lua modules?

The WMAU committee has a meeting tomorrow, where the next stage will be decided. Gotta get people to approve where we're up to so far. :-)

Thank you!!

Good point; yeah, that should be fine.

Thank you! Looks great. And yep, I'll get on to the main wiki shortly. :) This is exciting!

By the way, is wmaucomm correctly set to private? I seem to be able to browse without being logged in.

The code looks good here, and the author is trusted. I'd say this could be installed.

I don't know what the problem was, but I ran fixDoubleRedirects.php and rebuildall.php and everything now exports correctly. Some wayward link record I guess.

I'm attempting to run dumpBackup.php, and hitting a bug. It's hanging with no error, after a couple of dozen pages. Seems to happen even after restoring the DB locally and trying with a clean MW install. Not sure what's going on. :-(

The uncompressed images directories are:

• 427M images_commwiki
• 849M images_wmauwiki

No, it's okay, we can supply XML dumps no worries. And will upload tarballs of the two images directories to Google Drive and send you a link.

I don't think SacredText is a goer, because the source location for its data http://sacredtext.googlecode.com/svn/trunk/data is dead.

Purge is a very simple extension, and is running on quite a few websites. I've worked on it a couple of times and I think it'd be suitable to install for Miraheze. The only thing I'd note though is that there seems to a possibility that it's not actually required: in https://phabricator.wikimedia.org/T200054 Yaron suggests that it's possible to have the purge-without-confirmation without using the JS POST trick that the Purge extension has. I'm still trying to figure out what's going on there though. (Oh, of course, it might just be for the convenient 'purge' link that you want it, so that should be fine.)

The only thing I'd note about CodeMirror is that there are a few bugs with it, that pop up in various circumstances. Basically, they're all hard ones to fix! There is rumour, however, of an upstream rewrite of the CodeMirror library, and that should help. No timeline for when it'll make it into the MediaWiki extension though.

Oh, and the executable bit is set for some reason on run_scratchblocks.js. Shouldn't be.

This extension is a wrapper for a Javascript-based code formatting library. It doesn't do anything PHP-side other than load the required JS and render the parser tags, so I think that's all safe enough (tiny improvements? e.g. htmlspecialchars() is used directly, in stead of e.g. Sanitizer::escapeHtmlAllowEntities()). The javascript library is a submodule, and is pretty far out of date, so that could be updated. I've not delved into the details of that though, so if there's no missing functionality then perhaps all is fine.

@Reception123 ah, cool! :) I've been trying to find time to get things running locally... maybe then I'll be able to help more.

I'm not sure, but I think you can change $wgLinkTargetParentClasses via Special:ManageWiki? (I'm only just learning how things work though, so I might be wrong.)

Have a read of the examples.

It sounds like they may not be all that keen on other people using the skin. Not that that means it can't be used, given that it is open-licensed, but it would probably mean someone else would need to do the work to prepare it for use here. Any, I'd recommend against using it if the OSMF doesn't want it to be used.

@Eduaddad yep, that's what it should do, but at the moment the skin is including its own logo.

That skin currently hardcodes the OSM Foundation logo:

Looks like a good skin from an experienced developer. I can't see anything wrong with it in my reading. There are some external resource requests (addthis.com), but they're all off by default. There are some open issues, but none security-related.

Looking at this again, I think it's a decline. This doesn't do anything useful, and doesn't work at all in a bunch of situations (e.g. different $wgScriptPath). It also doesn't use standard MediaWiki ways of doing things.

Oops, I should have read that! :) Thanks.

I'm getting a couple of errors (with latest master of Liberty):

The point of this extension is to dynamically load JS and CSS from multiple wiki pages at once isn't it? And inject them into the page with <script> and <style> elements.

Could https://www.mediawiki.org/wiki/Extension:JSBreadCrumbs be a possibility for this feature?

This extension looks good to me. Can't see anything other than a few stylistic issues, certainly nothing around database access or security jumps out. CleanChanges is installed on https://translatewiki.net/wiki/Special:Version which I think is a good indication of maturity.

@Reception123 ah, that's true. :)

#Quiz is fine isn't it?

It's a simple extension, so could be quickly improved, but I wouldn't touch it as it stands.

FlickrAPI is good to go once this patch is merged: https://gerrit.wikimedia.org/r/#/c/384642/ (I've forked the 3rd party library that it uses, and fixed a few bugs in it; I have plans to add new features to FlickrAPI).

On the topic of MsUpload, I'd just add that there are some outstanding issues with it, but I reckon it's a great extension and that we (whoever use it) should continue to make it even better. (So, if anyone has any other unrecorded issues with it, please do report them!)

I've tested that patch, and it looks good to me. I commented over there.

Oh cool!

The first problem I see with this skin is that there are lots of untranslated strings in it, even for things (e.g. 'recentchanges') that have translations in core. These would probably be pretty easy to fix; I might try to find time, but it might be quicker for a Korean speaker. :-)

I've created https://phabricator.wikimedia.org/T179245 with relation to this.

@CnocBride I think reaching out for specific things would be a great thing to do. Perhaps not a blanket call, though, but more "here's a thing we want to use, is it good to go?" might elicit more discussion.

@Reception123 I can try to help! Is it just a matter of looking at anything in Extension-Review and saying yea or nea to each extension? And, I guess, for any bad things found, raising bugs on the Wikimedia Phabricator?

But if you're a programmer, I'm sure you're aware of the wretched hive of scum and PHP that is the MW extension ecosystem. The WMF extensions are very good... the others, well...

I work in the Community Tech team at the WMF, but I use GraphViz in my personal capacity on my own sites. I hope I'd answer yes to all of your questions. :-)

There's a patch in for GraphViz at the moment, to convert it to extension registration, if anyone would like to review it: https://gerrit.wikimedia.org/r/#/c/373735/