Huh, I just noticed that the button to reset everything got removed. Interesting.

You can do this yourself in Special:ManageWiki/permissions. There should be button that says something to this effect.

Latest stable version from 2013. No updates to the code whatsoever since 2018. Unmaintained.

Latest stable version from 2016. No actual updates to the code in 4 months (all more recent updates are bots). Seems unmaintained-ish and therefore declined, but going to allow security reviewers to have a second look in case I've missed anything.

@UmbraKing do you just want to delete all of the wiki's pages, or do you want to delete and recreate the wiki altogether? Note that the latter will also erase any changes you have made to the wiki's configuration in ManageWiki.

@Southparkfan Actually, Nimbus is blocked by Upstream per T5450#108244 (was already reviewed by Sam Wilson)

You can enable this via Special:ManageWiki/extensions

Per above, what has been requested can be done via ManageWiki.

The Popups extension is still maintained as it is in active use on Wikimedia Foundation sites (including the English Wikipedia, the largest WMF site). The extension being unmaintained is not the issue. This seems to be a bug with the extension. (I feel like a similar bug regarding malfunctions page previews has been reported before recently too).

I don't see massively why we should split this from CU tbh so I'd say the best would be to hold an RfC on it to determine if people are happy with allowing local CU/OS.

I'm not entirely sure, as I've never tried to use or work with Page Forms. However, by the looks of it (MW documentation), it would seem that the "input types" are included by default with the extension itself and can be used via one of the special pages (most likely Special:CreateForm). Someone more familiar with the extension should double check me on that, but if I'm right, this shouldn't need a separate security review and should already work assuming that Page Forms is enabled in Special:ManageWiki/extensions.

These rights are fundamentally equivalent to CheckUser permissions. You would definitely need to sign the NDA if granted access to these permissions. Given that CheckUser and Oversight permissions are not given out to non-stewards, I don't see why an exception would be made here, unless there is some unusual/extenuating reason for this. If it is the case that the rights will be granted to anyone who has signed the NDA (which I doubt is the case), that is not reflected in the relevant policies/documentation.

Also, please don't remove subscribers from tasks for no reason.

I don't see any reason why this needs to be stalled. This is part of the Page Forms extension which I believe we already have, so I'm not sure if this needs a separate security review/install or not.

HeaderFooter is already installed and can be enabled via Special:ManageWiki/extensions.

InstantCommons is enabled by default on all Miraheze Wikis. If for some reason it is not enabled on your wiki, it should be able to be enabled in Special:ManageWiki.

@Lakelimbo any CSS changes you can make yourself (assuming you are a sysop/interface admin) by editing MediaWiki:Common.css on the wiki. In terms of the status of the skin review, you are correct that the review process is very slow. Unfortunately, we currently only have two people qualified to do extension reviews (@Southparkfan and @Samwilson), and both of them are very busy. As such, extension/skin reviews do tend to take a long time.

While it is possible that this is a Phabricator problem, there are also several scenarios on the user end where this would happen.

This is an MW bug, not an extension bug

Security review needed. I'll note that this is a Bluespice extension, and Miraheze does not currently support Bluespice. However, it is possible that it may still work.

I have submitted a change to remove the skin from $wgHiddenPrefs on your wiki.

I have just been able to create and decline wikis with no issues.

This has now been requested for a second wiki, esu.miraheze.org

This is currently pending security review.

Unfortunately the EmbedVideo extension is declined due to security and privacy concerns with allowing external RAW HTML code to be interested into wiki pages.

Both creation protection and extended confirmed protection can be done via Special:ManageWiki/permissions. As RhinosF1 said CheckUser and Oversight are declined for privacy/security reasons.

@Cool11guy12 No, that has nothing to do with this task. Wikis are currently down for routine database maintenance (per 44d2c505d49a)

The extension is installed, but is probably restricted due to a warning on the MediaWiki documentation page about compatibility issues with MW 1.32+ (I say probably restricted as I can't verify right now as wikis are down for maintenance). This will need sysadmin review. @Paladox @Reception123

Extension:Video would almost certainly not pass security review. The extension documentation page has a big red warning banner on it that says not to use it in a production system, which Miraheze is. Additionally, the latest stable version is from 2017 and therefore out-of-date.

Do you perhaps remember where John would have said this? And I remember him saying you shouldn't delete Phab accounts, not rename.

In T5902#115332, @RhinosF1 wrote:

In T5902#115329, @AmandaCath wrote:

Well, I wouldn't expect John to be wrong, but I guess anything is possible. Unless of course the folks upstream changed things with one of the more recent versions of Phabricator, since it was a while ago that I was told this.

It's been done before and been possible since when Miraheze was a baby https://phabricator.wikimedia.org/T110970#1719035

Well, I wouldn't expect John to be wrong, but I guess anything is possible. Unless of course the folks upstream changed things with one of the more recent versions of Phabricator, since it was a while ago that I was told this.

I was told by @John before that Phabricator accounts, although they can be renamed, that renaming them after using them would break things.

Unfortunately, Phabricator usernames cannot be changed once they have been used. Unlike wiki accounts, Phabricator is not able to simply rename an account across the platform, and so renaming an account that has been used (especially one that has been used multiple times) would break things and leave missing subscribers/task authors all over the place. There may be other technical reasons as well, but this is the one I am most familiar with.

@Carp_Universum You can't use a hyphen "-" in a subdomain due to technical restrictions/limitations. Regarding custom domains, you can find out more information here.

@KQP If the original wiki is fairly small (i.e. not a lot of content or other non-content pages) you can probably perform the move yourself by going to Special:Export on the original wiki, entering Special:AllPages in the field for what to export, and then import the file that will be generated to the new wiki (once created) using Special:Import. However, if the original wiki is large (or even medium-sized), this may need to be done via script by a sysadmin.

I guess I'll call it quits for today, since clearly I'm not being helpful.

Huh, didn't see it in Special:ManageWiki/extensions just now

Extension:DisqusTag will need a proper security review... however I will caution you about two things:

I can edit your wiki with no issues, so whatever the bug was seems to have been resolved. On a side note, you probably want to protect your main page to prevent vandalism on the first page people see.

@Avengium Hi, at least one issue that I can identify from your task description is that the interwiki prefix for Wikipedia is not "Wikipedia" but rather just "w". Try to delete what you imported and re-import again using the correct interwiki prefix, and see if that fixes things.