Other then T476

I totally agree with creating a local manage wiki page, although on wikis that have a designated "founder", the access should be limited to them only. Otherwise, bureaucrats seem okay for the task.

It will be a user right that can be assigned as necessary. It will default to bureaucrats unless otherwise specified.

OK

Just out of curiosity what is the status of this currently? Is it functional yet or still in development? BTW I have deleted the subscription of the most recent poster before me who appears to have been blocked, if that's OK.

It is nearly done. If you go to special:ManageWiki on any wiki exepct meta, you will see that it is installed but disabled.

When will it be enabled? If it's installed, what are we waiting for?

We are waiting for it to be functional. Amanda, if you'd like to help contribute to getting it working, you can send pull requests to https://github.com/miraheze/CreateWiki/

For the extensions to be developed suitably for use in wikis. Currently it acts as a global tool that can edit every wiki without restrictions.

sorry, I meant to link to https://github.com/miraheze/ManageWiki/

+ManageWiki project as this is now its own separate extension. -CreateWiki has it's no longer relevant here.

It may a little too late, but I just wanted to propose the settings that DQ & I feel should be included in this new extension:

• The ability to close your own wiki
• The ability to mark your own wiki as private
• The ability to put an open wiki in read-only mode for longer than 1 week*
• The ability to edit the site namespace name and the official site name (but not the URL)
• The ability to change the default skin of the wiki
• The ability to add/edit/remove the wiki logo

*One week is the longest that Special:ProtectSite allows

---Amanda

BTW, is there a set month/date when this is supposed to go live? I see that's it's enabled in GitHub but the special page still doesn't work.

In T194#20753, @DeltaQuad wrote:

It may a little too late, but I just wanted to propose the settings that DQ & I feel should be included in this new extension:

• The ability to close your own wiki

Is already included.

• The ability to mark your own wiki as private

Already included.

• The ability to put an open wiki in read-only mode for longer than 1 week*

This is not something feasible within MediaWiki and requires an entirely new extension.

• The ability to edit the site namespace name and the official site name (but not the URL)

Already included.

• The ability to change the default skin of the wiki
• The ability to add/edit/remove the wiki logo

Generic settings like these are planned.

In T194#20755, @DeltaQuad wrote:

BTW, is there a set month/date when this is supposed to go live? I see that's it's enabled in GitHub but the special page still doesn't work.

The plan was December 2016 however only @Southparkfan is able to give any accurate estimations. He was hopeful of December 2916 as well but that was a while ago.

{F50651} {F50655} @DeltaQuad here is a screenshot of what Special:ManageWiki currently looks like if you're wondering.

He was hopeful of December 2916 as well but that was a while ago.

I hope SPF can finish a couple centuries before that.

@labster lol

@John I assume you mean 2016

---Amanda

Indeed 2016.

Why is the old project goal still here?

It was worked on in that time so it's really for tracking.

Has this been completed yet? On WikiCanada I noticed that there is a Special:ManageWiki page but accessing it throws an internal technical error.

If it is not completed yet, why is the special page already there?

@Amanda Obviously if this task is still here it has not been completed. The page is there because SPF added it for some reason, but that does not mean it is operational yet. Also it is not a "technical error" it is just not actually enabled on wikis other than Meta and and Extload.

I've made some changes to ManageWiki:

• metawiki is classed as a GlobalWiki and can change configuration of all wikis;
• each wiki (where ManageWiki is enabled) is able to change its own configuration only;
• changed wfGetDB to wfGetLB so it works with our multi-database setup.

ManageWiki should be good to deploy on all wikis now which essentially resolves this task of "some settings" and "manageable by bureaucrats", though I'm waiting for someone to review and okay it. Even a semi-testing production on wikis like testwiki etc. may be at hand now.

Been looked over and okay'd by labster and ndkilla so will enable globally shortly.

https://github.com/miraheze/mw-config/commit/d73d04b562451e52527c31498908fddf5cca0c8a

@John Currently I've noticed the following:

• The Special:ManageWiki page does not contain settings for user groups/extensions yet
• Users cannot make their own wikis private/public

I think that the public/private ability currently requires the managewiki-restricted userright, but this userright has not been assigned by default and ideally should not be required

In T194#32415, @Amanda wrote:

• The Special:ManageWiki page does not contain settings for user groups/extensions yet

This still requires a lot of work and is 100% dependent on SPF. We reached a point where the shell was there that it only required a little bit of effort to deploy it globally. There is still a lot of come but his time restraints are unfortunately quite high.

• Users cannot make their own wikis private/public

I think that the public/private ability currently requires the managewiki-restricted userright, but this userright has not been assigned by default and ideally should not be required

This is legacy and it's currently undecided if this is a smart idea. It is up for discussion but it has been brought up that people can unintentionally (or intentionally) make their wiki public and then blame and put liability on Miraheze.

This is legacy and it's currently undecided if this is a smart idea. It is up for discussion but it has been brought up that people can unintentionally (or intentionally) make their wiki public and then blame and put liability on Miraheze.

Okay, I understand. Would I be allowed to assign managewiki-restricted locally on WikiCanada as I would never do something like described above?

managewiki-restricted exists to keep some settings solely for sysadmins, so I'm going to say no. At the minute, "public/private" is a side affect and 100% not the intended use of it.

