Page MenuHomePhabricator

TheVoidwalker (Void)
User

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Saturday

  • Clear sailing ahead.

User Details

User Since
Aug 22 2016, 2:01 AM (396 w, 3 d)
Availability
Available
LDAP User
Voidwalker
MediaWiki User
The Voidwalker [ Global Accounts ]

Recent Activity

Nov 22 2023

TheVoidwalker closed T302812: Wikimedia\Assert\PreconditionException: This Title instance does not represent a proper page, but merely a link target. as Invalid.
In T302812#8285027, Umherirrender wrote:

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

Nov 22 2023, 1:15 AM · MediaWiki-Core-Revision-backend

Jan 3 2023

TheVoidwalker added a member for affects-Miraheze: TheVoidwalker.
Jan 3 2023, 3:15 AM

Sep 9 2022

TheVoidwalker placed T257701: Add global blocks into CompositeBlocks rather than treating them separately up for grabs.

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.

Sep 9 2022, 7:55 PM · Patch-For-Review, MW-1.40-notes (1.40.0-wmf.10; 2022-11-14), Anti-Harassment (AHaT Sprint 19: The Sanbenito), MediaWiki-Blocks, GlobalBlocking

Jul 26 2021

TheVoidwalker added a project to T287347: Loops can cause php-fpm exhaustion (CVE-2021-42040): Patch-For-Review.
Jul 26 2021, 7:19 PM · SecTeam-Processed, Vuln-DoS, MediaWiki-extensions-Loops, User-RhinosF1, Security
TheVoidwalker added a comment to T287347: Loops can cause php-fpm exhaustion (CVE-2021-42040).

Patch:

Jul 26 2021, 7:08 PM · SecTeam-Processed, Vuln-DoS, MediaWiki-extensions-Loops, User-RhinosF1, Security

Jun 21 2021

TheVoidwalker added a comment to T285100: Vector CI on REL1_36 branch fails with UnhandledPromiseRejectionWarning.

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

Jun 21 2021, 6:35 PM · Vector (legacy skin) (Tracking), Browser-Tests, ci-test-error, MW-1.36-release

May 2 2021

TheVoidwalker added a comment to T221560: Searches with hyphens yield a database query error.

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

May 2 2021, 10:04 PM · MediaWiki-Search, Discovery-Search

Apr 4 2021

TheVoidwalker added a comment to T279090: CVE-2021-41801: ReplaceText continues performing actions if the user no longer has the correct permission (such as by being blocked).

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"?

Apr 4 2021, 5:27 PM · SecTeam-Processed, Vuln-MissingAuthz, MediaWiki-extensions-ReplaceText, User-RhinosF1, Security, Security-Team

Apr 3 2021

TheVoidwalker added a comment to T279220: Bug exists where userID is displayed instead of username in DPLforum extension.

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();
Apr 3 2021, 2:13 AM · User-RhinosF1, MediaWiki-extensions-DPLforum

Apr 1 2021

TheVoidwalker added a comment to T279090: CVE-2021-41801: ReplaceText continues performing actions if the user no longer has the correct permission (such as by being blocked).

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.

Apr 1 2021, 6:27 PM · SecTeam-Processed, Vuln-MissingAuthz, MediaWiki-extensions-ReplaceText, User-RhinosF1, Security, Security-Team
TheVoidwalker created T279090: CVE-2021-41801: ReplaceText continues performing actions if the user no longer has the correct permission (such as by being blocked).
Apr 1 2021, 5:27 PM · SecTeam-Processed, Vuln-MissingAuthz, MediaWiki-extensions-ReplaceText, User-RhinosF1, Security, Security-Team

Mar 22 2021

TheVoidwalker added a project to T276954: "(next page)" link on Categories ignores the `pagefrom` parameter when the Video extension is installed: Video extension.

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.

Mar 22 2021, 3:54 PM · Social-Tools, Video extension, MediaWiki-Categories, User-RhinosF1

Feb 18 2021

TheVoidwalker added a comment to T273251: Code to prevent users from downvoting comments doesn't work as it should.

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

Feb 18 2021, 4:24 AM · affects-Miraheze, Social-Tools, MediaWiki-extensions-Comments

Jan 29 2021

TheVoidwalker added a comment to T273251: Code to prevent users from downvoting comments doesn't work as it should.

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.

Jan 29 2021, 3:54 AM · affects-Miraheze, Social-Tools, MediaWiki-extensions-Comments

Jan 13 2021

