[06:23:36] Hi there, I want to use OCR and Charinsert gadgets on my wiki. I tried to copy the gadgets js and other files from Wikisource but for some reason they aren't working on my wiki. So may I know how to make gadgets work? I have already installed required extensions. Thnaks [14:40:47] hello [14:45:34] Is there any specific channel for CentralAuth? I could use some help from the devs that work on it. [14:48:06] no, you can ask here though [14:55:23] I've got a stuck rename that can't be fixed with fixStuckGlobalRenames.php, and I'm not sure how to proceed. It went through just fine on the other wikis we have, but one in particular just permanently shows as queued. I'm not sure how to debug from here. [14:56:26] At first I thought the problem was that I couldn't get the --logwiki param right, but I worked that out to be the wiki's DB name ($wgDBname). [14:57:53] Supposedly this rename has been stuck for a long time (a year +), but surely there has to be some way to get it requeued? Or maybe there's some kind of database problem with it? [14:59:46] Many potential factors at play... [14:59:56] do you have any error messages from the rename attempts or the script? [15:00:48] If I try to redo the global rename on wiki, it tells me there's one in progress. If I try to run the script, it tells me that there ISN'T one in progress on that wiki. [15:02:00] do they have (many) edits on that wiki? [15:02:36] Some but not many. Less than 20. [15:05:30] What's it say in the renameuser_status table for that user/wiki? [15:06:28] It does indeed show it as queued [15:08:20] if ( !$ca->renameInProgressOn( WikiMap::getCurrentWikiId() ) ) { [15:08:20] $this->fatalError( "{$ca->getName()} does not have a rename in progress on this wiki." ); [15:08:20] } [15:08:21] * Reedy looks [15:11:44] I wonder if it's easier to detach, rename, reattach at this point [15:12:42] what does Special:GlobalRenameProgress say? [15:14:48] Wow, okay, so I just managed to make it work. I went into LocalSettings and did an if ($wgCommandLineMode) to force it to load the specific wiki. That seems to have worked. [15:16:38] The script successfully logged and everything. [15:17:21] heh [15:17:36] some weird edge case then [15:18:01] I'm just glad it isn't a database problem [15:34:26] I think I understand what happened btw. --logwiki is just the wiki to write the log to, not the wiki receiving the rename. The default wiki selected when using the CLI will always be the main one, so it checked that DB against the rename instead of the one I wanted. [15:34:57] That's why forcing it to load the one I wanted with $wgCommandLineMode worked; it checked the correct DB that time. [15:35:02] probably... how do you normally run maintenance scripts against a specific wiki? [15:35:09] in WMF we do --wiki=foowiki [15:36:32] I think I've actually used this same solution to run scripts in the past. I don't usually do them, but this is typically how I upgrades. Guess it might be time for a better solution. [15:41:26] I take it most MW maintenance scripts accept a --wiki param? [15:45:20] I believe all do [15:45:57] It's somewhere in the base class from memory [15:46:09] how the WMF do it is a bit different with a wrapper around the lot [15:50:07] Yeah, makes sense. [22:16:01] ugh, what is the cause of '"CdxTypeaheadSearch" is not an export of Codex and cannot be included in the "codexComponents" array' on latest master? [22:16:47] Normally I'd assume some extension, but it looks like it is included in codexComponents in core