I'm going to keep this task open for now since we're dealing with 2 separate lines of inquiry.

Anyone with Steward access can handle this.

We do ES or db5. Cost wise it’s one or the other.

No XSS.

Update?

Redis issue that was caused by a live hack which was reverted when this was reported originally and other times.

Few months left

While a valid issue, there is a solution for which a task already exists. Priority should be spent on that and if there still remains an issue, another specific task open for this.

This should absolutely have a policy before being possible. Blacklisting IPs should be a ToU action with regards to hosts only.

You were working on this yesterday?

In T4493#85255, @Void wrote:

Is there anything else that can be done in the meantime? Such as T4260? Any space we can get is space we need.

It’s not a silent failure but this an upstream issue with the form layout and not one relates to ManageWiki or Miraheze

In T4477#85082, @RhinosF1 wrote:

In T4477#85079, @John wrote:

Per above.

That doesn't answer whether a radio button works better. Is there a reason to not use one?

Per above.

Invaliding as upstream and chances of resolution are extremely low by July.

In T4370#84981, @Eduaddad wrote:

will not be on translatewiki.net?

You can change it back using Special:ManageWiki

Please request this on Meta.

Unfortunately the extension you've requested is not compatible with our environment. There are many other batch upload extensions already installed which may suit your needs.

You can do this using Special:ManageWiki/extensions on your wiki.

We don't use $wgJobRunRate.

Can't reproduce.

This would be an issue to take upstream.

oecumenewiki

You can fix this using Special:ManageWiki.

The deletion was requested in the correct place.

https://github.com/miraheze/CreateWiki/compare/0bf257727e4c...931d0932d575

We have an existing check for disk space. We aim to have 10% left on a sever, and if there is less than 10%, that has to be resolved. Otherwise lower the criteria. Not create even more checks because what is more critical than critical?

There isn’t a data reset, it’s a waterfall. So June 2nd includes May 1st-June 1st, then June 3rd it’s May 2nd to June 2nd, June 4th it’s May 3rd - June 3rd etc.

In T4430#84259, @AmandaCath wrote:

Per T4424#84190 wiki deletion requests no longer go on Phabricator unless they are urgent (note to self: shouldn't the information on Meta related to wiki deletions be updated to reflect this?)

He is aware about this

Modify the header. But “restricted” is a configured section so this is better suited via the help param.

Deletion requests (unless needing to be done now) no longer go on Phabricator as anyone with "managewiki-restricted" on metawiki (sysadmins and stewards) are able to delete wikis via Special:ManageWiki.

"aft-reader" isn't assigned to any usergroup using Special:ManageWikiPermissions which is causing this error.

Thank you for your reasonable disclosure.

In T4409#83879, @Zppix wrote:

I think actions done by wiki manager should be logged on meta though

They can allow you the ability to edit site css/js using Special:ManageWikiPermissions/sysop

In T4403#83802, @Robkelk wrote:

Same issue existed on allthetropes and poserdazfreebies. I can edit now, but as of this posting the "Admin Links" link I'm used to seeing in the top menu is missing at allthetropes, poserdazfreebies, and theresnothingbetter

In T4401#83760, @AmandaCath wrote:

Don't we already do this, when there is copyvio content or other CP violations, we make the wiki private and/or close it until the issues are resolved?

In T4391#83595, @Hispano76 wrote:

What if what is restricted is only visible to some users and not others?

Essentially, yes, if all account creations end up going through Wiki A. A team is only as strong as it's weakest link.