I don't know. I haven't tested it. But I doubt it.

The important change, though, is probably this one in WikiEditor: d23d096

MediaWiki 1.34+ ... 5e55aeed71 is what my branch says

In T246199#5919452, @Tinganwiki wrote:

my solution works for me, but didn't consider downward compatibility issue, https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageForms/+/575006/1/libs/PF_wikieditor.js

In T226857#6127853, @Reedy wrote:

The bug seems very much with the library and how it's being implemented/installed. And seems to demonstrate why T249573: Remove support for extensions requiring a MediaWiki version via Composer and T250406: RFC: Hybrid extension management need to happen

PerconaDB should override locks. Granted, I haven't tried installing into an empty Percona DB using this extension.

Does this need to be updated with this comment from @Tgr?

Just ran into this. Should we not be running this despite what update.php says?

I just ran into this problem with a client today. I'm wondering if @Osnard has a better solution, but I just commented out the bit in Auth_remoteuser that munges the cookie name.

Was just about to file a bug for this!

Adding @daniel since I hear he knows a thing or two about DI.

In T250406#6063772, @Reedy wrote:

Though, this kinda irks me to some extent. Having installation method A for some subset of extensions, installation method B for others, and C where they support both A and B... Well, frankly, is just a mess and leads to much more confusion :)

Note that @Osnard was already working on this RFC before we saw T249573. When we saw that, we knew we had to put our not-quite-finished RFC up for some initial review. I do not have time right now to flesh out the details and @Osnard is unavailable until next Monday at the earliest.

In T250406#6063672, @Reedy wrote:

Not in any sort of official supported/approved way - see the docs. The RFC was declined, and then later a patch created and merged without any associated task, or any real discussion.

@Krinkle, I'm confused by your example. Could you rephrase it?

The above fixes the problem for PluggableAuth, but maybe this should be re-targeted against core and a fix made on Title::getFullURL().

I'm not dealing with this right now, so I'll close it. If it annoys me in the future, I have something to refer to.

I think it is fixed. At least, it seems to be working.

If I need this later, I'll revisit.

I think I'm done with this for now.

Thanks for the reminder @Aklapper

@Hexmode @MarkAHershberger heads up - one of the uses is in the `hexmode / mediawiki-PeriodicRelatedChanges` extension on github

done

In T243371#5822060, @DannyS712 wrote:

@Hexmode can you take a look at https://github.com/hexmode/mediawiki-UserSnoop/pull/2 please?

Also, note that if you were seeing timeouts on wikiapiary, I think I've got it fixed thanks to this SF answer.

Wow! I'm impressed that you reported the bug so quickly.

Yaron, in response to the latest patchset, you inadvertently +2'd. When you re-applied your -1, you also added:

I think my previous comments still apply to this patch...

I want to make sure I'm addressing the right thing. In one comment, you said:

It seems strange to turn just one form input class into a "true class", while keeping the others as they were - that might cause more confusion than it's worth. It's also strange to do this within the context of a bug fix. What about just fixing the bug in this patch?

I responded with my reasoning, which can be summarized as "I had to refactor the code to understand where the bug was. Once I was doing that, it made sense to use a 'real' class."

In T238806#5680572, @Yaron_Koren wrote:

I never thought about that case... maybe it would be better to show an error message, like "No forms have been defined on this wiki", so it's clearer what's going on?

I was talking about this:

I can see where you're coming from, but, instead of defending against a mysterious, unknown browser that might act strangely, just display a list of buttons that the user has to select and then, if a problem is reported, fix it. We do need to announce this change, though: "None will no longer be displayed when it is not a valid choice." I wouldn't say it breaks backward compatibility, but people need to know.

In T137701#5683443, @Yaron_Koren wrote:

I'm confused about the first thing you wrote - "Even if we posit that you are correct". Correct that the default value should not be used when editing existing pages? Because that seems to be the entire underlying issue.

In T137701#5681551, @Yaron_Koren wrote:

In any case, I still think default values should not kick in when editing an existing page

In T137701#5680598, @Yaron_Koren wrote:

• The user lacks permission to edit that input

This is not the case. There is no restriction in the import.

This import includes a demonstration. There are three pages in this demo: Test, Form:Test and Template:Test.

Who manages github mirroring? It looks like there is no mirror of the current LDAPGroups.

Ok, I've put all the tests into a single, easy to verify commit: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageForms/+/550990/

What's the problem with JS validation? That's how mandatory text and textarea inputs are handled...

So, for applying my rewrite change, I see that I need to update my tests. Let me get that rewrite backported first.

Changes to merge: the ones tagged radiobutton-tests

This does cause confusion for admins, but I think it's the right
approach, because it avoids accidental creation of data. What do you
think?

Is "None" an ok value for a _boo field?

So that future me (when I get my fonts fixed) or someone else looking at this doesn't get too confused, here is the tofu I see for the relevent parts of this comment:

This happens because User::getCanonicalName() uses MediaWikiServices::getInstance()->getContentLanguage() to get a LanguageEn object and Language::uc() recognises a multibyte string so passes it to Language::mbUpperChar() which paasses it to mb_strtoupper().

Found the culprit!

The first comment's [[ https://phabricator.wikimedia.org/T238149#5658509 | var_dump ]] was done just before this line. At that point, both $this->mName and $q['actor_name'] contained the malformed username: "Გამაგ"

sorry about that, I have a better version here: გამაგ from this revision.