Sep 13 2020
Sep 7 2020
7zip 20.00 alpha (x64)
Win10 LTSC 2019
Current 7zip version unpacks this archives correctly.
Aug 31 2020
Aug 14 2020
@eprodromou What I should do to "confirm all the credentials and other issues"? The problem persists. I removed and re-added "High-volume editing" grant to this bot password, it doesn't help me.
Aug 13 2020
Tested from both MBH and MBHbot accounts, logged into it from AWB.
OK, I will not argue, for deletion it was right in 2012, when I was closer.
Jul 22 2020
@eprodromou I can post here or mail you my bot password, so you can confirm this issue.
Jul 15 2020
Jul 4 2020
Jun 22 2020
Search with regexes Tooltips.*\|default\| and Reference.*\|default\| gave me exactly the same result.
I have written a simple bot that searches regex
on every url like
Jun 11 2020
I re-runned this query in its old form. Successfully executed in 278 sec.
@Marostegui But query https://quarry.wmflabs.org/query/12570 now contains another text, that it was contain on March 18, date of creation of this ticket. How you know what text was contain this query on March 18? Quarry doesn't store history of text changes in one query, as far as I know.
@Marostegui it isn't the original query. Recently I optimized it by replacing views "revision" => "revision_userindex" and "actor" => "actor_revision". Before that it was killed after 30 minutes. To test the original query you can roll back these replacements.
May 3 2020
Why you can't just move Quarry to another host?
May 2 2020
The problem persists. The same query https://quarry.wmflabs.org/query/12570 was killed after 30 min again.
I agree with QEDK: this change should get consensus on big wikis or option in preferences to get this changes back.
Apr 13 2020
There is interwiki prefix [[toollabs:...]] now, that still leads to old url. Will it be updated or will be introduced a new prefix?
Apr 9 2020
B. It persists without deleting/restoring. See https://ru.wikipedia.org/w/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%96%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D1%8B&page=%D0%AD%D1%81%D0%BF%D0%B5%D1%80%D1%81%D0%B5%D0%BD%2C+%D0%9B%D0%B5%D0%BD%D0%B5 and https://ru.wikipedia.org/w/index.php?title=%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%96%D1%83%D1%80%D0%BD%D0%B0%D0%BB%D1%8B&page=%D0%9B%D0%B8%D0%B3%D0%B0+1+%D0%A4%D1%83%D1%82%D0%B1%D0%BE%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9+%D0%BB%D0%B8%D0%B3%D0%B8+%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B8+2009%2F2010
Apr 4 2020
New case: https://ru.wikipedia.org/w/index.php?title=%D0%AD%D1%81%D0%BF%D0%B5%D1%80%D1%81%D0%B5%D0%BD,_%D0%9B%D0%B5%D0%BD%D0%B5&action=history
It is caused by article renaming and can be fixed by deletion and restoration of such page.
Mar 20 2020
Mar 18 2020
May it be the same as T246970?
Feb 9 2020
Looks like it was fixed many weeks ago.
Feb 5 2020
If "Problem likely started when FR config was moved to an extension function in summer 2019", why not just roll back this change?
Jan 23 2020
I could replace this character on my own. But the problem isn't this character, but that some software replaces Unicode character "nbsp" with HTML entity and doesn't show this entity as "nbsp", but shows it as a raw text.
Jan 22 2020
Looks like restarting webservice fixed this issue, just with some delay.
Jan 3 2020
But... if zero views, it's stated explicitly
Jan 2 2020
"Fatal error encountered during command execution" was unclear message about timeout error. When I increased allowable working time for request, problem was solved.
Jan 1 2020
Dec 17 2019
@awight If you're a developer of Reference Previews, can you explain, why, in general, Reference Previews was created, if for many years exist fully functional, completed and useful gadget Reference Tooltips? Is it needed to reinvent the wheel?
Dec 15 2019
Will it be fixed for renamings before patch? Still not fixed for me, see T193504
Looks like fixed many months ago.
Dec 11 2019
I think, it should. When I enter some text into text field and press Enter, the request must be executed with exactly entered text.
Dec 10 2019
The fact that now user's js/css pages can be edited by this user and (interface) admins means that there are one more protection level, "me and admins". It's useful in some cases, for example, configuraton files of some of my bots and request pages for bot-executed requests for another my bots are .css files in my subspace, so, they can be edited by me and admins (request pages was created in 2016-2017, when any admin could edit this pages). It's useful opportunity, so, if we remove a right to edit this pages from even interface admins, it may be good if we explicitly establish a new protection level, "me and admins". Or change the behaviour of MediaWiki engine, so user can edit fully protected page if it is in this user's subspace.
Dec 1 2019
Nov 24 2019
@MBH: Could you please share specific examples which make the gadget on ruwiki better than the beta feature?
@Aklapper Several reasons pointed on https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/ReferencePreviews#We_already_have_Reference_Tooltips (thanks Jack for this link). But I filed this task primarily not because of "gadget is better than beta feature", but because of 1) ruwiki has enabled gadget for all users and everyone likes it, 2) so, beta feature is not needed, 3) new users get enabled both gadget and beta feature, but unregistered users has only gadget, so, if we turn off the gadget instead of beta feature, unregistered users will lose reference previews at all.
Nov 23 2019
Is https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%A2%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D0%B7%D0%B0%D0%BF%D1%80%D0%BE%D1%81%D1%8B#%D0%93%D0%B0%D0%B4%D0%B6%D0%B5%D1%82%D1%8B_%D0%BF%D0%BE%D0%BA%D0%B0%D0%B7%D0%B0_%D1%81%D0%BD%D0%BE%D1%81%D0%BE%D0%BA_%D0%BD%D0%B0%D0%BA%D0%BB%D0%B0%D0%B4%D1%8B%D0%B2%D0%B0%D1%8E%D1%82%D1%81%D1%8F_%D0%BE%D0%B4%D0%B8%D0%BD_%D0%BD%D0%B0_%D0%B4%D1%80%D1%83%D0%B3%D0%BE%D0%B9 enough?
Oct 31 2019
Oct 13 2019
I updated code (https://tools.wmflabs.org/mbh/patrol.txt, use Ctrl-F5). Now API answer is written to the console only if call was unsuccessful, error message contains page title and API answer. Of course, a message will be localized.
Code is dirty, but working.
@DannyS712 @Tgr @Zache I wrote a bot that reviews all edit sequences that was not reviewed due to this bug. I wrote it for ruwiki, but if you want, I can launch it for your wikis too, if your wikis grant "editor" flag to my bot.
Oct 4 2019
I already pinged an only active on Phab member of https://phabricator.wikimedia.org/tag/mediawiki-extensions-flaggedrevs/ , @TerraCodes
Oct 3 2019
@Marostegui and where is this report? Post a link, please.
Oct 2 2019
Of course, this bug should never happen for users with "reviewer" rights, 'cause it happens only for users with "autoeditor" right, not "editor" and not "reviewer".
To all discussion participants: don't listen Neolexx. This user can't understand Flagged Revs mechanics, makes false statements about it, confuses himself and others. Two years ago all ruwiki's technically competent users in the amount of more than five people were trying to explain him simple FR mechanics, but failed. Don't listen him and his false statements, for example about "engine allows to have articles which are not patrolled but having patrolled last edit" (this statement is clearly wrong).
Sep 29 2019
@TerraCodes can you do something? Flagged revs based reviewing is COMPLETELY BROKEN for a week in any wiki where it's installed, including big wikis such as ruwiki and enwiki.
Sep 24 2019
Sep 19 2019
When you use Windows 8 and newer, it's better if AWB require .NET 4.5 instead of 3.5, because 4.5 comes out of the box, while 3.5 should be installed separately. It's great that new AWB version no longer requires .NET 3.5 installation.
Sep 18 2019
I'm not sure if I need to backport this (and various other changes) to 5.10.x.x too... Are people still using 5.10? or is everyone on 6.0?
@Reedy is 6.0 is official, legitimate version of AWB? The fact is that AWB updater on version 126.96.36.199 "updates" AWB to 5.10.1 version.
Sep 17 2019
Sep 9 2019
Sep 1 2019
@D3r1ck01 It "is still very valid and is highly used" not in big wikis like enwiki, commons, ruwiki, where it recognized as unusable disaster, which makes using history, reverting vandals and complex multilevel discussions impossible. As far as I know, WMF abandoned an idea to force every project use Flow, its new idea to simplify discussions (presented on last Wikimania) is JS script over normal talk pages. I'm interested, can this NS and extension be completely removed from ruwiki (local consensus exists)?
@D3r1ck01 It's off-topic, but maybe you know answer. Will "Topic" namespace from cancelled Flow extension be deleted in projects, that were use it, too?
I checked last release versions of Chrome, Firefox, Opera, IE11, Edge and Android 6 default browser; all of it saves changes in text field in edit mode. Other user confirms for me, that desktop Safari and iOS browser do the same.
@D3r1ck01 Will Educational Program namespaces be deleted in projects where EP was installed? For example, ruwiki, EP namespaces still exist (but its localization already gone).
Aug 27 2019
Looks like it is fixed now (maybe because of updating mono version on Toolforge). Now this bot works very fast.
Aug 26 2019
I'll test this in the coming days. Except Safari and iOS broswer, 'cause I don't have Apple devices.
Aug 25 2019
I know, but the rest that I wrote remains valid. Why is this annoying warning needed, if any browser, used in 2019, saves text fields content?
Aug 24 2019
Jul 26 2019
Looks like fixed now.
Jul 10 2019
Yes, it's because of "table" tags. I couldn't post this T227681 task with error "Call to undefined method PhutilDOMNode::newRawString()", but when I deleted "table" tags from task's text, task was posted successfuly.
Jul 3 2019
User from New-York reports that he see vandalised version too.
Jul 2 2019
Russia (Siberia): outdated version both registered and unregistered view.
Jul 1 2019
- https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%A4%D0%BE%D1%80%D1%83%D0%BC/%D0%A2%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9#%D0%92%D0%B0%D0%BD%D0%B4%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D0%B8%D1%8F_%D0%B2_%D0%BF%D1%80%D0%B5%D0%B4%D0%BF%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80%D0%B5 (screenshot saved from here)
Jun 30 2019
Can you tell me a certain date? Your links contains many data, but no information about when this fix will be released.
When fix will be released? Still broken now.
Jun 27 2019
Now my userpage link overlaps by notifications link.
Jun 23 2019
Jun 19 2019
Global user contribs still broken because of this refactoring, see T224930
Jun 16 2019
I has this problem too. Solved by restarting webservice.
Jun 13 2019
@aborrero , can you look at this task?
Jun 8 2019
May 31 2019
I changed a code of one of my bots to using actor_name instead of log/rev_user_text and bot became work several times longer (more than a hour vs. 5-10 min). This bot makes two requests to DB replicas on Toolforge: