In Progress: 3.4.11 was release on 2023-01-04, but hasn't been populated e.g. in the updater as of yet due some emerging issues.

I'm also busy and still setting up my dev env again, but that's my current status:

@@ -152,13 +152,15 @@ bool EditQuery::IsProcessed()
                 {
                     reason = _l("editquery-error-badtoken");
                     hec = HUGGLE_ETOKEN;
                     // we log off the site
                     this->Suspend();
-                    Configuration::Logout(this->Page->GetSite());
+                    //Configuration::Logout(this->Page->GetSite());
                     Syslog::HuggleLogs->ErrorLog(_l("editquery-invalid-token", this->Page->PageName));
                     this->qEdit.Delete();
+                    WikiUtil::RetrieveTokens(this->Page->GetSite());
+                    // error handling in case of failure is bad
                     return false;
                 } else
                 {
                     // We don't want to process failure in case the query was suspended
                     this->Result = new QueryResult(true);

Tried to reproduce it yesterday. Almost every time directly after login (updating huggle userlist) or logout (updating preferences). No really an idea why esp. directly after login the token is bad, looked at request log is the correct one fetched seconds before. And then suddently after trying to debug (as always :D ) or random after dozens of tries it works.

Since I am not active since a long time ago but this is still assigned to me I reassign it to Daimona, who is more active and has taken over the original patch.
Hope you finish it, @Daimona :)

For all viewers of this task comming from the announcement of MediaWiki Security release of 1.27.5 / 1.29.3 / 1.30.1 / 1.31.1 (Thu, 20 Sep 2018)

similar to T99793. where I currently can't reproduce that bug, but instead got this output behavior.

A quick test by repeating the request suggests that deployment-mediawiki01.deployment-prep.eqiad.wmflabs delivers for Special:Radom a blank page and deployment-mediawiki02.deployment-prep.eqiad.wmflabs correctly redirects.

