Per above

I've done some simple fixes. I'd also suggest you import MediaWiki:Common.css if this hasn't already been done.

I'm not sure there's anything left to be done, as everything appears to be working now.

If you provide a copy of the script locally on your wiki, you can load it from there without any difficulties. If you need any help doing that, let me know.

Hi, sorry this took so long, but we just discovered that the configuration was done wrong. It has been adjusted now.

1. You can try to remove all references to the interface admin group using Special:ManageWikiPermissions. (Remove all permissions from the group and make sure no group can add or remove the now empty group.
2. $wgTidyConfig is set by default to RemexHtml. Is this suitable?
3. That's in the works right now.

TemplateStyles can be enabled using Special:ManageWikiExtensions.

It doesn't seem to apply anymore, as I made a change that was not marked as bot. I'm guessing there was something done that confused RC.

If it helps, I discovered this by accidentally stripping the email from two or three spambot accounts on allthetropeswiki.

As a followup to this task, we're thinking of modifying modifyGroupPermission.php so that it can remove a permission from all groups that contain it. This would make it easier to strip the right, as currently there are still wikis that have it. Hence https://git.io/fhwOy was done as a temporary measure.

It was removed from MWE because of the inability to properly configure it through MWE installation at the time. I'm not sure what's missing right now, as the exact reason wasn't documented. I know it's missing permissions, but if that's all, we can move it back to MWE now.

You can now delete the Uncyclopedia namespace, and merge it into the project namespace.

Add cp2 to that list now.

Per R9:523dab070359#70008 this isn't working properly.

If need be, I don't think there would be any legal reason you couldn't provide a copy of the scripts on your wiki, provided that the licensing information (which is in a comment at the top of the script) is kept intact, and that you supply the URL of the original copy.

Did you name the talk namespace? This doesn't happen automatically, and will disallow you from submitting the form.

@Paladox @Reception123 ^

In T3861#76112, @Void wrote:

Task has been resolved upstream for a month.

Correction, Special:ListFiles has been fixed. Is there an upstream task for Extension:Editcount?

Content translation was previously removed because it requires a service we don't have. See T784#12341. I'm guessing someone just forgot to remove the extension submodule.

We don't maintain the translations of other extensions.

Caused by broken translations. I've adjusted them.

In T4010#76825, @MikeV wrote:

I managed to do it after getting him to browse to ndg.nenawiki after logging on to nenawiki.

Yup, that's what you need to do.

A global account already exists.
https://meta.miraheze.org/wiki/Special:CentralAuth/TomBreen

Fixed by @Paladox. Should be working now.

Nope, you should just be able to create a link like that. There are a few more details here.

Looks like this is affecting all wikis.

This should be possible if the current namespaces existed in the ManageWikiNamespaces. I guess there are a number of wikis that don't have the mw_namespaces table populated, which should get fixed.

You could try using the new global interwiki feature, by linking to [[mh:nenawiki:Page]]. In theory, the link should always point to the same place.

If you have any questions about the process, please direct them to the community noticeboard, unless you are getting an error when trying to import.

You should be able to use the upload form normally. Are you getting any issues?

This can be accomplished using Special:ManageWikiPermissions.

Per above, and the fact that Extension:EmailForm is not compatible with the most recent version(s) of MediaWiki.

It appears that the user Topology is the bureaucrat of that wiki, just FYI. I've opened up the wiki.
If you can't open a wiki, the request should be on Requests for adoption.

You could load it in as a gadget, by moving MediaWiki:Slick.js and MediaWiki:Slick.css to MediaWiki:Gadget-Slick.js and MediaWiki:Gadget-Slick.css. Then add the following to MediaWiki:Gadgets-definition:
* Slick[ResourceLoader]|default|Slick.js|Slick.css
Then, you could create MediaWiki:Gadget-Slick with information on what it does.

Is this still an issue?

Done in https://git.io/fhZzq

Task has been resolved upstream for a month.

The ability to delete namespaces has been added as of T3949.

I've worked on this in https://git.io/fhs1Z

cw_user was using a SMALLINT, which has a max size of 32767

I doubt there's any compromising going on here, otherwise this would be a security task. The original requester is still visible in the farmer log, so that does help.

This issue seems to affect all users created after Hearth to matilda was added to meta.

A user's contributions can still be attached to their account, without the need to delete and re-import content. However, it will require the use of a maintenance script. In terms of attribution, we believe that, as long as the full history of the pages is preserved, attribution is satisfied. We do not believe it to be within reason to require that all pages that were imported from another source link back to the original page.

Confirmed working on publictestwiki.com

I believe https://git.io/fhIPq will add default permissions for all extensions we currently have.

I've unlocked the accounts, they had appeared to be connected to another user, but the lock should never have been made. If they have any other difficulties editing as a result of a block or lock, let me know on my talk page.

Should the value be modifiable by Special:ManageWiki?

Per above

Works on all wikis I checked

Global issue

Per above

You should be all set now.

Hmm, I got an internal error on visiting the wiki and was logged out across all wikis.