I don't know. I haven't tested it. But I doubt it.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 22 2020
May 20 2020
The important change, though, is probably this one in WikiEditor: d23d096
MediaWiki 1.34+ ... 5e55aeed71 is what my branch says
May 19 2020
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
May 12 2020
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
May 9 2020
PerconaDB should override locks. Granted, I haven't tried installing into an empty Percona DB using this extension.
May 4 2020
Does this need to be updated with this comment from @Tgr?
Apr 30 2020
Just ran into this. Should we not be running this despite what update.php says?
Apr 27 2020
Apr 23 2020
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.
Apr 21 2020
Apr 20 2020
Was just about to file a bug for this!
Apr 17 2020
Adding @daniel since I hear he knows a thing or two about DI.
Apr 16 2020
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 :)
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?
Mar 25 2020
The above fixes the problem for PluggableAuth, but maybe this should be re-targeted against core and a fix made on Title::getFullURL().
Mar 20 2020
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.
Mar 18 2020
Mar 16 2020
I think it is fixed. At least, it seems to be working.
Feb 28 2020
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
Jan 28 2020
done
Jan 23 2020
In T243371#5822060, @DannyS712 wrote:@Hexmode can you take a look at https://github.com/hexmode/mediawiki-UserSnoop/pull/2 please?
Jan 14 2020
Jan 11 2020
Dec 24 2019
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.
Nov 27 2019
Nov 25 2019
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."
Nov 24 2019
Nov 23 2019
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?
Nov 22 2019
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
Nov 21 2019
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.
Nov 20 2019
Who manages github mirroring? It looks like there is no mirror of the current LDAPGroups.
Nov 16 2019
Ok, I've put all the tests into a single, easy to verify commit: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/PageForms/+/550990/
Nov 15 2019
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?
Nov 13 2019
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!
Nov 12 2019
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.