In T91317#1080115, @Anomie wrote:

The "push through" would probably apply to all RedirectSpecialPage subclasses when redirects=true. The annoying part being having to go through the list of special pages and find which ones are.

oh the lovely times from bugzilla's gerritbot are back: one email for the comment, another one for the tag...

In T90887#1072134, @Tgr wrote:

It would be easy to set up an abusefilter rule to catch edits which add such characters so errors of this kind don't go unnoticed.

AbuseFilter ignores wikitext during upload: T89252

I don't like the idea of centralizing newsletter definition. I'm also for centralizing specific newsletters but let communities handle their own (custom to the wiki) newsletters themself, like it's possible to use MassMessage on any wiki, managed by local admins/senders, but also send messages from Meta to all wikis.
to clarify: My main point here is not the central place, but who will have which rights and how that integrates with local community wishes.

coincidentally https://www.mediawiki.org/wiki/Extension:Thanks#API_Documentation mentions "huggle" as example for the source parameter ;)

https://en.wikipedia.org/w/api.php?action=help&modules=thank

In T90611#1069169, @MZMcBride wrote:

Perhaps https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/specials/SpecialUserProfile.php#L206-215, but I'm quite tired.

Due a missing closing div-tag, the header and sidebar (div#mw-navigation) are now within div#content
dewiki has in its MediaWiki:Vector.css, which causes the wrong alignment as seen in the screenshot above.

for the others as info: as far as I have followed this we have now (open)

• T90753: Get rid of Special:UserProfile
• T90801: Remove last edited pageimage from Special:Userprofile

if you have other constructive improvement requests/bug reports, please open a new task.

In T41104#1065379, @Nemo_bis wrote:

Please see a question at https://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Translationnotifications-talkpage-body/en

A simple hotfix I have written got deployed and applied to 1.25wmf18 before it got out to group1 and all wikis to prevent rendering the complete feature unuseable (not showing up anywhere).
But due the simplicity of the fix, there's now the regression that popups doesn't show up for anchored links. This regression will hit all wikipedias tomorrow with group2 deployment.

I have created the following patch https://gerrit.wikimedia.org/r/192465 as alternative to revert, but must be reviewed if this really fixes that problem.

related/reminder: se.wikimedia.org was also interested in getting this deployed as default (regardless of beta state), see T68374

related bug: garbage is displayed in the hovercards for some wikidata links instead of nothing: T78825: Popup/Hover on Wikidata Q pages shows plain /*<![CDATA[*/ only

example item: links to https://www.wikidata.org/wiki/Q5

duplicate of T89973?

There are currently to failing jobs in the list, and the commits linked here finished importing. So closing this as fixed.

Another idea would be to setup a simple redirect/landing page pointing to https://tools.wmflabs.org/nagf/ and/or https://tools.wmflabs.org/nagf/

As the task description suggest I am also for a CSS-class added to links, so each user or wiki can create their own styling if they want.
It doesn't have to have a associated style by default as the Extension can be used by various wikis with each a different environment.

In T72576#1048671, @Ricordisamoa wrote:

Anyway, if they point to local pages that neither exist locally nor are mirrored from an external site, they should be red.

created T89944.

In T88166#1043101, @Prtksxna wrote:

thanks for pointing out this problem. I think ResourceLoader takes up all localStorage.

Yes, even if now ResourceLoader cleans up old cached js files after himself. My and many other local storages of users I know are still full from before this was fixed. Don't really know if it was indeed fixed at some point :-)

Further research for whoever will fix this w/o T 89302 hook:
there should/will be the hook "PageContentSave" called when the description page is created, but it hasn't a nice error handling;
via UploadBase::performUpload -> LocalFile??::upload -> WikiPage:doEditContent.
AbuseFilter currently doesn't hook in there.

ok @Fae, I think I understand and you mean T89252.

looks like this is a valid bug, based on my assumption that for new upload only onUploadVerifyFile is called, but not filterEdit.

In T21565#1031373, @Fae wrote:

This is a great loophole for copyright abuse and uploading professional photographs to Commons without permission. Once an OTRS ticket gets "recycled", an image would be highly unlikely to get noticed as a copyright problem or that the ticket was not added by anyone with OTRS access.

If this cannot be fixed, we really should consider if an efficient bot can be designed to do the same job.

In T54453#1028658, @Jalexander wrote:

Aye, user talkpage notifications are unhelpful to the user who can't log in to their account and on private wikis (like this is meant for) this are a security issue too since the notification can have snippets of what is posted. [obviously there is not generally a reason to post private information to a blocked wikis talk page but I can imagine a situation where someone hadn't noticed they were gone already or something like that]

In T54453#1027792, @Trijnstel wrote:

What if this task is being done and accounts need to be unblocked? Will the email then automatically be confirmed again? (ie. think about returning OTRS agents, CheckUsers and/or stewards)

this is annoying, and together with T88554 it is hard to get a verified+2 in gerrit even when rechecking.
Apparently for the last failing builds on mediawiki-extensions-zend it was always the flow repo (Flow/.git/config.lock).

Adding CheckUser.
Patches currently existing are gerrit:92051 in AbuseFilter and corresponding gerrit:92050 in CheckUser extension (Though they also currently reuse the same web request (same UA etc.).

CompactPersonalBar was disabled in production as a beta feature, but can still be loaded via

mw.loader.load("skins.vector.compactPersonalBar");

Based on the negative feedback on https://www.mediawiki.org/wiki/Talk:Compact_Personal_Bar about the deactivation and the above posted workaround there, I think VectorBeta should be still loaded for the users who want CPB regardless of the "critical" bugs and fully aware of this.
I see no reason to deny that possibility.

@MarkAHershberger is this now with the merged change fixed? If so, please resolve the bug.

new one for documentation: Task 7250335 with 233 failures going up, importing rECNO748476b23bed (extension-CentralNotice)

now (up to build 2230) four ones: 2217, 2224, 2227 and 2230, where the two latter also has a mw-error.log (something about implicit commit transaction), all still on integration-slave1009

that a already revdeleted username appears sounds (relatively easy) fixable.

In T88005#1002067, @chasemp wrote:

There is an upstream for this somewhere I have seen where they said I think "this seems actually not simple to fix". So we should track that down.

maybe then add "run time", too? Anyway, they are a indicator, but also very choppy (see T53294)

From reading the Status.php (mw-core) code the status-object will prepend under certain circumstances to the whole single message a "* ", expecially if there are more than one message (multiple matching filters), to format all errors as a list.

CPB removed globally with https://gerrit.wikimedia.org/r/185116 and https://gerrit.wikimedia.org/r/186549 (may be still on beta-labs)

In T87059#983784, @Petrb wrote:

It was useful more or less just for statistical purposes, but you can as well select all pages User:*/huggle3.css from SQL to list all users who did ever use huggle in past

I had used it for keeping track of new users starting to use huggle to monitor and help them. You could find that out by using SQL but that's not option for normal users/admins.
So updating that page has still an use case (that is more practical be fixed by adding users themself than e.g. writing a bot querying the db).

closing as T86680 got fixed. Change has been deployed. I haven't seen that issue afterwards for me.

After no obvious is striking in the code, I could imagine that has to do with the user id a user has.