Page MenuHomeMiraheze

Attempt to improve ManageWiki usability and discovery
Open, LowPublic


Some of this will most definitely need community feedback, so tagging Notice. However, I can't give a 100% guarantee, at least from me, that we'll be able to successfully implement all of this. Although, we can definitely try and start somewhere and gradually implement some of the others in the longer term unless it is deemed impossible to achieve at the moment. I have no idea if it's all possible to do, and these are just some ideas that we could try to implement following some community feedback on them.

Module Improvements


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.


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.


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.


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 the new $wgGroupInheritsPermissions (added in MediaWiki 1.38.0) to allow certain groups to automatically inherit permissions from another group.


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.


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.

Event Timeline

Universal_Omega created this task.

Though I am not sure of the details of some Special:ManageWiki/subpage that I did not use, I agree that there should be an improvement.
Some thought:

  • APIs are needed to use JavaScript and it is not implemented yet at all afaik. I think removing technical debt will be a boring task to do.
  • In addition to the community feedback, it would be helpful if there are analytics like WMF are collecting by using Extension:EventLogging because watching the activity of users can give motivation and hints to developers. But this is not needed hardly but just my thought.
  • There are some options to choose to write JavaScript modules on MediaWiki: OOUI, Mustache, Codex (Vue.js), etc. It is hard to say which one is best because all of them are potentially deprecated or in development.

Anyway, thank you for creating this task!

Universal_Omega updated the task description. (Show Details)