TheVoidwalker claimed T257701: Add global blocks into CompositeBlocks rather than treating them separately.
Jan 13 2021, 1:10 AM · Patch-For-Review, MW-1.40-notes (1.40.0-wmf.10; 2022-11-14), Anti-Harassment (AHaT Sprint 19: The Sanbenito), MediaWiki-Blocks, GlobalBlocking
TheVoidwalker added a comment to T257701: Add global blocks into CompositeBlocks rather than treating them separately.

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?

Jan 13 2021, 1:08 AM · Patch-For-Review, MW-1.40-notes (1.40.0-wmf.10; 2022-11-14), Anti-Harassment (AHaT Sprint 19: The Sanbenito), MediaWiki-Blocks, GlobalBlocking

Jan 12 2021

TheVoidwalker added a comment to T257701: Add global blocks into CompositeBlocks rather than treating them separately.

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.

Jan 12 2021, 4:31 AM · Patch-For-Review, MW-1.40-notes (1.40.0-wmf.10; 2022-11-14), Anti-Harassment (AHaT Sprint 19: The Sanbenito), MediaWiki-Blocks, GlobalBlocking

Dec 22 2020

TheVoidwalker added a comment to T270687: IPs can comment when globally blocked.

This would probably be made moot by T257701

Dec 22 2020, 8:57 PM · affects-Miraheze, MediaWiki-extensions-Comments, Social-Tools
TheVoidwalker added a comment to T270687: IPs can comment when globally blocked.

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!

Dec 22 2020, 6:04 PM · affects-Miraheze, MediaWiki-extensions-Comments, Social-Tools

May 22 2020

TheVoidwalker added a comment to T253300: Remove core hacks from url.py.

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.

May 22 2020, 3:52 PM · User-MacFan4000, Upstream, ZppixBot

Dec 16 2019

TheVoidwalker claimed T240872: Wiki session data lost during edits.

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

Dec 16 2019, 8:17 PM · ZppixBot

Nov 4 2019

