Module Improvements

Core

Special:ManageWiki/core could potentially be improved by maybe moving some of the primary settings, such as $wgFavicon, $wgAppleTouchIcon, $wgLogos (ManageWikiSettings has this split out as $wgLogo, $wgIcon, $wgWordmark, $wgWordmarkHeight, and $wgWordmarkWidth), $wgDefaultSkin, and $wgDefaultMobileSkin to Special:ManageWiki/core.

Central Core
I have thought of one thing here, and this is potentially completely unnecessary. But, I think it would be nice to allow searching for wikis by the server URL, so when tasks are created linking only the custom domain, additional looking up of the database name, it would also be useful when the custom domains no longer resolve, since the database name can't be found on-wiki, you'd have to look back at tasks to find the initial requesting task, in order to find the database name, to remove the custom domain from ManageWiki.

Extensions

One idea I have for this is to create a preference to be able to disable section tabs within Special:ManageWiki/extensions, except for "Other" and "Skins", which would revert to the old behavior of Special:ManageWiki/extensions. The reason this would be a good idea is that it would maybe allow easier discovery of extensions by being able to search using the browser word search functions. Additionally, the creation of the sections never went through community feedback, as it was before SRE started doing that. Whether this can even be done is yet to be seen, but it does seem like a good idea to attempt to do it. Furthermore, if the preference is not enabled, we should consider the redesign of the current sections for better discovery, as they currently for the most part use the sections in extension.json, which isn't always ideal, and it's hard to find some extensions.

Settings

Redesigning and reorganising the current sections of Special:ManageWiki/settings may be a good idea. We could also consider maybe pulling setting descriptions from the configuration description or descriptionmsg from extension.json/skin.json. Also, since Special:ManageWiki/settings, does support filtering by extensions or skins now at Special:ManageWiki/settings/<name>, we could maybe add a dropdown box or something above the form with options for every enabled extension and skin for easier filtering and visibility of each of their available settings, with the addition of MediaWiki core and all global extensions and skins as options as well.

Permissions

We could potentially improve Special:ManageWiki/permissions by maybe making it possible to add at least one configuration variable to the main part of Special:ManageWiki/permissions before entering into group permission modification. We could add the ability to create custom rights within the $wgAvailableRights configuration, which, of course, would need to be vetted to adhere to the disallowed rights, etc. But, doing this would potentially allow adding one of the most requested configuration variables to ManageWiki, $wgRestrictionLevels. If we did this, we could also consider moving $wgImplicitGroups to Special:ManageWiki/permissions instead of Special:ManageWiki/settings, where it is now. We could also consider adding $wgRevokePermissions as another tab in group permission modification to be able to configure that for each group. Another thing we could consider is supporting $wgGroupInheritsPermissions to allow certain groups to automatically inherit permissions from another group. We could also consider adding support for $wgGrantPermissions as well as $wgGrantPermissionGroups.

Namespaces

We could potentially improve Special:ManageWiki/namespaces by making it possible to add multiple values for $wgNamespaceProtection, as that config supports an array for multiple values as well. Some extensions even set multiple by default, but because of the fact we don't support them, ManageWiki only supports one, and therefore, only one is in the install step of ManageWikiExtensions. An example of this is StructuredNavigation for the "Navigation" namespace. The extension has two namespace protection permissions: structurednav-edit and structurednav-create. However, since ManageWiki only supports one, it only sets structurednav-edit in the extension install step. Another thing we may want to consider is allowing some of the ManageWikiNamespaces additional settings to be modified for the special namespace if it would work to do. Currently, the special namespace is completely disallowing modification, and under certain circumstances, setting additional settings for it may be necessary, or at least useful.

Global Improvements

User Experience

We could potentially improve the overall flow of the extension, by using heavy JavaScript, to make the user experience better, and allow us to continue modifying the main form after selection of a group or namespace in their respective modules, interactively with JavaScript, so virtually it would not need to reload.

Discovery

We should consider further improvement and discovery of ManageWiki as a whole to make it easier to use, provide better documentation, and make it more understandable and easy to use for less technical-oriented users. One idea could be a complete rewrite of the entire extension (or creation of a new module), which would essentially create a step-by-step wizard, either complete deprecation of the current modules or a whole new module, which you could use to find extensions or skins you want to enable, enable extensions or skins, continue to the next step, manage namespaces, continue to the management of permissions and settings for the extension or skin setup, with some sort for a wizard or something else for core stuff management.

New Additions

Supporting Hooks

We could potentially consider supporting some basic hooks in ManageWiki, potentially by creating a new "hook" type for Special:ManageWiki/settings, which would be able to modify hook output within ManageWiki. Of course, by doing this, we would need some sort of validation/sanitisation for user input within ManageWiki.

Better Validation of Configuration Variables

We should consider maybe something like a new ManageWikiValidation helper class or something to support better validation for numerous configs in both Special:ManageWiki/settings and Special:ManageWiki/namespaces. This would validate stuff like usage of https:// where required, to prevent user confusion, or CSP errors, which would sometimes be given if using http://. An example of this happening is T9032. If it is done incorrectly, then this would immediately give the user an option to correct their mistake and not save the setting otherwise.

Support Making Reason Optional

Reasons are not always necessary, it would be nice to not require them, since often times users just use something like . since they don't need to add a reason, but the field is required. However, one case it may be required, is ManageWiki changes on Meta, so potentially, we could make it a configuration variable, disabled by default, and enabling on certain wikis where it is necessary, such as metawiki.

Add New File URL Type

Adding a type of file URLs can be useful to allow users to not have to make the input use the full static URLs, but rather just File:Example.png, which ManageWiki could then expand to the full URL via lookup when setting the config. This is useful for new users who are not aware they need to use the full static URL for files. Alternatively, we could add validation that the inputs include the static URL and warn users that they do not, but need to.