In T11496#230564, @Hunt209 wrote:

I just enabled it after it was not greyed out! Thank you.

Hi, this is available in Special:ManageWiki/extensions under the "other" tab.

Putting this back into consideration.

This can be enabled in Special:ManageWiki/extensions.

This can be done in Special:ManageWiki/extensions.

Whilst not a member of SRE; it is very unlikely that this would be approved given the big warning at the top of the extension regarding potential security issues. Even more so without anyone to security review it.

Done with 695a9fe558bff1d59714958a7bb7df9dcd7d451f.

Are these comment dumps from Fandom? It looks as though they are; I do not believe that importing comments from Fandom is possible.

In T11477#230274, @Bazzinioli wrote:

In T11477#230268, @Original_Authority wrote:

This issue was fixed in T11466, but a Steward will need to go back and give you the rights, since your wiki was created before the issue was fixed.

Do I need to contact a steward then? Or do I just wait now?

This issue was fixed in T11466, but a Steward will need to go back and give you the rights, since your wiki was created before the issue was fixed.

Withdrawing this.

I've added the patches and this should now be ready for SRE review per this change.

PR: https://github.com/miraheze/mw-config/pull/5380

Setting $wgExternalLinkTarget to _blank (the second option), should do what you're asking; if it isn't working as expected, then something else is amiss.

This is available in ManageWik/settings under the "links" tab.

I would generally opt for Redis due to the persistence, rather than Memcached.

Answered in T11451, is in relation to ReplaceText, which is not compatible with Miraheze.

The ReplaceText extension is not compatible with Miraheze. Please use MassEditRegex instead.

Duplicate of T11452.

Roughly this translates to "I want to download a wiki extension"; please provide more detail exactly which extension you require for your wiki.

DismissableSiteNotice is already a global extension on Miraheze and will work without further setup.

In T11375#228523, @MacFan4000 wrote:

Unfortunately an NDA is required for SRE access, and to my knowledge, we aren't currently in a position to process new ones at the moment.

Apologies, that's my bad — reading my reply back, it does sound passive aggressive from my side but I did not intend it to come across that way :)

@Agent_Isai — SRE as above.

No longer necessary, per discussion on Discord. Paladox will re-open the task when needed.

@Honglan233 — is this still happening?

@Tiv please provide the wiki you wish this to be enabled on so it can be enabled just for that wiki.

PR to remove the setting since it has been removed in 1.40 https://github.com/miraheze/mw-config/pull/5355

@LAnonyme16 — is this still happening?

Also cannot reproduce this and since the task author has not replied to Redmin, it can be assumed that they are either no longer experiencing this, or that it is fixed.

The CSS hasn't changed:

div.thumbinner {
    background-color: <colour>;
}

Please see the conversation in Discord.

Please note that if you are not using Let's Encrypt you will need to provide and purchase your own SSL certificate.

PR: https://github.com/miraheze/mw-config/pull/5327

PR https://github.com/miraheze/CreateWiki/pull/447, potentially stalled waiting on a member of SRE to review — perhaps this can be pushed to betaheze?

HitCounters has been disabled on Miraheze for quite a while due to performance issues and is due to be undeployed come 1.40.

PR https://github.com/miraheze/puppet/pull/3444

Orain.org seems to have been renewed until 2024, so the consensus seems to be in keeping the domain at least for now. Closing this task to clear the backlog until it can be evaluated again.

Merged.

This extension seems fine, doesn't appear to be any security risks. The only concerning thing is that it hasn't had any edits in over 3 years (which I guess isn't an issue because it does what it needs to), but it uses wfGetDB() which is depreciated.

pull request.

Feedback welcome.

The ReplaceText extension isn't compatable with Miraheze and database compression. You can use MassEditRegex instead, which is available in ManageWiki.

In T10844#221750, @AmandaCath wrote:

Unfortunately my RL is becoming exceptionally busy to the point that I don't think I'll have the time to actually finish this. Whoever ultimately picks this up, if you want any part of the code that I had partially developed, please contact me.

In T10966#221059, @Redmin wrote:

Why implement as a maintenance script though?

In T10961#220990, @labster wrote:

In T10961#220937, @Original_Authority wrote:

I'm just going to give my two cents here, but increasing the timeout for NGINX is probably not the best idea. Miraheze's resources are already stretched thin and increasing the time that connections are left open would only add to the strain on the servers for probably something little wikis will actually need to utilise. It would probably be more worthwile getting a steward to provide the dump rather than all of the potential side effects of raising the timeout limit.

The static server just serves files, right? How does leaving connections open longer increase strain on the server? Please explain.

Second PR to actually remove the git submodule; changing to stalled for now awaiting SRE merging/comments.

In T10961#220938, @Agent_Isai wrote:

The dump is already there so a Steward really can't do much.

They can retrieve it from the server and pass it on.

I'm just going to give my two cents here, but increasing the timeout for NGINX is probably not the best idea. Miraheze's resources are already stretched thin and increasing the time that connections are left open would only add to the strain on the servers for probably something little wikis will actually need to utilise. It would probably be more worthwile getting a member of SRE to provide the dump rather than all of the potential side effects of raising the timeout limit.

This is not a high priority task.

This PR removes WikiForum from ManageWiki and its associated configuration.

In T10844#220686, @AmandaCath wrote:

I'd assume that this would go in here https://github.com/miraheze/CreateWiki/blob/1f993cc82cc9b1649d195ac614e962bc19f1add7/includes/RequestWiki/SpecialRequestWiki.php

If I'm right about that, I can try to write at least an initial version of something like this for T10931#220644 when I have some spare time (should have this week).

In T10915#220081, @RhinosF1 wrote:

In T10915#220073, @Original_Authority wrote:

Can someone clarify what "completely broken" means? I'm experiencing no such issue running the master branch on 1.41-wmf-11?

You won't be running parsoid for read. It's not landed in master yet. If you follow the upstream tasks, they might have landed the query parameter. If not, they'll be a lot of gerrit patches about to be merged you can use.

Can someone clarify what "completely broken" means? I'm experiencing no such issue running the master branch on 1.41-wmf-11?

In T10351#209186, @Void wrote:

I've gotten it working on test131 with https://github.com/miraheze/CreateWiki/pull/376, waiting for CI before I merge.

Interesting — I'm not using OAUTHAuth and the issue persists for me. Does that definitely look to be the root cause?

In T10351#209059, @Reception123 wrote:

In T10351#209050, @Original_Authority wrote:

This doesn't appear to be a Miraheze isolated incident, but definitely seems to be something that changed between 1.39 and 1.39.1. I'm running CW and can confirm the same behaviour happens. When a wiki is created, I get a success message, and everything seems to be alright. The database file <database>.json is created for the wiki, but the entry isn't added to the databases.json file, so $wgServer is just being set as the domain name and not the wiki domain. Just thought I'd add a bit more to the debugging of sorts :)

Could you clarify whether you'd confirm for sure that it worked on 1.39 (not the RC)? Since we can't seem to remember whether we tested it on 1.39 RC or on the actual 1.39 version. Since that would narrow things down a little. But thanks for your help either way!

This doesn't appear to be a Miraheze isolated incident, but definitely seems to be something that changed between 1.39 and 1.39.1. I'm running CW and can confirm the same behaviour happens. When a wiki is created, I get a success message, and everything seems to be alright. The database file <database>.json is created for the wiki, but the entry isn't added to the databases.json file, so $wgServer is just being set as the domain name and not the wiki domain. Just thought I'd add a bit more to the debugging of sorts :)