Since we act solely on the request of a bureaucrat anyway, I'm going to kill the requirement for it. I note especially that under the ToS, we are not liable for the inability to use any of the service/software provided. As such, if someone makes their wiki public, we're not liable for the affects.

So does this mean that managewiki-restricted will no longer be required to change public/private settings?

Yes.

Great! Now, where would you change the config so that on WikiCanada the managewiki userright is restricted to the "founder" group? I'd assume overrides, but I'm just being sure

https://github.com/miraheze/mw-config/blob/master/LocalSettings.php#L2758

Hello! This ManageWiki is very handy and I cannot wait to see the features in store. I would just like to make a few suggestions about the ManageWiki form.

• It would be cool if we were able to make our own namespaces. For example I work on another Wikia wiki lets call it "MyWikia". Imagine if I wanted to import pages from that wiki into a namespace called "MyWikia:". The ability to create your own namespaces without requesting would be very helpful.

• The ability to enable the extensions and gadgets without the requirement of system administrators. I don't know if this could work but it would be nice to have a tab on the ManageWiki page called "Extensions" and it would have a full list of extensions that you can enable. All you have to do is click enable or a button on them to be able to use the extension. A search bar could also be used to add easier functionality. The ability also the configure the extensions could also be added with certain restrictions of course. Also the ability to add our own gadgets to the wiki. Of course they would have to be reviewed but they would still be cool.

• The ability to also create user groups and appoint certain rights would also be handy. For example I wanted to create like a moderator. They could block users or warn them using an extension.

I have a question about using CDB files. Assuming that we'll have to load every value in the configuration to process a request, is there a reason to use a key-value store at all? If we need to iterate through all of the keys in the file, why not just store a serialized array and just load that file? Or have a CDB for all the wikis, mapped as ( wikiwiki => [ serialized settings ] )?

If my assumption is wrong -- that we wouldn't need all of the values for a request, maybe there's a reason to do this?

@Southparkfan this still needs an answer.

@labster that is probably. It's better to have all values for every request, but we need to be sure there is no negative performance impact.

If we could only just get the CDB file issue sorted out and configured, applying the rest should be easy. The priority is for "the developers" (@Southparkfan, @labster) to sort out this issue.

On thinking about it, we can't have a single CDB for all of the wikis, because CDB files are immutable. I keep thinking it's like BerkeleyDB or something. I still feel like serialized blobs should be faster, because there's less overhead for something we'll just slurp into memory. (CDB is still a better option for LC, because you only need a few values for each request, not the whole thing.)

I'm thinking we also want a timestamp column in cw_wikis. Because we need to keep all of the wiki settings updated for multiple mw servers, presumably every puppet run, we can either:

• Just generate every wiki's settings on every puppet run
• Compare a timestamp, and only generate settings if the file is older than the last update
• Something of a hybrid -- set a global timestamp somewhere, and update all wiki settings if any of them changed.
• Just keep it in the DB, and query cw_wikis every time. It might be fast enough.

In a lot of ways, this might be easier if we had Redis running, in which case we'd just set a TTL, and it would automatically update. But that's a whole other set of challenges.

@Reception123 "the rest should be easy" Really? What we normally say is, "It's just a simple matter of programming."

@labster I didn't mean "easy", but I meant if, you would do one setting, like "wgLogo" adding all the rest would be trivial (just copy it and replace the values) but of course programming the initial code would not be close to easy.

I'm not sure about including puppet in this, wouldn't it be annoying for users to have to wait 10 minutes for their config to work? I'm sure we'd get a lot of tasks saying "my config doesn't work" simply because the users didn't read the part that says you need to wait.

Puppet only manages stuff in puppet anyway so this can't be in puppet.

@labster Any updates? Do you think you'll be able to work on this sometime soon?

my suggestion was merged to this task. But maybe different.

My suggestion: Make simple wikipage which allows direct editing of LocalSettings.php. Allow all settings that are normally available in LocalSettings.php.

Then, no sql table needed.

You could share this feature outside of miraheze, as standard extension on WikiMedia.

Direct editing of LS would be difficult to do properly. The most I'd say could be done would be a series of checkboxes, instead of direct code editing. As otherwise, incorrect code or data leaks are likely to occur. The way we have in mind would be both user-friendly and safe.

Yes. I don't mean raw text. I mean checkboxes which are directly applied to the LS. Give full power of LS to wiki admin, but with safety layer.

That’s the sole purpose of this task/project.

In T194#53864, @John wrote:

That’s the sole purpose of this task/project.

Great!

Suggestion: simplify the settings editor by removing database. Go:

MW config page > php > LocalSettings.php

instead of

MW config page > php > MySql > php > LocalSettings.php

Seems redundant to store same info in MySql and in LocalSettings.php.

Just a suggestion, i'm sure it will be great either way!

same idea:
https://www.mediawiki.org/wiki/Extension:Configure

Extensions can now be managed (in theory) by using Special:ManageWiki.

Things have to be converted over and then enabled using $wgManageWikiExtensions and then the relevant parts in LS need to be uncommented for it to take affect but the backend is definitely in place for it now.

Decided extensions should be managed in their own table and leaving wiki_settings open for wg* variables while wmgUse variables can be handled through manipulating the settings as on using $wgConf->settings.

Looking at implementing variables, could use json_encode() to store in MySQL then using json_decode(), manipulate and retrieve as needed. Though how to manage it with respect to all.dblist will be interesting.