After the successful release of ManageWikiPermissions, I embarked upon the next major feature we had planned for ManageWiki, namespace implementation. After what is arguably one of the most successful years for Miraheze, I am pleased to announce that we will be rounding 2018 off with the release of namespace management within ManageWiki - giving Miraheze wikis more features to empower their goals. We are expecting to enable ManageWikiNamespace on all Miraheze wiki at 17:00 UTC on Sunday, 30th of December 2018.
How Advanced Is This Feature?
ManageWikiNamespaces, compared to ManageWikiPermissions, is actually a complete feature. It allows changing the names of custom namespaces, creation and deletion of custom namespaces while modifying meta data for existing namespaces. We looked at all the available settings within MediaWiki with regards to namespaces and decided to implement the ability to control all the settings as overall, the configuation and deployment of namespaces isn't really that complicated.
Above: ManageWikiNamespaces main namespace configuration options on a namespace created on a wiki using the function. Below: The talk page configuration options showing custom protection.
Side deployment
As a heads up, this deployment will be accompanied by removing the user rights restrictions on all the existing ManageWiki pages. This means all users will be able to view the ManageWiki pages but editing options and elements will not be possible - this is to pre-empt a planned upstream MediaWiki feature where all configuration options will be viewable on a custom special page in the future at some point.
Other Notes
We released a new special page on all wikis earlier this month called Special:GlobalNewFiles which lists all files that have been uploaded on all Miraheze wikis in order to support copyright prevention, vandalism and the growth of the in-work global Miraheze Commons wiki
ManageWiki as a project still has a long way to go before it is able to support every setting MediaWiki has to offer and before we're able to support everything we could possibly want to do on Miraheze. The development of both CreateWiki and ManageWiki will continue long into 2019 when it comes to core changes and core additions however I feel both projects are stable for third party use. Anyone wishing to use either piece of software (or our other ones such as WikiDiscover, MatomoAnalytics or RottenLinks) are encouraged to contact me by email at john [at] miraheze.org and I will happily support anyone in using the software.
To keep up to date on the developments of all of our software, below are links to projects both on Phabricator and GitHub for the software!
- CreateWiki: CreateWiki, GitHub
- ManageWiki: ManageWiki, GitHub
- MatomoAnalytics: MatomoAnalytics, GitHub
- RottenLinks: RottenLinks, GitHub
- WikiDiscover: WikiDiscover, GitHub
- Projects
- Subscribers
- SolidBlock, idris, PERCE-NEIGE and 4 others
- Tokens
Event Timeline
As a heads up, this deployment will be accompanied by removing the user rights restrictions on all the existing ManageWiki pages. This means all users will be able to view the ManageWiki pages but editing options and elements will not be possible
Just for the record I personally am not a fan of that, but I won’t stand in the way if it is necessary for future changes.
You’re not a fan of making config easily viewable like it used to be/currently is on GitHub?
@John no, what I’m not a fan of is making Special:ManageWiki and its associated pages viewable for all users. Whether or not the settings are editable or not, IMHO ManageWiki should still be a restricted special page.
For context, the essential predecessor to ManageWiki, the now-archived Configure extension didn’t grant read-only access to its special pages for all users.
@AmandaCath readonly to the page does nothing and really matches up with our communities value of transparency and accessibility.
Configure is 100% irrelevant to ManageWiki in every way possible. MediaWiki itself is moving in this direction, we’re just beating them there.
Plus for reference ManageWikiPermissions is already open, we’re just making the original design consistent with new stuff.
So the next thing we know, someone (whether it be us or upstream) will be saying that we should make all restricted special pages read-only to all users... which means that we’d be saying we should make pages like Special:Block and Special:DeletedContributions available to be read by anyone? No, that’s not good at all. And then, taking it to an extreme step, should we say that even the most restricted like Special:CheckUser should be readable by everyone? Making the pages readable to everyone only opens up more potential loopholes and security/privacy risks. If you are not authorized to use a feature than you are not authorized to use it - period. That includes viewing it.
Opening up what should be 100% viewable content with zero privacy implications isn’t an issue. The reverse argument is should we make Special:Contributions restricted?
Viewing isn’t using - viewing for information which is useful is useful. If it add no value, then yeah sure viewing is useless.
Also the security implications are extremely low. We have settings that are restricted already, which if changed can break wikis - the mechanism are already there, it’s just removing a line which unnecessarily restricts something.
I don’t want to argue over this... like I said I’m not going to stand in the way of this, but put simply, I don’t feel that allowing everyone to view the tools that only administrators or other restricted groups should have access to is a good idea. I fail to see how allowing potential vandals to see how admins block them is beneficial in any way. Also, we must make sure that deleted contributions are NEVER publicly accessible, since that would basically defeat the purpose of deleting them to begin with, and it would allow anyone to see copyright violations, grossly inappropriate vandalism, etc.
Phab temporarily crashed while I was in the process of replying, so my reply got posted like six times. Sorry.
Just to make it clear, your argument does not have any sense with the DeletedContributions, since that information is private, so why would anyone ever make that public?
And, as John told you, settings used to be public on GitHub and there were never any problems, why should there be now? I really fail to see what harm can be done by users being able to see what settings each wiki has. It is public information that is of interest to any user, basically like Special:Version. For example, what if a user is surprised that there are no Wikimedia Commons images on a wiki, they can check Special:ManageWikiSettings and see that it is disabled on purpose. And also, the logs for ManageWiki are public anyway, so again keeping it private makes no sense, since a user can always see what was changed through the logs (though viewing it on the extension page is obviously nicer and easier)
How to modify a namespace's standard name and display name (sometimes differs from aliases or stand name)?