Oh ok, well if it would be an issue, it's not a big deal as I can use my other domain. But maybe there's a way MH could block cookies from being seen by such subdomains. (I don't know much about how cookies work.)

But CNAME flattening as Cloudflare does wouldn't work for this?

Are you sure it's still against standards? The registrar has a slightly different name for it, CNAME flattening, and Cloudflare has a post about it being allowed: https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

Do you know if Miraheze could do a root domain pointed with CNAME? I know my registrar has the ability to do it, but the MH Meta page only mentions subdomains:

@OrangeStar Ok, cool. I opened a new one here: https://meta.miraheze.org/wiki/Special:OAuthListConsumers/view/146afa2c12459c0f73bb9fd00848e415

@OrangeStar It's a different domain. The Miraheze wiki domain ends in .org but this new one ends in .com.

Ok, I've got the other domain set up, so could I rerequest, but with a callback URL of https://comprehensibleinputwiki.com/auth.php?

Oh ok, I prefer to have the wiki on the top level domain, so I'll just host the other part of the website on a different domain. Unless the security concern is related to it being *all* subdomains, in which case only pointing to one subdomain would work for me. Or if you know of another way to point the top level domain to MH but the subdomains to another server, that'd be great. If not, this can be closed.

Also, I don't have much experience, but I'm not sure the format in the DNS file is correct. I think somewhere there needs to be *.comprehensibleinputwiki.org.

I think you put the wrong IP in. Should be 95.217.135.175 not 95.271.135.175.

Perfect!

Thank you!

Thanks!

@Reception123 Yes, please, as OrangeStar explained.

Ah ok, then it should be on the secondary subdomain. I haven't yet got the hostname connected, so I'll change status to Stalled until then.

It looks like the wrong wiki name was put in the settings: comprehensiblewiki instead of comprehensibleinputwiki

Can confirm that I get the same error. It appears to happen if comparing between the newest revision and any other revision if pressing the Compare selected revisions button. And sometimes between the newest and the second newest if using the Prev link.

I appreciate it!

Ok will do, thanks.

I just found that there is a setting in ManageWiki for this:

Thanks!

Thanks!

Copied from what I posted at Wikimedia:

In T10235#206316, @Void wrote:

Hmm, I've been looking over your logs and the only suggestion I have at the moment is to force the family to use https. I'm wondering if perhaps the request data is being lost in a http -> https redirection? Really not sure at the moment. However, if I'm correct, all you need to do is add the following to the family:

def protocol(self, code):
    return 'HTTPS'

In T10235#206316, @Void wrote:

... However, if I'm correct, all you need to do is add the following to the family: ...

In T10143#204428, @Reception123 wrote:

Unfortunately as you rightly point out this issue is upstream and as such there's nothing Miraheze can really do about it as far as I'm aware.

While I wouldn't recommend it if the option provided by Agent above is really that inconvenient for you, you could temporarily assign "skipcaptcha" to user in Special:ManageWiki/permissions.

In T10143#204344, @Agent_Isai wrote:

I recommend you temporarily promote your friend to "confirmed." After 5 days and 10 edits (or something around those lines), all users are promoted to autoconfirmed so after that, you can remove them from the confirmed group.