In T221627#5131273, @Margott wrote:

Yes, thats right. Thank you :)

A quick look... sqwiki and sqwikinews have a timezone set of Europe/Berlin. Nothing for sqwikiquote. So it's in UTC...

In T221627#5131225, @Margott wrote:

I see, then lets make it to show the right time when we are logged in. Would be nice to show the right time because of the banners and quote of the day. Its around one hour early as far as I can understand, which is not a big deal. If its too much work from the team that has to work on this, then we can skip it for now.

In T221627#5130970, @Margott wrote:

Yes, the current time now. Im updating the description.

What time is it supposed to show? The current time now?

Fixing part of this would also fix T221616: Error running update.php on shared db with PostgreSQL (at least where INSERT IGNORE is concerned)

As far as I'm concerned, this is good to go. A little bit of cleaning up, but nothing security specifically

Needs extra quoting...

In T189434#5128665, @TerraCodes wrote:

@Reedy that might be a good idea, since I'm now getting email that's being spoofed (eg, it says it's to security@tools.wmflabs.org but I somehow got the email).

And for amusement, the boardvote tables on enwikibooks use 100MB+

The tables are fairly big in small wikis (a wiki that was made last week and has 7k articles, has 57k rows in querycache making it 8th biggest table there while it's 70th largest table in enwiki), taking lots of storage for s3

I’d imagine a large chunk of the data, at least on older wikis probably wouldn’t be migrated

Oh and T174513: Maintenance script to cleanup querycache

See also T146571: Add a primary key to querycache for some of the duplicates and crap that’s been left behind...

In T221461#5125577, @hashar wrote:

https://integration.wikimedia.org/ci/job/mediawiki-quibble-composer-mysql-php70-docker/17434/ I have marked the build to be kept forever.

Confirmed fixed on Special:CheckUser (get users) too

Hmm. So it seems there's no train next week... I think I'll cherry pick @Urbanecm's patch into .1, but leave it out of master, in the hope that @Catrope and/or @Jdlrobson (or anyone else on a responsible team) can deal with it in master before 1.34.0-wmf.3 is branched... There's about a week of working time after easter, but before the branch. Should be sufficient

In T221456#5125392, @Der_Keks wrote:

I also tried to telephone to WMDE but they aren't at work so maybe smb. knows the phone number of their IT.

Of course, this also affects MW-1.33-release and we should be careful backports/fixes end up there too

In T220767#5125236, @Urbanecm wrote:

In T220767#5125234, @gerritbot wrote:

Change 505242 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/core@master] Set $useParentheses to true in userToolLinksRedContribs

https://gerrit.wikimedia.org/r/505242

@Reedy This might be an easier solution. I'm not sure if this isn't breaking something else, but according to my local testing, it isn't causing anything like double parentheses or similar.

In T220767#5125236, @Urbanecm wrote:

In T220767#5125234, @gerritbot wrote:

Change 505242 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/core@master] Set $useParentheses to true in userToolLinksRedContribs

https://gerrit.wikimedia.org/r/505242

@Reedy This might be an easier solution. I'm not sure if this isn't breaking something else, but according to my local testing, it isn't causing anything like double parentheses or similar.

In T219348#5080065, @gerritbot wrote:

Change 499364 merged by jenkins-bot:
[mediawiki/core@master] RecentChanges updated to use pseudo elements for presentation

https://gerrit.wikimedia.org/r/499364

In T220767#5121773, @matej_suchanek wrote:

I maybe did in T221253.

So I guess the load order is wrong somewhere in operatons/mediawiki-config

In T220767#5120700, @Xaosflux wrote:

Just wondering - is anyone working on this? Has anyone been able to validate what the breaking change was?

In T161248#5117575, @lucamauri wrote:

Dear @Reedy I see this task is currently unassigned and open for quite some time now.
As I already worked a bit to improve documentation, does it make sense that I claim it and and work with the userbase to update the instructions to a satisfactory level for admin and users as well?

I am sorry I am fairly new to the whole system, so I am not 100% sure if I am allowed to do this and what standards should I met.
I am willing to help nonetheless as I am working to make this extension work anyway for my own project, so I would put my experience at other users' service, if this can help.

In T25227#5117999, @Ladsgroup wrote:

In T25227#5116776, @sbassett wrote:

"Rebased" @Bawolff's 3+ year-old patch (T25227#2013640) on master, tested locally. Talked about this with the Security-Team today - fine with just pushing it publicly in gerrit. If there are no objections, I'll create a patch set from the attached: F28682008.

Awesome! thanks. One thing in the patch, it uses the old array() system. That's my only note. Once it's in gerrit, add me as reviewer so I help (btw. Can we write tests for this?)

In T216692#5092682, @Lydia_Pintscher wrote:

From my side I'd like the review to happen asap because otherwise it's getting into my vacation and I can't help deal with the feedback and requests from the editors. For that to work out we'd need to have everything ready for deployment on 24th of April.

In T220623#5113388, @Krinkle wrote:

Ha, so it's actually an empty string by default. Interesting. Yeah, so Incubator just needs a patch then to ignore that and simply assign plainly like other hook handlers do…

I note the stack trace is out of date....

In T220623#5113238, @Krinkle wrote:

It looks like the problem is a faulty hook parameter, which might actually originate from other extensions in production that hook into the same event.

https://codesearch.wmflabs.org/deployed/?q=function.%2BetUserPermissionsErrors&i=nope&files=&repos=

Some set a string here (such as Flow). Which seems actually valid according to the docs.

https://www.mediawiki.org/wiki/Manual:Hooks/getUserPermissionsErrors

&$result: … $result can be returned as a single error message key (string), or an array of error message keys …

So, looks like Incubator is in error after all.

EDIT: Except whenever it is set to a string, the hook should return false which would end the callback sequence. If Incubator is getting a string, that must mean a previous caller declared a permission error without returning false?

This should be updated on translatewiki, it will then be exported and go live within a week or so

Placeholder mainpage created

I can do, yeah. I'm curious how it doesn't even have a main page (do we just blame addWiki probably being broken?)

This is a dupe

More fails

In T202470#4993066, @Krinkle wrote:

Re-opening for now as reminder to release/deploy. (Sorry)

In T220779#5109117, @Isarra wrote:

This came up in MediaWikiAuth because there we have a permission that all it does is return early and not keep checking other things if they have it; there is no special action associated with it to begin with. While we may add an actual action later in this particular case, for quite a few other extensions that's definitely not going to happen: for instance HAWelcome runs a job behind the scenes and just skips it with its right...

In T220779#5108274, @Umherirrender wrote:

Structure tests should be enable after fixing the extensions and not produce something like "Unbreak now"