This has been discussed and from a matter of principle, we've enacted a new policy point for this exact situation.

No progress, no plans to start on it at the minute as it involves a complex rewrite to implement minor improvements while there more critical features on the radar

In T3868#74318, @Reception123 wrote:

@John Ok, sounds good. So we need more specific categories.

In T3868#74316, @Reception123 wrote:

@John For configuration settings specific to extensions, we either should make a new tab on the current ManageWikiExtensions called "extension settings" or a tab on ManageWikiSettings called "Extensions". Which one do you prefer?

100% config, not ManageWiki (the extension)

Anything that blocks this task being completed should have a relevant subtask opened and assigned to myself. Prioritisation will take place and attempts to resolve blockers before July will be made.

root@test1:~# php /srv/mediawiki/w/maintenance/eval.php --wiki test1wiki

$dest = Title::newFromText( "MainP" );

The extension no longer works at all from what I can tell.

In T1404#66202, @Paladox wrote:

We should uninstall NativeSvgHandler seeing as that's the problem.

I wanted to do this by rewriting the existing Special:ListFiles and then realised it'll need to have every wiki defined as a repo source (meaning every wiki shares every other wikis images... which is, bad shall we say). I've now decided that if I just write a DB table and a relatively simple SpecialPage/pager and a hook, this can be so much easier and allow us granular control over who accesses stuff. Further we could hook it into the CW hooks and mass update all images' public/private state.

Please put this on the Comminity Noticeboard.

Chase up the password with Paladox and the bot flag with the wiki.

This will be done with time.

In T3846#73888, @Cyberpower678 wrote:

In T3846#73832, @John wrote:

Phab is not a TODO list.

It kind of is, if all of these tasks were placed on a Workboard like, https://phabricator.wikimedia.org/project/board/2160/ :p

PHP 7.3 hasn't been released yet. Isn't this a bit premature as we don't have a release date or even knowledge of a release at all?

Phab is not a TODO list.

SQL was done a while ago. Working on adding files and MWP now. MWN is out of scope for this task because I kinda need this done before MWN can be worked on.

Dec 11th deadline for resolution.

root@mw2:~# php /srv/mediawiki/w/extensions/MirahezeMagic/maintenance/getJobQueueLengths.php --wiki loginwiki --total-only
reviwikiwiki 357
root@mw2:~# php /srv/mediawiki/w/maintenance/showJobs.php --wiki reviwikiwiki
0

In T3829#73778, @Paladox wrote:

Hmm, those 2 settings only affect wikibase, do you have wikibase installed?

https://github.com/miraheze/ManageWiki/compare/e336c0b4ece3...21c2f809d3f3 paves the way to be able to do this efficiently.

After testing, the implementation I've done is increasing page loads and isn't working with several extensions that are being super picky about the order things are loaded in. Therefore, this isn't going to happen and I'm going to instead focus on working on other tasks.

I'm going to decline this now I've been thinking about it.

In T3794#73657, @Paladox wrote:

Just leaving a FYI, this is a high priority once released.

In T3812#73519, @Reception123 wrote:

Any status? This has been here for 6 days

Deletion request

Not broken. Unstable feature deployed into production

For interwikis, please make the request on https://meta.miraheze.org/wiki/Community_noticeboard

For reference, the issue was Actor requires a unique user ID and a unique username. Paladox ran a script he shouldn't have which removed your account but not the actor reference. I've set this username reference to old so we can deal with it later.

You should be able to login now.

The main point of this really was having an API. The extension isn’t designed too well for active actions so a privileged API is out of scope.

https://gerrit.wikimedia.org/r/c/operations/puppet/+/465538/3/modules/varnish/templates/misc-frontend.inc.vcl.erb

Please contact labster [at] miraheze.org about this.

1.32 is in RC stages, so it's not a formal release yet but it's no longer in alpha (which is 1.33).

Technically because the import is a full history, it is legally compliant with CC-BY-SA licensing as we are CC-BY-SA licensed as well. As I can't see any evidence to suggest the content is licensed otherwise, no action is needed.

Yes so it goes back to its old format, so in order to use the ManageWiki extension, you must be using CreateWiki’s CDB storage.

In T3629#72770, @Paladox wrote:

@John what do you mean by killing DBListGenerator at some point?

What will replace it?

https://git.io/fpmju is the code for this on a basic level.

Working on this now, and the potential for this is immense.

We should upgrade because we commit to the latest version.

In T3787#72581, @Tiger wrote:

In T3787#72578, @John wrote:

You do not need to use 3.0. 4.0 is a valid license for the content.

Is it safe to copy content from zhdel (4.0) to zh.wikipedia (3.0)? (which is one of purposes of zhdel)

In T3786#72582, @Paladox wrote:

You mean the "translate" extension? In which case you can enable it through Special:ManageWikiExtension on your wiki.

You do not need to use 3.0. 4.0 is a valid license for the content.

In T3631#70329, @Southparkfan wrote:

P125 is a draft for a simple query API.

However:

• RemoteWiki::getExtensions() should automatically return an array without 'zzzz'

I’m going to move this to json soon so don’t worry.

• There is no RemoteWiki::getPermissions() method or similar

Do we need to?