Related: T277628
maybe: T57734

Proposed hook would be ConfirmAccount::checkRequest, would run before inserting the request into the submission queue, and would only be passed the AccountRequestSubmission object.

In T265309#10243215, @Tacsipacsi wrote:

By a hook, I mean the extension handling some appropriate hook (SpecialPageAfterExecute?) to change the MediaWiki behavior

I have interest in taking stewardship of this extension. As I mentioned elsewhere, I'm interested in restoring some of the book rendering capabilities of this extension. I'd like to maintain these functions for people that need them in a way that they don't conflict with the needs of the WMF.

In T374888#10229877, @akosiaris wrote:

I think a first step would be to make that offer in T224922: Code Stewardship Review: Collection Extension

In T265309#10223836, @Tacsipacsi wrote:

In that case, maybe a hook handler could hook into Special:AllPages and enable crawling without adding a new special page (although removing Special:CrawlableAllPages would be a breaking change; I don’t know how many people use that extension and how much they would be impacted). @MarkAHershberger, as the author of this extension, what are your thoughts?

Visiting Special:Book in a Firefox private window clearly shows the Book creator bar with the option to disable it:

I've been looking at forking (or adding to) DownloadBook in order to provide rendering for Collection via Chrome on a smallish wiki (since a first pass with Weasyprint or pandoc, the backends it currently offers, aren't suitable for my purposes). Its ugly, but shows promise.

The redirect code was a red herring.

OutputPage only accepts 301 or 303 and, in any case, I think the root problem has another solution.

Hmm... Looking more closely, it looks like Chrome is caching the redirect it gets from Special:PluggableAuthLogin since the initial request to the URL shows 302 Found (from disk cache) in the browser's dev tools.

Oops, think this was T354498

Note that the hard-coded versions in LuaStandaloneInterpreter::getLuaVersion will have to be updated.

Adding Robert since he is familiar with the components and I've been trying to get him to document/publicize them more.

I created a couple of patch files that can be applied to a pristine copy of a git repo for lua 5.1.5 (as noted elsewhere, this isn't tagged in the github repo for lua) that will hopefully be of use. I've left stubs in the README-WMF for someone to document build instructions so that the binaries could easily be reproduced.

In T366824#9876360, @sbassett wrote:

Looks like @Reedy and @tstarling answered your questions, @MarkAHershberger? Did you need anything else right now or can we resolve this?

I think the results I got on my local wiki means this is safe. On a page in the module namespace, I have

local p = {}
function p.hello( frame )
	coroutine.wrap(p.hello)()
	return "Hello, World!"
end
return p

In T366824#9869346, @MarkAHershberger wrote:

How can I verify that coroutines are disabled or not possible from MediaWiki?

In T366824#9868257, @Bawolff wrote:

it isn't clear that CVE-2021-43519 has been addressed at all.

That looks like only applicable to coroutines, which i think we disable (or at least luasandbox disables, im not sure about lua standalone)

And < and >

Also &quot;

Updated task with explanation (that I discovered while trying to fix this).

Updated the quibble.sh to remove some stuff and it seemed to work. I the problem before was a command I provided (for debugging) right before $DEPENDENCIES that I forgot to remove.

In T249573#9388985, @CCicalese_WMF wrote:

I propose that we rename this task to: "Remove support for specifying a MediaWiki version in an extension/skin composer.json" and make the Motivation in the task description consistent with that.

A bit better search would be for #!/usr/bin instead of /usr/bin/env.

When the script was written the use case--using the WMF's mwscript--was a bit unusual.

@Kghbln, What are the results of show create table searchindex?

I have had a busy few months with a new job and other obligations. @cicalese has been working with me to move WikiApiary back to WMCS, but we've run into problems with SMW.

is it fair to assume, give this unfortunate time lag of a decade, that this request no longer necessary?

No problem. I'll restrict my use of gitlab for now to anything that can be stored in the repo so that if the server side has a huge snafu ("steps on my toes"), I'll be able to recover quickly.

This is not for WMF production. If I can get ownership of it for now, that'd be great.

I want to use the name comment-streams-all-discussions since this is the special page that is the focus for implementing T193234.

As I commented there, I agree with this from @Krinkle:

I don't recall the exact reason. I'm happy with removing it or updating it as you see fit.

In T339877#9032671, @bd808 wrote:

@MarkAHershberger please update this ticket to fit with the guidance from Cloud-VPS (Quota-requests) so that we can put it through our normal process.

I'm not sure what you should do with this since I haven't thought about it in 10 years. Mobile technology and data connections have changed significantly in that period of time, also.

done