Currently, the Debian 10 servers should be 10.4 if they haven't been updated. See https://lists.debian.org/debian-announce/2020/msg00005.html

It would appear I've found the issue! I tried doing that before, but got an error saying "CNAME records on dynamic dns domains are currently restricted, contact an admin for assistance to have it enabled," so I just assumed it was wrong.

Import is in progress. Please note that it may take quite a while as imports are slow.

Where it says "destination" it should be mw-lb.miraheze.org

The above image shows the screen I'm looking at when trying to point the CName (I'm using FreeDNS). What exactly do I have to do to actually point it to mw-lb.miraheze.org?

It would also be a good way to avoid issues like T5827.

Long imports will timeout and show a 503. Please create a seperate task with the file to import and wiki and we will do it server side.

Huh, I just noticed that the button to reset everything got removed. Interesting.

It's a script

You can do this yourself in Special:ManageWiki/permissions. There should be button that says something to this effect.

Thanks for your assistance! I really appreciate it. Hope the error gets fixed easily

Adding subscriber per request on Discord

Latest stable version from 2013. No updates to the code whatsoever since 2018. Unmaintained.

Latest stable version from 2016. No actual updates to the code in 4 months (all more recent updates are bots). Seems unmaintained-ish and therefore declined, but going to allow security reviewers to have a second look in case I've missed anything.

Needs a ip purchase approval I think.

@Lawrencedepe It seems that after all there is still a mistake. Please make sure that the CNAME points correctly.

Yes, it was correct now :) Your wiki is now accessible at the custom domain.

The import has been completed. Assigning to RhinosF1 as he said he would investigate the internal error.

Have I completed it correctly now? Also, sorry for the change, but I updated the custom domain request to tla.awiki.org.

@Lawrencedepe Hi. It doesn't appear that you've correctly pointed your domain to us. Please read https://meta.miraheze.org/wiki/Custom_domains for how to do that.

In T5994#117426, @John wrote:

I was under the impression @Reception123 or @Paladox were dealing with this the other day.

I was under the impression @Reception123 or @Paladox were dealing with this the other day.

In T5994#117422, @John wrote:

Why does SPF need to approve something anyone in SRE can do of their own volition? If this is such an important issue, you’re creating a slowdown intentionally

Can it be approved then? Multiple members of SRE have seen this discussion and not actively stated an approval / decline.

In T6006#117420, @John wrote:

“ would require more resources to implement - potentially more than we are able to suitably give.” is a vital thing you did not reply to, the more critical part.

That's something I'm going to look into more as I think we should seriously consider it.

Why does SPF need to approve something anyone in SRE can do of their own volition? If this is such an important issue, you’re creating a slowdown intentionally

“ would require more resources to implement - potentially more than we are able to suitably give.” is a vital thing you did not reply to, the more critical part.

Would not solve problems

There's 100% duplication in the way jobs are processed. If the duplication detections works as I understand, it would reduce the load as less jobs to process. Concurrency limiting would also reduce the amount of resources a single type of job can take up and therefore reduce the impact of a spike in edits on loginwiki.

What are you doing Response is too late. It's funny to ignore opinions even if it's technically difficult.
Even if the conversation history disappears, please be sure to correct it.Quickly!!

Would not solve problems, and would require more resources to implement - potentially more than we are able to suitably give.

See T6006 as well, I think they'll go hand in hand well

@Zppix had to restart the jobrunner service again last night due to lag.

Per Sam's comment. Since the debug statement left out doesn't hurt anything we can install this

The SSL has been renewed.

In T4789#116738, @Reception123 wrote:

In T4789#115677, @Aunst wrote:

In T4789#115338, @Reception123 wrote:

@Aunst Per Southparkfan, have you tried other similar extensions and found that they were not suitable for you?

Yes, I've tried Extension:Comments, but I think it isn't suitable for my wiki.

Okay, for what reasons? Have you also tried Flow?

https://vedopedia.witches-empire.com/wiki/User:Затейник/песочница1 (sandbox1)

In T5750#117090, @Southparkfan wrote:

@Paladox, what was the reason this extension was declined as 'hard/impossible to install'?

In T5998#117295, @RhinosF1 wrote:

Cc @John as I think ManageWiki uses it so he can confirm but is it not already available?

Opened https://github.com/fuerthwiki/MobileTabsPlugin/pull/1 for

There's also a debugging statement left in extensions/MobileTabsPlugin/resources/tabs2accordion.js, which should be taken out but which doesn't really hurt anything.

The code here looks sort of old-ish, but fine from what I can see. However, an error is being thrown about the registration of the parser functions:

Already available. Please check Special:ManageWiki/extensions before filing tasks.

This looks fine to install, I think.

Re security reviewers (@Samwilson @Southparkfan ) this looks like a very quick review