The same thing happened as I said on T5034#96189, although this time I was able to resolve it by following the instruction on that task.
Why such login issue is occurred whenever the database name is changed?

In T5228#99546, @Intdevalliance wrote:

Hey, sorry, i really didn't want to start an argument, i just need help to make sure '*' group can edit without logging in, that's all. Any changes i have previously made, were an attempt to allow this group to do this, not the other way around. No bad intention. So the changes you noticed were definitely an accident.

I created this wiki, and i really just want users to be able to get involved in an easy a way as possible, so giving editing rights without logging in seems the best way to do this, if i can find a way to assign this permission.

Many thanks

That is the default settings of Miraheze wikis, as well as MediaWiki itself. If it ain't broke, don't fix it.
Phabricator is not for stuffs that can be handled locally. So do it yourself.
Go here and re-check ALL the permission you have removed. I'm sure you can do this as long as you can understand English. I'm copy-pasting the log again for what you have removed:

01:40, 8 February 2020 Intdevalliance (talk | contribs) changed group metadata for Special:ManageWiki/permissions/*: add rights (none); removed rights editmyoptions, editmyprivateinfo, editmywatchlist, viewmyprivateinfo, viewmywatchlist, writeapi, abusefilter-log-detail, abusefilter-view, abusefilter-log, oathauth-enable, urlshortener-create-url; added addgroups (none); removed addgroups ; added removegroups (none); removed removegroups ; added addgroupstoself (none); removed addgroupstoself (none); added removegroupsfromself (none); removed removegroupsfromself (none); modified autopromotion (no) (open editing)

You also have threatened, complained, and tried to force, censor and/or oppress when the saying doesn't "fit" for you, even to some other users.
I have seen such situation for several times, even their saying (clearly) has no problems, so that the user must feel bittered and argument to such your judgement.
We are not here to adulate you, please you nor say only in the way you "fit".
I decided not to tolerate your such judgement anymore, never, in whatever circumstances. Trying to force me will result in the completely opposite situation.
I also remember you have tried to censor the freedom of speech for certain religion in a wiki request. I take freedom of speech very seriously and always say "NO" to censorship, in any circumstances. No exceptions.

@PlavorSeol: I’m sure it was accidental and they don’t realise rather than are pretending. Please assume good faith and follow the Code Of Conduct while using Phabricator.

So yeah, you assume good faith of them, but not me, right?
I won't tolerate threatening and any trial to force me anymore, for whatever reasons in any circumstances, no.

Configuration mistake - should be handled locally

Do you think I will be threatened with such threatening?
@Intdevalliance THERE IS A SUFFICIENT EVIDENCE THAT YOU HAVE REMOVED SUCH PERMISSION. DON'T LIE WHEN YOU ARE ASKING FOR HELP.

You have removed the bunch of permissions from * group, and this log proves this:

01:40, 8 February 2020 Intdevalliance (talk | contribs) changed group metadata for Special:ManageWiki/permissions/*: add rights (none); removed rights editmyoptions, editmyprivateinfo, editmywatchlist, viewmyprivateinfo, viewmywatchlist, writeapi, abusefilter-log-detail, abusefilter-view, abusefilter-log, oathauth-enable, urlshortener-create-url; added addgroups (none); removed addgroups ; added removegroups (none); removed removegroups ; added addgroupstoself (none); removed addgroupstoself (none); added removegroupsfromself (none); removed removegroupsfromself (none); modified autopromotion (no) (open editing)

Every time you make a change to the wiki, MediaWiki logs ALL of them to either the history of corresponding page or the log. There is a definite evidence for your action, and you cannot pretend as you didn't do it.

This task is not related to the technical issues with Miraheze, as well as T5211.

DIY

01:40, 8 February 2020 Intdevalliance (talk | contribs) changed group metadata for Special:ManageWiki/permissions/*: add rights (none); removed rights editmyoptions, editmyprivateinfo, editmywatchlist, viewmyprivateinfo, viewmywatchlist, writeapi, abusefilter-log-detail, abusefilter-view, abusefilter-log, oathauth-enable, urlshortener-create-url; added addgroups (none); removed addgroups ; added removegroups (none); removed removegroups ; added addgroupstoself (none); removed addgroupstoself (none); added removegroupsfromself (none); removed removegroupsfromself (none); modified autopromotion (no) (open editing)

@Intdevalliance Hey, where are the rest of permissions you have removed from * group?

I would like to enable edit rights for all visitors to this Wiki

01:40, 8 February 2020 Intdevalliance (talk | contribs) changed group metadata for Special:ManageWiki/permissions/*: add rights (none); removed rights editmyoptions, editmyprivateinfo, editmywatchlist, viewmyprivateinfo, viewmywatchlist, writeapi, abusefilter-log-detail, abusefilter-view, abusefilter-log, oathauth-enable, urlshortener-create-url; added addgroups (none); removed addgroups ; added removegroups (none); removed removegroups ; added addgroupstoself (none); removed addgroupstoself (none); added removegroupsfromself (none); removed removegroupsfromself (none); modified autopromotion (no) (open editing)
Didn't you remove all permissions from * group?

@Reception123 The Yet Another Simple Event Calendar extension that this user previously requested on T5080 was failed for security review, and I think they are about to try another one.

It is possible, but the wiki will be read-only during migration. See also T5034.

You need a wiki to import, so you should request a wiki first. Once the wiki is created, then you can request to import. You should also upload the XML dump here.
I don't understand why @John reopened this task even though it is invalid as it is for a nonexistent wiki, but for now I'm changing the status to Stalled until the wiki is actually created.

DiscordNotifications extension cannot be disabled and it isn't on the ManageWiki.

That wiki does not exist.

By the way, projects should be added as tags rather than subscribers.

Indexing special pages are generally disallowed, as special pages are user interfaces for several functions rather than actual content pages. Wikimedia wikis also disallow indexing them, and example in Manual:Robots.txt on MediaWiki.org also explains about it. I also don't think it should be allowed (at least by default).

@Bd3076 I don't think that is possible unless they passed --report <interval> parameter when they ran importDump.php.

Should we upload the XML dump directly here rather than using Google Drive in order to proceed to import?

I don't see such extension in Служебная:Версия page on your wiki.

That page has both {{Page security extension disclaimer}} and {{Extension code in wiki}}. Should we really install this?
@Helper Why don't you use protection?

CC @LeeEuiSup who said the opinion above

Actually there was an opinion on 백괴게임:오락실/2020년 1월 page on temporary server of 백괴게임 미러 that they should request for import of only latest revisions of their pages:

잘 모르겠습니다. 그러나 백괴사전은 모든 문서의 모든 역사를 복구해달라고 부탁했으며, 오류가 발생했다는 서버 관리자측의 메시지가 있었기 때문에 백괴게임의 경우에는 최신 판만 백업하는 방식이 좋겠습니다. 곧 서버 이전에 대한 조언을 제 사용자 문서에 작성할 계획이니, 참고해 주시면 감사드리겠습니다. --이의섭 (토론) 2020년 1월 21일 (화) 00:03 (KST)

But it will be a violation of BY clause of CC BY-NC-SA 4.0 if we actually do this, because it is required to export full histories of pages to comply license, as described on Moving a wiki to Miraheze page on Miraheze Meta.
So I checked whether they do what they said or not. (That should not be done.) I checked the XML dump and it contains full history of each pages, and I confirmed personally on Discord that the requester exported the full histories, so now it is fine to proceed to import. Thank you.

Please hold on this request before actually starting import because I have to make sure some stuffs with the requester.

MediaWiki is not designed to be a Content Management System (CMS), or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content.
- Security issues with authorization extensions page on MediaWiki.org

Partial read restriction (per-page, per-namespace, etc.) is generally not available on MediaWiki.

However I hope it wouldn't be specific to that wiki, but available to all wikis. (And set to "deny" by default.)

This may be done on requests, but this should NEVER be done by default, and there is NO reason to do so. Period.

@Hispano76 Even though this task was closed a few days before, I'm here to clarify and correct this:

In T5057#96386, @Hispano76 wrote:

I used this request in Wikimedia Phabricator as an example. But I just saw that apparently it didn't work and they must have used a different attachment and page. I didn't check anymore, you could see it. Or else wait until tomorrow. @Jidanni

@revi seeing as you're the one who opened that assignment, can you contribute to the sitenotice on kowikipedia?

미디어위키:Gadget-siteNotice.js page on Korean Wikipedia is not for using as an alternative of $wgMinervaEnableSiteNotice. The purpose of introducing siteNotice gadget is for preventing search engines (especially Google) from crawling the text of notices that results showing the notices' text on search results instead of the page's content.

Could you re-review this extension? The forked version of original one seems to be still maintained.
(Related diff on MediaWiki.org: Special:Diff/3174229)

Now I am able to log in to that wiki. Maybe the DB renaming process caused an issue to my session?
Thank you!

Even my global user page doesn't show up on 진실위키. Is my account detached from it?

Imports per requests on Phabricator are done with importDump.php script, not web interface (Special:Export page), and it does not have any checkbox.
The script assigns edits to local users by default where they exist.

It says "당신의 세션에 대해 현재 로그인 시도가 이루어지고 있지 않습니다." ("No active login attempt is in progress for your session."), which is the content of centralauth-error-nologinattempt message.
Moreover, when I log in on Miraheze Meta, visit 진실위키 and then return to Meta, I am also logged out on other wikis.

I'm not able to log in on that wiki after renaming its database name.

Just edit MediaWiki:Scribunto-doc-page-name page on your wiki.

Closing this task as the commit is merged.

When it can be done? More than 4 hours elapsed but many pages are still missing.

I still see "weather.miraheze.org" in Special:CentralAuth.
Please remove such entry from attached users' Special:CentralAuth as well. Thank you.