Unfortunately due to some external circumstances I do not have the time to finish this task at the moment, I will pick it up again when I have time if nobody else claims it in the meantime. The work in progress commits I made are linked in the original post if someone wants to continue working based on what I had done

Looking at the current canned responses, it seems like some of them also jam several potential reasons for why something was approved or declined, even if not all of those reasons apply (e.g. "your requested subdomain is either invalid, is too generic, conveys a Miraheze affiliation, or suggests the wiki is an English language or multilingual wiki when it is not")

I took a look at how WikiDiscover implements the "number of wikis with setting" magic word, and it actually just fetches every wiki from the DB, parses its settings JSON, and checks if the setting has the desired value... we could take the same approach here instead of a separate table for consistency reasons, although I don't think doing it that way is particularly scalable if there was a significantly larger amount of wikis (since we only have ~6k it's not that big of a performance worry)

Since there can only be one category per wiki, the query only needs to look for an exact match. If we were to store tags as strings in JSON format or as comma separated lists, we'd need the query to check for any occurrence of each tag being filtered for every wiki. That kind of query is slow in SQL.

In order to make querying tags efficient we'll likely need a new table on the mhglobal database cw_wikitags with wiki_dbname and tag_id columns... Although we could store the tags as JSON or CSV in cw_wikis, trying to query that would be slow

I started to take a look at potential ways to implement this, and from a frontend UX standpoint the best result was using OOUI's MenuTagMultiselectWidget. The major downside to using this is that it requires JavaScript.

Another thing to consider is allowing the inclusion of any relevant Phabricator task alongside each blocked extension so that a link to the task can be displayed to users on ManageWiki, or a simple page on metawiki with a list of currently blocked extensions that we could link instead would work too.

We'd just need to disable the checkbox + add message underneath, not actually modify the set value, so that way when/if an extension is unblocked globally, any wiki that had it enabled will be able to use it again without needing to take action. It looks like this is where globally disabled extensions are defined currently

Should people be able to specify tags during the wiki creation process? (Could be done as a part of T9153)

Regarding the addition of a user right for stewards to modify tags: how often do we anticipate tags actually needing to be modified? Is it necessary for a special page to modify them vs just putting them in a config parameter?

https://github.com/miraheze/WikiDiscover/pull/91

It doesn't look like you have StructuredDiscussions enabled on the wiki you mentioned. Try enabling it first and see if that resolves the issue.

We could alternatively just add a 404 page that has "Did you mean: /wiki/<page_name>" here like Wikipedia does.

In T7125#141452, @Universal_Omega wrote:

Split the long extension list into multiple categories, so that similar functionality is grouped together (kind of akin to what Special:SpecialPages does). While it might be possible to get this from extension.json, this might end up with too many groups. We may want to choose a smaller group to be manually determined, like "User rights and moderation" "Wikicode functions" (parser functions), "Appearance", "Editing", Special Pages", "Other". The categories might be grouped into tabs or with ordinary headers; I'm fairly agnostic on this point.

Already supported, just needs mw-config change for that. You just need to add the 'section' => 'section' key => value to ManageWikiExtensions.php.

Now that I have CreateWiki and ManageWiki working on my local MediaWiki install, I will attempt to start working on some of these changes when I get the chance.

The database name is exactly what it sounds like, it is the name of the database that holds all of your wiki's data (including page contents, revisions, local users, etc). The naming scheme for wikis on Miraheze is "<subdomain>wiki", so a wiki with the url https://meta.miraheze.org/ would have the database name "metawiki". When renaming a wiki, the database is also renamed to reflect the new subdomain for the wiki, because if we were to not do this it could cause a database conflict if someone were to create a new wiki with the same subdomain that your wiki used to have.

Structured Discussions is not enabled anywhere by default, you will need to enable it manually.

In T7103#140860, @Turtle84375 wrote:

In T7103#140836, Universal_Omega wrote:

• ManageWiki should blacklist the entire deletion of the bureaucrat group, in my opinion but that's just an opinion.

Some people like to remove and/or rename the bureaucrat group to suit their own/their wiki's purposes, so I'm not sure the last one is really the best idea, as far as keeping Miraheze wikis as founder-run and customizable as possible. I'm all for the other suggestions, though.

While I don't think I'll have time to do this, I will say that this should be done in some way as an error instead.

if you are removing the managewiki right from the only group that it is still contained within, error.
if you are removing the ManageWiki right from the last group with users in, error

It looks like this issue is not caused by deleting user groups as the original post stated, but is rather caused when someone attempts to create a user group that has no rights assigned.

PR was merged.

Done in pull request #3815. Sorry about the initial confusion.

It looks like the documentation has lied to me... I will create another pull request to define $wgLinkTitlesFirstOnly shortly.

When I looked in the documentation for LinkTitles, it said that $wgLinkTitlesFirstOnly defaults to false already.

Done in pull request #3814.

The reason it did not work is because you have your entire Common.js wrapped in a mw.loader call with a dependency on mediawiki.notification, which was not loading, so the callback is never called. Removing this dependency should allow your code to work again.

Universal_Omega almost had it right, but the desired portletId would be p-personal instead of p-tb.

The Timeless skin is installed on all Miraheze wikis by default. You can set it as the default on your wiki on the Special:ManageWiki/settings page on your wiki, under the "Styling" tab.

I was also able to reproduce this issue on my wiki.