In T302812#8285027, Umherirrender wrote:

This is from SpecialSearch, see T315737#8187139 for a possible solution

I don't really have the time to work on this. Feel free to take over for now, otherwise I might have more availability at some undefined later point in time.

Patch:

Looks like the NPM dependencies on REL1_36 have not been updated properly. @babel/preset-env should be 7.9.0 or higher, but is currently version 7.8.7

InnoDB full-text search does not support the use of a leading plus sign with wildcard ('+*'), a plus and minus sign combination ('+-'), or leading a plus and minus sign combination ('+-apple'). These invalid queries return a syntax error.

https://dev.mysql.com/doc/refman/8.0/en/fulltext-boolean.html

In T279090#6970957, @Ladsgroup wrote:

Regarding the second part: You're checking against "replacetext" right. I might be misunderstanding how rights work in mediawiki but the right should stay around even when the user is blocked, right? Let's draw a comparison between this right and "autopatrolled" right, if a user is autopatrolled and is blocked, the right doesn't go away. Shouldn't the check also be "edit"?

I don't have time to submit a patch, but it seems like an easy fix. Line 430 of DPLforum_body.php should be changed to:

$first_user = User::newFromActorId( $row->first_actor )->getName();

And it looks like replace text restarted the failed moves an hour later, which is also pretty problematic, since I thought it was safe to disable the abuse filter that was preventing the page moves.

I've done some investigating, and have been able to confirm that this is caused by the Video extension. Not sure what the actual cause is yet, but we've confirmed that disabling the extension resolves the issue locally. Though, that's not a solution for wikis that rely on the extension.

In T273251#6836686, @Masson_Thief wrote:

Excuse me, any progress on this? Also, is there a way to just remove votes entirely?

From a quick look into this, it seems that CommentVoteAPI.php calls Comment::getScoreHTML. However, since CommentsPage::setVoting is never called by the API (and can't since the API doesn't have access to the parser, to my knowledge), the settings for allowPlus and allowMinus are never set. One way to handle this might be to change getScoreHTML (and then, by extension, the CommentVoteAPI) to not set the vote links. Otherwise, one would probably need to make the parser for the comments tag available to the parser, which I doubt is possible, or reasonable.

In T257701#6739699, @Tchanders wrote:

Thanks for looking into this @TheVoidwalker. Haven't given this much thought yet, but would it help to add the global block-specific message into the block reason instead?

Hmm, I've been looking into this, and I have a fairly functional method by which to do this (need to make some updates still to the GlobalBlock class as it does not define all the block options it needs to), however I've encountered a new problem. As of T227174, it is no longer possible for block objects to define their own error message key and parameters, as both of these are effectively hard-coded into BlockErrorFormatter for the existing block classes in MediaWiki core. This means that the error message you see when blocked by a global block (if this change is implemented) will no longer make as much sense.

This would probably be made moot by T257701

Possibly related, but I had forgotten about it: T226342. It looks like a few things have changed in core since I made that recommendation, which might change how best to fix this. I had originally opened that ticket as a result of this same issue, but didn't really make that clear. My bad!

Our urls.py has a hack to prevent ZppixBot from fetching URLs posted by certain bots to reduce spam (MirahezeLogBot, travis-ci, and wikibugs). If we migrate to upstream url.py, we will have to make this hack again. Alternately, the bot could just entirely ignore those other bots.

I managed to make an edit, which seems to have fixed it for now. I'll look into upgrading MW shortly.

Per discussion with @RhinosF1, it appears to be functional, and the code has been cleaned up rather significantly.

In T231763#5596140, @matmarex wrote:

I signed up and tested on your wiki (test.miraheze.org redirects to https://publictestwiki.com/ for me).

When you're logged in, the state of these popups is stored in user preferences. We use the action=options API to save them. However, on your wiki saving them fails, returning an error like this:

{"warnings":{"options":{"warnings":"Validation error for \"visualeditor-hideusered\": not a valid preference."}},"options":"success"}

You can see this in browser developer tools in the "Network" tab after you close the popup.

Few more tweaks to go, but the functionality should all be there.

The bot config already has a url blacklist built in (bot.config.url.exclude and bot.memory['url_exclude']). I'd say all we need to do is allow for it to be modified dynamically (via command).

As it turns out, it's an unrelated issue where multiple blocks exist for the same IP (somehow).

Upon further investigation, it does not seem possible to replicate this issue. Instead something else may be at play, I'll see if I can nail that down, and update this task with the details.

In T219050#5444693, @kostajh wrote:

@TheVoidwalker could you share the URL where you observed this please?

In T226343#5277068, @DannyS712 wrote:

Users can't be globally blocked - only IPs can. See https://meta.wikimedia.org/wiki/Global_blocks

The issue appears to be caused by afl_user being set to 0 on user creation (likely because the user account does not exist). But, when searching though the abuse logs, a condition is added to search by afl_user, which, as long as the account now exists, cannot be 0. Is this necessary at all, given that afl_user_text should be unique? Maybe, given that a disallowed user creation could add entries from different people.

This appears to be the case for any filter that is activated on account creation. For whatever reason, the log is not actually attached to the account (meaning that you can't search for the account name to find the hit).

Handled with downstream config fixes. Not to mention, if there is another issue, it appears to be next to impossible to debug in the current situation (too intermittent/unreliable).

Also, I just want to remark that I am concerned that my own debugging is not for the same issue as the original that we encountered, as that one could be fixed or bypassed by the user. So far, the account I triggered this on has remained inaccessible for over 24h.

I've done quite a bit of debugging downstream, and found that the issue may be T169261, but that wouldn't make sense, because we are using a version of CentralAuth that includes the fix that resolved that task. Anyway, here's the debugging I got:

It does not appear to be up to date with the master branch. I will try updating.

We have a git repository here. I'm currently checking if the extension is up to date.

Well, I changed line 359 to public function performUpload( $comment, $pageText, $watch, $user, $tags = [] ) { and it seemed to work. Then I attempted to upload an avatar and received the following error:

Warning: getimagesize(): Filename cannot be empty in .../extensions/SocialProfile/UserProfile/SpecialUploadAvatar.php on line 364

Also, I suggested a script here, which replicates the functionality without using a confirmation button.

Check to make sure that pages are marked as visited, the change had made it so that the page marks stuff as visited without reloading (possibly).
No idea why they made it remove the button though.

In T150045#2877191, @Sn1per wrote:

Since the original form-submission-based reset didn't require a confirmation, how about removing the dialog confirmation and immediately resetting the watchlist via JS? It wouldn't require a reload but wouldn't add another extra click.

In T147922#2708609, @Xaosflux wrote:

Note: fails not only during transclusions, but also when just linking:

https://en.wikipedia.org/wiki/Special:RecentChanges/tagfilter%3Dblanking (WORKS)

https://en.wikipedia.org/wiki/Special:RecentChanges/tagfilter%3Dpossible_vandalism (DOES NOT WORK)

Converting _ to + or %20 also does not work.