TheVoidwalker closed T234718: Run test on publictestwiki.com for users with @miraheze/* cloaks, a subtask of T234717: Restrict sites StatusBot module can run on, as Resolved.
Nov 4 2019, 11:34 PM · User-RhinosF1, ZppixBot
TheVoidwalker closed T234718: Run test on publictestwiki.com for users with @miraheze/* cloaks as Resolved.

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

Nov 4 2019, 11:34 PM · User-RhinosF1, ZppixBot

Oct 24 2019

TheVoidwalker added a comment to T231763: Don't show VE help/welcome messages to users if seen before.

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.

Oct 24 2019, 6:41 PM · affects-Miraheze, VisualEditor

Sep 17 2019

TheVoidwalker closed T201234: Create a URL blacklist for the URL module as Resolved.

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

Sep 17 2019, 10:10 PM · ZppixBot, User-Zppix
TheVoidwalker claimed T201234: Create a URL blacklist for the URL module.
Sep 17 2019, 9:39 PM · ZppixBot, User-Zppix
TheVoidwalker lowered the priority of T201234: Create a URL blacklist for the URL module from High to Medium.

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).

Sep 17 2019, 5:36 PM · ZppixBot, User-Zppix

Sep 16 2019

TheVoidwalker added a member for ZppixBot: TheVoidwalker.
Sep 16 2019, 2:43 AM

Aug 29 2019

TheVoidwalker closed T219050: Revoking talk page access for anons doesn't work as Invalid.

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

Aug 29 2019, 1:03 AM · Growth-Team, StructuredDiscussions
TheVoidwalker added a comment to T219050: Revoking talk page access for anons doesn't work.

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.

Aug 29 2019, 12:18 AM · Growth-Team, StructuredDiscussions

Aug 28 2019

TheVoidwalker added a comment to T219050: Revoking talk page access for anons doesn't work.

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

Aug 28 2019, 9:37 PM · Growth-Team, StructuredDiscussions

Jul 5 2019

TheVoidwalker claimed T226343: Global Blocks do not prevent the use of WikiForum.
Jul 5 2019, 3:37 AM · Social-Tools, WikiForum

Jun 24 2019

TheVoidwalker added a comment to T226343: Global Blocks do not prevent the use of WikiForum.

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

Jun 24 2019, 2:38 PM · Social-Tools, WikiForum
TheVoidwalker updated the task description for T226342: Comments should use Title::userCan to determine a user's blocked status.
Jun 24 2019, 12:38 AM · MediaWiki-extensions-Comments, Social-Tools
Restricted Application added a project to T226343: Global Blocks do not prevent the use of WikiForum: Social-Tools.
Jun 24 2019, 12:34 AM · Social-Tools, WikiForum
Restricted Application added a project to T226342: Comments should use Title::userCan to determine a user's blocked status: Social-Tools.
Jun 24 2019, 12:09 AM · MediaWiki-extensions-Comments, Social-Tools

Mar 23 2019

TheVoidwalker created T219050: Revoking talk page access for anons doesn't work.
Mar 23 2019, 2:58 AM · Growth-Team, StructuredDiscussions

Feb 5 2019

TheVoidwalker added a project to T215324: Patch for T210937 needs backporting to 1.32 (API list=users mistakenly reports user as missing): MediaWiki-Action-API.
Feb 5 2019, 9:58 PM · MW-1.32-notes, MW-1.32-release, MediaWiki-Action-API
TheVoidwalker created T215324: Patch for T210937 needs backporting to 1.32 (API list=users mistakenly reports user as missing).
Feb 5 2019, 6:51 PM · MW-1.32-notes, MW-1.32-release, MediaWiki-Action-API

Feb 4 2019

TheVoidwalker created T215136: Disabling an AbuseFilter action does not remove that action from existing filters.
Feb 4 2019, 12:57 AM · Patch-Needs-Improvement, AbuseFilter

Jan 17 2019

TheVoidwalker added a comment to T213982: Special:AbuseLog issues when filtering vs not filtering results.

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.

Jan 17 2019, 12:47 AM · AbuseFilter
TheVoidwalker added a comment to T213982: Special:AbuseLog issues when filtering vs not filtering results.

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).

Jan 17 2019, 12:28 AM · AbuseFilter

Jun 5 2018

TheVoidwalker closed T141482: CentralAuth login attempt gives "No active login attempt is in progress for your session" as Resolved.

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).

Jun 5 2018, 11:33 PM · User-Zppix, MediaWiki-Core-AuthManager, MediaWiki-extensions-CentralAuth
TheVoidwalker added a comment to T141482: CentralAuth login attempt gives "No active login attempt is in progress for your session".

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.

Jun 5 2018, 12:22 AM · User-Zppix, MediaWiki-Core-AuthManager, MediaWiki-extensions-CentralAuth
TheVoidwalker added a comment to T141482: CentralAuth login attempt gives "No active login attempt is in progress for your session".

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:

Jun 5 2018, 12:19 AM · User-Zppix, MediaWiki-Core-AuthManager, MediaWiki-extensions-CentralAuth

Sep 10 2017

TheVoidwalker created T175462: Inability to lock via setglobalaccountstatus API in mw 1.29.
Sep 10 2017, 1:42 AM · MW-1.30-release-notes (WMF-deploy-2017-09-05 (1.30.0-wmf.17)), Regression, MediaWiki-extensions-CentralAuth

Jan 1 2017

TheVoidwalker added a comment to T154390: Visiting Special:SpecialPages while SocialProfile is installed throws a PHP error.

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

Jan 1 2017, 4:27 AM · SocialProfile, Social-Tools
TheVoidwalker added a comment to T154390: Visiting Special:SpecialPages while SocialProfile is installed throws a PHP error.

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

Jan 1 2017, 4:18 AM · SocialProfile, Social-Tools
TheVoidwalker added a comment to T154390: Visiting Special:SpecialPages while SocialProfile is installed throws a PHP error.

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
Jan 1 2017, 3:17 AM · SocialProfile, Social-Tools

Dec 16 2016

TheVoidwalker added a comment to T153389: "mark all as visited" appears temporarily grayed/disabled after a refresh following a watchlist reset.

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

Dec 16 2016, 1:23 AM · MediaWiki-Watchlist
TheVoidwalker added a comment to T153389: "mark all as visited" appears temporarily grayed/disabled after a refresh following a watchlist reset.

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.

Dec 16 2016, 1:17 AM · MediaWiki-Watchlist
TheVoidwalker added a comment to T150045: Add a confirmation button to "Mark all pages as visited" on the Watchlist, and update via ajax.

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.

Dec 16 2016, 12:06 AM · User-notice-archive, MW-1.29-release (WMF-deploy-2016-12-13_(1.29.0-wmf.6)), MW-1.29-release-notes, Patch-For-Review, Google-Code-In-2016, MediaWiki-Watchlist

Oct 13 2016

TheVoidwalker added a comment to T147922: Transcluding RecentChanges fails when using tags with spaces.

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.

Oct 13 2016, 2:05 AM · MediaWiki-Recent-changes