If he tries to login in repeatedly in a short period of time, then even if the password is correct the api can return "throttled".
By default this is 5 logins within 300 seconds (5 minutes). (from https://www.mediawiki.org/wiki/API:Login#Throttling ).

Wasn't https forced already long before "28/29 Jan 2016"? Nevermind, there are locations in the vb-sourcecode where http is hardcoded. Also even if there were https, afaik there would be per default no cert validation.
This must be fixed in the old visual basic code. but the devs/Petr don't support HG2 any more.

@Niedzielski could you clarify if you mean the test in the app should be fixed?
Or can I assume that you are wondering why the edit goes through? This is as intended (see before) and the text in the warning message. ( "Prevent the user from performing the action in question" unchecked, "Trigger these actions after giving the user a warning" checked in the filter). Please close as invalid if resolved for you.

This isn't a issue of AbuseFilter, is it? The filter is only set to warn, not prevent any edit. So after the warning, if you resubmit it (or something for the same pagename) in the same php session again, it will go through. Doing as intended from AbuseFilter side.

This is a problem with a local gadget https://www.wikidata.org/wiki/MediaWiki:Gadget-PopupsFix.js, not with popups itself.
Please raise this issue on Wikidata.org village pump or gadget talkpage.

PS: A thing where I'm not sure about if this is the right thing is the argument supplied to the matcher-function. Currently it is the href-part of a link, e.g. "/wiki/Mainpage".
But the gadget works/inspects on the title-attribute of the link. Theoretically that could be modified to work on the url, but maybe there are edge cases, which require addition infos.

Ok, I try to explain what this patch aims at.
The patch in question solves the problem that previously it wasn't possible to add new renderer without overwriting popups javascript functions with own customized ones, which are prone to break if the original function changes. Also obviously this only works easy with one external party.
You can see that approach taken at the wikidata gadget by bene* at https://www.wikidata.org/wiki/MediaWiki:Gadget-PopupsFix.js who overwrites mw.popups.render.article.init.

In T102921#1720328, @Jdlrobson wrote:

I understand what you are trying to achieve and what the desired outcome is.
I just want to know whether https://gerrit.wikimedia.org/r/232236 helps you do that.
This requires you building something.

To be clear I expect the Wikidata team to make use of https://gerrit.wikimedia.org/r/232236 to make this happen. Once I see working code I'll merge https://gerrit.wikimedia.org/r/232236 otherwise it will not happen.

another option would be QApplication::beep()

Which filter triggers the block? Google translate mentions it could be filter 41?
I can't see it because its private, but from the list entry it tags atm. I suppose blocking has been disabled.

Note: <math> formulars on pages doesn't have to be rendered as a plain png, Extension:Math also supports MathML (browser rendering) with SVG/PNG-fallback or (removed) via MathJax (JS-library) and other modes by itself.
Extension:Math even has a user setting for that on wikimedia-wikis (I won't judge if that makes sense in context for hovercards).

In T99793#1654258, @Jdlrobson wrote:

As @Prtksxna points out this is an image. We could take the value of the text in the alt tag although this would have more serious impacts on other text extracts where the image is not a crucial part of the information. Could the article be rewritten to us one of the many maths extensions we have?

In T86523#1630176, @Aklapper wrote:

@Se4598: I cannot reproduce this anymore in Firefox 40. Can you?

ok, to summarise the features requested here are:

1. create edit queues based on selected tags (user config)
2. take specific tags into score calculation (per project/user config)
3. show edit tags under the edit summary at the top of each edit

See notes on changeset. (hm, somehow my annotations are off by one line)

@Tinaj1234 This patch doesn't cover all the strings that need to be translated in the extension, right?

In T99999#1308438, @Wtmitchell wrote:

I've never attached backup like screenshots to a Phabricator report and , looking around here as I''m entering this comment, it's not obvious to me how to attach screenshots to a report while entering a comment.

readding VisualEditor: was removed without explanation and the correlation seems obvious.

Quoting from another bug, maybe dupe of (T73947: Edits via API (e.g. through VisualEditor) cause AbuseFilter to work on pre-automerged edit):

This sounds like a simple JS-userscript to execute on a log page, and the API is there. Hasn't noone this idea yet or am I missing something? There is no need for a regex to clean up when it can be interpreted as json.

In T94368#1192301, @Luke081515 wrote:

OK, whats the next step now?

old bugs reintroduced. I'm not innocent on this one.
Are try-catch in JS code nice?

In T21565#1183187, @Dragons_flight wrote:

The underlying technical problem is that uploads proceed in two steps. First the file is uploaded to the server and then the text is processed and saved to the database. We have a hook into the upload process, but at that point in software the uploaded text is not yet available.

After poking around the code a bit, my instinct is that the best approach probably to add a new hook in UploadBase/performUpload prior to calling LocalFile->upload. Call it something like, UploadBeforeSaveText and send it the file info as well as the $comment, $page_text, and $user. And then move all AbuseFilter processing of uploads to that hook. The biggest potential pitfall is probably making sure the code aborts correctly and doesn't leave dangling stuff on the file system (the code is complicated enough that I'm not currently sure what cleaning might be necessary in response to a late abort).

The only other sensible alternative that I see would be to make page_text, etc. properties of UploadBase and associate it with the file much earlier in the upload process, before verifyUpload gets called. In some ways this might be preferable conceptually, as it would enforce a tighter integration of file description text and file content (and doesn't require a new hook), but doing that seems like it would require many more dependency changes since one would be modifying the parameters sent to performUpload among other things.

Does anyone else have suggestions about how to proceed here?

related: T93319: IE9 does not show reference backlinks around the same lines of CSS.

stuck open hovercard at https://en.wikipedia.org/wiki/Blackadder (1.25wmf21 (rMWdd2e66f6e20d)) @Prtksxna
FF's own Web Console shows (with grey cross):

"[Popups] Missing property "action"" load.php:39:408
"[Popups] Value null is the wrong type for property "duration" (integer expected)" load.php:39:408

Related to this task: Since the change I get emails from watched gerrit projects about submitted l10n changes. This wasn't before (except changes manually approved).
Is there a way to ignore L10n-bot again (particularly changes owned by l10n and submitted by jenkins)?

I assume there was a javascript error. I also had this infrequent lately but sadly forgot to save the message.

I will post a notice about this on dewiki's blacklist. It contains a lot of common german insults and also variants of local sysops usernames, which are affected by stalking trolls.
Also enwiki has similiar cases.
So before the switch gets flipped, Glaisher's questions (which would be mine too, from above link), should be answered.

So since this is going to happen, we need a process for migrating reasonable rules from local blacklists to this one (also abusefilters which prevents usernames needs to be disabled and imported here). [...] Glaisher (talk) 12:57, 11 March 2015 (UTC)

any update here? I suspect it is still not working.

The code (module "ext.betaFeatures.popup") is there, but it isn't loaded for me for an unknown reason. Option "betafeatures-popup-disable" is unset for me.

@yuvipanda: I don't know which infos are all on stat*, but relative easy queries can already be made together with Extension:AccountAudit like

SELECT up_property, up_value, COUNT(*) AS count FROM user_properties INNER JOIN accountaudit_login ON aa_user = up_user WHERE up_property LIKE "%gadget%" AND aa_lastlogin > '201404' GROUP BY up_property, up_value ORDER BY count;

(the query run in August 2014 and needed 1 min 32 sec for dewiki)

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.