You can only request to get your own username changed, except for a few situations (generally usurpation of an unused account).

Handled by @Paladox

Renameuser is only available to be used at a global level. To request a global rename, please use https://meta.miraheze.org/wiki/Special:GlobalRenameUser

@Paladox likely related to the change you made earlier today.

Tempted to raise priority, assuming that the two tasks I merged were related to this one.

Per above.

Try removing the colon (:) before the url (//static.miraheze.org/pastportwiki/5/5a/APP_Logo_160p.png). Also, logos tend to fit best when sized to 135px square.

@Noblets563 any way you can confirm your identity?

In T3861#76987, @Void wrote:

Is there an upstream task for Extension:Editcount?

It takes ten to twenty minutes after enabling visual editor before it can begin to work. It should be functional now.

In T4702#89511, @RhinosF1 wrote:

In T4702#89510, @Void wrote:

All done, except Naf, because that's not supported in our options anywhere.

Added to mw-config

All done, except Naf, because that's not supported in our options anywhere.

Rename now in progress

This will be converted to an opt-in feature, both at the wiki level, and the individual user level in https://git.io/fjxsz

Currently, the extension still needs a lot of work. As it stands, it functions like the existing CheckUser extension (not globally), except it uses a different table in the database. However, it took me about an hour to figure out how to get it working at all. There are a number of edits that still need to be made where the code references the wrong DB tables and columns, as well as other problems.

I goofed above, can confirm that there is a DBQueryError when attempting to update a SocialProfile profile on the wiki.

Seems @Paladox didn't properly enable PollNY, or something went wrong, but anyway it should now be fixed. (You can delete my test if you like).

I'll be taking a more in-depth look at this extension in two days or so, but I did notice that there are a few typos in the extension.json file.

I've restored the bureaucrat group to have the managewiki permission. You should then manage the rest of the groups to what ever way you see fit, while retaining access to this permission.

It's in the math extension, I don't know how to change the color of the generated png.

Simple enough fix, wound up spending more time standardizing the indentation of the file.

Got one of these on a userrights change just now, and noticed several while deleting pages previously.

@Reception123 it is listed in P214

Lowering priority to be consistent with T4584

Wikilog is not compatible with the latest version of MediaWiki. I will note that though the extension code has been modified as recently as three months ago, the documentation appears to be around three years outdated. However, open issues on the github, as well as comments on the talk page, suggest that compatibility with the latest MW versions has never been added.

This issue is not unique to ATT, I've received a few reports of this previously and mentioned it. I think there is some issue with setting/reading cookies, but I have no idea what.

Using Special:ManageWiki/namespaces, you can change the default content model of the talk namespaces to Flow. This should force new pages to be in the flow format. To migrate pages, they will have to be deleted, or moved to an archive location. Unfortunately, there is not currently a way for this to be done automatically, although I believe there should.

It's a global extension. It is enabled on all wikis all the time.

I'm also getting similar errors using the Poll extension. Would this be because of having one enabled, and then the other?

In T4557#86740, @RhinosF1 wrote:

In T4557#86728, @Levreauj wrote:

Sorry but it does not work
I think it as to do with a mistake in the variable name in the setup filek from the extension page the variable starts with "eg" and no "wg"
I've look at the commit in Phabricator.
Thanks !

I’m struggling to find where the spelling error is. Can you give me its line number?

You need to import MediaWiki:Common.css.

Fixed locally, but ideally shouldn't happen.

I've restored the bureaucrat group, which should at least allow you to manage your wiki again and reset it to where it was before.

I'm also noticing an issue where the contributions page (example) is throwing an internal error. It's probably something different, but should absolutely be looked into.

@GoddessofTirar I hate to see how long that this has gone without a response, please let us know if you are still interested in this.

@Paladox (again)

@Paladox status?

Done by @Paladox a few days ago apparently.

@Hypercane Can you confirm what protection levels you want, and what groups should have access to them?

Is there any specific error message? Might be useful for figuring out what's up.

Would it at all make sense to just add all custom protection levels to wgAvailableRights? That way they can be assigned with ManageWiki.

I've added managewiki to founder, as that's easy. TidyConfig is set by default to RemexHtml.

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

Just got around to it.

This can be enabled using Special:ManageWiki/extensions

ParserFunctions is enabled on all wikis by default.

Please use Special:ManageWiki/extensions.

@Paladox ^

Chrome, and it only seems to appear when I have the console open on a page reload. Using Microsoft edge I instead get "CSP14307: Source ''self'' was already provided for directive 'default-src' for Content-Security-Policy."

@Paladox last person to touch CSP config.

@John purging the cache wasn't a fix, as the issue would seem to be fixed, but would return upon loading another page or reloading the same page. In fact, sometimes clearing the cache just plain didn't work.

Depending on your email host, you can probably configure a filter so that all Miraheze emails are never marked as spam.

Image dumps need to be generated by sysadmins, see J8.

I'm also noticing similar behavior on toxicfandomsandhatedomswiki (many files missing as of today), digimonwiki (several files missing), and testwiki (one file). Not sure of other wikis are affected, but it seems likely.

@Paladox ^

Hmm, seems to be the CSP. Guess we'll have to figure out how we want to do external images, when we limit the external resources that can be loaded.

https://git.io/fj3EI is likely the fix.

I can't seem to replicate using Special:ManageWikiPermissions alone. Is it possible to be leftover from when this happened before, or is there some other cause (like wiki creation)?

Fixed in https://git.io/fjOQ4

Seems like it was possible to delete it and restore it, and looks like that fixed it. Odd though, I'm not actually sure what happened there.

I've spun up https://git.io/fjmYW to fix the issue.

I spun up a quick testing environment and discovered that the issue is caused by MWP only saving perms that are visible on the page. In other words, any blacklisted perm is removed from the user group as soon as the form is submitted.

Should be resolved now, please re-open if not.

We should either move on this, or figure out another way to get more space on db4, as the disk space has been pretty much stuck in critical for some time now.

That's definitely something that deserves more investigation if possible.

No idea.

If I'm not mistaken, we're out of space again.