Will the Two-factor Authentication previously set up in Wikitech still be effective for LDAP, or will it become invalid along with the migration to SUL?

https://zh.wikipedia.beta.wmflabs.org/w/index.php?title=Template:Navbox&oldid=8047 has an error message: "The text of this revision is missing or corrupted." Although the error content is somewhat different, could it possibly be related to this task?

Thanks for taking the time to investigate.

In T363087#9739890, @taavi wrote:

Since /data/project is a symbolic link to /mnt/nfs/labstore-secondary-tools-project on Toolforge, some tools such as pnpm will write /mnt/nfs/labstore-secondary-tools-project instead of /data/project to the file, so that it cannot be executed in the container.

Does this happen if you run pnpm inside a container?

Sorry, I accidentally forgot to turn off the notification option, please ignore the demo above.

According to simple research, wgContentTranslationPublishRequirements is only used on the Web side, and no interception is performed on the PHP side.
mw.cx.init.Translation.prototype.checkIfUserCanPublish to verify whether it is published in the main namespace is only used by the onNamespaceChange hook (mw.cx.init.Translation.prototype.onNamespaceChange) and the hook does not seem to be triggered during initialization.
Edit: this.veTarget.getPublishNamespace() in mw.cx.init.Translation.prototype.checkIfUserCanPublish is null in first call beacuse of unknown problem.

It seems that a gadget forgot to list oojs-ui as a dependency, causing a race condition, and the Chinese Wikipedia happens to have a gadget that may trigger a race condition. ReferenceTooltips is defined as:

* ReferenceTooltips[ResourceLoader|dependencies=ext.gadget.HanAssist,mediawiki.util|skins=vector,vector-2022,monobook,timeless,modern,cologneblue]|ReferenceTooltips.js|ReferenceTooltips.css

Sorry, I wanted to point out that no changes need to be made is problematic. Lua api mw.title:inNamespace would detect the existence of the incoming namespace and throw an error. Abruptly removing the namespace obviously destroys some modules. e.g. Module:PJBSClass#rev80701284@zhwiki

Two questions:

1. Should the redirect page use design similar to a general redirect indicating that this is a redirect instead of continuing to use scribunto-doc-page-does-not-exist/scribunto-doc-page-show?
2. Does not support any syntax that is different from return require [[Module:Target]] (even if the number of spaces is different return require[[Module:Target]], or quote return require "Module:Target", etc.) is a "feature" of this new functionality?

Sorry, it seems it was a misunderstanding on my part.

In T352592#9380789, @Umherirrender wrote:

Trying to put some information here
The default skin on zh.wiki is: vector-2022
It seems you visit the page logged in with account having the skin set to vector (legacy vector from 2010)

• Does this needs a specific language or variant?

No.

• Mobile site or desktop site?

Desktop. (It seems to be no reason to use vector-2010 on mobile site?)

• Could you reproduce this also for a old revision view as linked above or only when the special page is in the current revision?

Both.

According to testing, although AbuseFilter was indeed recorded after the patch, edits were not properly blocked. Moreover, the differences left by AbuseFilter are not correct, and a JSON escape sequence appears.
log: https://zh.wikipedia.beta.wmflabs.org/wiki/Special:AbuseLog/1210
diff: https://zh.wikipedia.beta.wmflabs.org/wiki/Special:Diff/23457

In T346760#9227269, @Urbanecm_WMF wrote:

@ Func @SunAfterRain Do you mind testing this again on zhwiki, and reporting in case this still happens? It appears to work fine on my end now.

It seems to still happen, but it doesn't seem to happen in safemode.
normal reqId = 366bbc88-ad74-46d9-b8fb-06b7c57179a3 (skin=vector-2022)
safemode reqId = db24ffe6-0264-41b5-9b3b-3fd07491971f (skin=vector-2010)

The following deprecation message was captured after applying patch 958540:

PHP Deprecated: Use of RequestContext::getMain while called from MediaWiki\SpecialPage\SpecialPageFactory::capturePath is deprecated since 1.41. [Called from GrowthExperiments\WelcomeSurveyHooks::onSpecialPageBeforeExecute]
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, string)
#1 /path/to/mediawiki/REL1_40/includes/debug/MWDebug.php(382): trigger_error(string, integer)
#2 /path/to/mediawiki/REL1_40/includes/debug/MWDebug.php(352): MWDebug::sendRawDeprecated(string, boolean, string)
#3 /path/to/mediawiki/REL1_40/includes/GlobalFunctions.php(791): MWDebug::deprecatedMsg(string, boolean, boolean, integer)
#4 /path/to/mediawiki/REL1_40/includes/context/RequestContext.php(551): wfDeprecatedMsg(string)
#5 /path/to/mediawiki/REL1_40/extensions/GrowthExperiments/includes/WelcomeSurveyHooks.php(138): RequestContext::getMain()
#6 /path/to/mediawiki/REL1_40/includes/HookContainer/HookContainer.php(160): GrowthExperiments\WelcomeSurveyHooks->onSpecialPageBeforeExecute(GrowthExperiments\Specials\SpecialManageMentors, NULL)
#7 /path/to/mediawiki/REL1_40/includes/HookContainer/HookRunner.php(3729): MediaWiki\HookContainer\HookContainer->run(string, array)
#8 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPage.php(694): MediaWiki\HookContainer\HookRunner->onSpecialPageBeforeExecute(GrowthExperiments\Specials\SpecialManageMentors, NULL)
#9 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPageFactory.php(1475): SpecialPage->run(NULL)
#10 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPageFactory.php(1545): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext, boolean, MediaWiki\Linker\LinkRenderer)
#11 /path/to/mediawiki/REL1_40/includes/context/RequestContext.php(577): MediaWiki\SpecialPage\SpecialPageFactory->MediaWiki\SpecialPage\{closure}()
#12 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPageFactory.php(1541): RequestContext::withDeprecatedGetMainAccess(string, string, Closure)
#13 /path/to/mediawiki/REL1_40/includes/parser/Parser.php(3205): MediaWiki\SpecialPage\SpecialPageFactory->capturePath(MediaWiki\Title\Title, RequestContext, MediaWiki\Linker\LinkRenderer)
[removed as unimportant]

There is no consensus and no specific direction for practice.

@Jdlrobson The bug appears to be broken by the https://gerrit.wikimedia.org/r/824303 (:
Another broken example

https://github.com/Frederisk/Wikitext-Extension-Gadget/issues/5

In T318180#8250227, @Aklapper wrote:

Hi @toorich, thanks for taking the time to report this! Please provide a full, clear, complete list, including all full URL/links and search terms as text, which allow someone else to reproduce the problem, without any interpretation. I cannot reproduce this, but I might not perform the correct steps.

No longer occur.

In T244635#7596218, @Dbrant wrote:

@Urbanecm Thanks for the heads up. Would someone mind restating the exact steps to reproduce this from the Android app?

In T307322#7909405, @Dylsss wrote:

Note that this would introduce bypassing Lockdown without any checks that a user can access the undoafter revision.

done by xiplus in https://zh.wikipedia.org/wiki/Special:Diff/71043781

So what happened to this task? Why it didn't mark weekly blocker tracking task? It truly broken something.

Also what is the domain name of sysop_itwiki?

https://sysop-it.wikipedia.org/