ugh... spoke too soon. I have 7.5.0 which should include this. *sigh*

Just ran into this bug. Thanks for the fix :)

wrong repo

In my test, the patch works. It would still be good to hear from @Zorua_Fox, though, to confirm.

In T391074#10893567, @Zorua_Fox wrote:

@MarkAHershberger Additionally, I noticed a potential timezone display error in CommentStreams.

@Zorua_Fox try the version tagged 8.0.3. It worked for me without giving those errors.

I'm able to reproduce a similar traceback in regular page loads with just SMW+CommentStreams on 1.43.

@Zorua_Fox could you try removing Gadgets and installing CommentStreams temporarily to see if the problem recurs?

Thanks for the repo... I asked if you had upgraded because I thought you were running CommentStreams for a while, but I can see now that you installed it and then removed it on the same day. This is a good resource for troubleshooting.

Thanks for the ping. I'll try to look later, unless @Osnard beats me to it. I don't think this is related to the SMW bit as that has been here a while.

I just ran refreshImageMetadata on all the files and, even though exif says File:DotMobi_logo.jpg (and, on the wiki before I ran the update, it had said there was an error), now the image's metadata section gives the comment field that exiftool displayed.

None of the pages in @AlexisJazz comment currently exhibit the problem but I just came across this on ICANNWiki when tracking down silenced errors in our debug log with the following message: PHP Notice: unserialize(): Error at offset 0 of 1 bytes.

Note that this is still happening on 1.43. Dropping the hyphen would allow title matches without causing DB errors.

T388862

As of 1c39d53111a the behavior here has changed. Here is a sample script to reproduce the problem:

#!/bin/bash -e

Hmmm... It looks like I was using REL1_43. I see that 2.1.2 includes a fix for this. Thank you for the pointer!

This needs to be updated to deal with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CommentStreams/+/1105912

The patches here are out of date and I don't have a current need for this functionality.

Or, if you want to fall back, you could just change getMigratedIdByUserName to

private function getMigratedIdByUserName( ?string $username ): ?string {

instead of

private function getMigratedIdByUserName( string $username ): ?string {

Nevermind. I missed the next paragraph:

Isn't that this ingress rule?

When installing popups for 1.43, I ran into this problem. Restarting memcache didn't help. Or it didn't help till I set $wgExtractsRemoveClasses = ''; (null did not work).

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