For more information about me, see https://samwilson.id.au/
- User Since
- Oct 20 2017, 01:57 (283 w, 3 d)
- IRC Nickname
- GitHub User
- Miraheze User
- Samwilson [ Global Accounts ]
Apr 14 2022
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.
Jan 10 2022
It sounds like the logo issue is fixed now.
Oct 26 2021
Yes, as documented at https://www.mediawiki.org/wiki/Skin:WMAU
Oct 25 2021
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?
Jan 7 2021
I'll have a look at improving it.
Oct 14 2020
@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
Aug 1 2020
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.
Jul 28 2020
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.
Jul 27 2020
It requires the BlueSpiceFoundation extension, so it sounds like this is not possible.
May 20 2020
I'm glad you like the Genealogy extension!
the pages still show up on Special:Nuke for some reason, even though they're """deleted"""
May 19 2020
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
May 6 2020
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!
Apr 13 2020
I don't think Diagrams is suitable for the Miraheze environment, as it requires the installation of a separate web service.
Mar 3 2020
Feb 25 2020
You are marked a maintainer for it so do you want to have a look?
Feb 1 2020
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.
Dec 23 2019
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?)
Aug 1 2019
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?
Jul 23 2019
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).
Jul 22 2019
@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.
Jul 19 2019
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.
Feb 14 2019
(Thanks to Reception123 for relaying my message earlier; I was locked out of Phabricator here.)
@Void no you could still do things like this:
Oct 7 2018
Thanks for that. WMAU is sending a donation to Miraheze in appreciation.
Oct 1 2018
So the Committee has decided not to proceed with the migration.
Sep 21 2018
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?
Sep 16 2018
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. :-)
Sep 15 2018
Sep 13 2018
Good point; yeah, that should be fine.
Sep 12 2018
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.
Sep 11 2018
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. :-(
Sep 10 2018
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.
Sep 9 2018
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.)
Jul 29 2018
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.
Jul 15 2018
Oh, and the executable bit is set for some reason on run_scratchblocks.js. Shouldn't be.
Jul 12 2018
@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.)
Jul 10 2018
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:
May 15 2018
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.
May 4 2018
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.
Apr 13 2018
Oops, I should have read that! :) Thanks.
Apr 12 2018
I'm getting a couple of errors (with latest master of Liberty):
Jan 21 2018
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.
Dec 20 2017
Could https://www.mediawiki.org/wiki/Extension:JSBreadCrumbs be a possibility for this feature?
Dec 6 2017
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.
Nov 26 2017
@Reception123 ah, that's true. :)
#Quiz is fine isn't it?
Nov 9 2017
It's a simple extension, so could be quickly improved, but I wouldn't touch it as it stands.
Nov 4 2017
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!)
Oct 30 2017
I've tested that patch, and it looks good to me. I commented over there.
Oct 29 2017
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?
Oct 27 2017
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...
Oct 20 2017
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/