jayktaylor / mw-discord Goto Github PK

Currently page creations use the pencil emoji, the same as non-creation edits. For quick visual distinction, it would be useful for them to use a different emoji, though I don't have any suggestions for a new one.

Reverting to an older uploaded version of a file doesn't trigger a notification.

Currently creations and edits are presented identically, except that creations lack a "diff" link after the page name, which makes it hard to spot them by just scanning through. It would be better if page creations said "created" instead of "edited", and/or were distinguished from non-creation edits in other ways.

So I have $wgDiscordDisabledNS = ["MediaWiki"]; set, and still get notifications for MediaWiki:Common.css.
Am I doing something wrong?
This is on 1.39.

Discord rate-limits individual channels to 5 messages a second (though the documentation says to use API headers instead of hard-coding assumptions about rate limits); when a wiki is experiencing action rates greater than this (e.g. if $wgDiscordNoBots is set to false, and a few bots are running simultaneously (or one really high-rate bot is running)), messages will fail to send. Possible solutions are to retry sending on receiving an error (reasonable for sudden transient spikes) or collecting multiple actions into a single message (would be required for longer durations of high-frequency actions). Dropping messages should probably be avoided unless explicitly opted-in (maybe accompanied by dropping an extra message to be able to send a "X messages dropped, see recent changes on-wiki" notification).

Currently three links are offered for the user that made an edit: the user's page, their talk page, and their contributions. However, IP user pages are almost never created, and as a result links to them are generally useless clutter. Therefore, the link to the IP's userpage should be removed and the IP address should instead link to their contributions.

A couple of issues are still happening with the recent changes bot. Most notably is the fact that templates on page creation/uploads are being subst'd, as is known. Additionally, editing a file page, to say, add a license or tag for speedy deletion also doesn't show up.

Another issue is that file names get italicised if they have slashes in them. I'm not sure if this is preventable, but I also didn't remember it being a problem with TyBot so I'll put that here too.

And i think this is bit related to SemanticMediaWiki/SemanticMediaWiki#5406 this issue. Somehow mw changes the way to load the user name. CIDR won't be correctly loaded. Of course, normal ip address is showing fine.

Above is 1.39, below is 1.35

As title says, It would be great to have a feature where one can disable notification edits for the namespace: User:Name/Sandbox , User:Name/sandbox.

This error is produced on changing the visibility of a revision (specifically on changing the visibility of the revision text, though I'm sure it would happen on changing the visibility of the summary or actor name, or any combination of them). Comparing the parameters of onArticleRevisionVisibilitySet() to other functions, the former uses &$title while e.g. onArticleUndelete() instead uses Title $title (but looking at more functions suggests there's no real set pattern to what exactly is passed in for the page title of the action performed, I'm guessing because the hooks used just aren't consistent either?)

Note that this was encountered on MW 1.31, so changes in subsequent versions of MW may have fixed this (the parameter references are identical between the REL1_31 and main branches of this extension).

Related to #13. Presumably this would also affect usernames.

page

The current hook-based design of this extension means it can only show actions that trigger a hook, and data accessible via that hook (see #23, #28, #30, probably other things no one's noticed or bothered to file an issue for). I'm assuming this won't be a straightforward drop-in replacement, so definitely more of a wishlist item than anything.

Most other mediawiki extensions can be translated there. I'd expect the mediawiki translation community to add support for many more languages if it was available on translatewiki.net.

Some links for requesting this are at https://translatewiki.net/wiki/Translating:New_project

It appears it is possible to send forged user right notifications to the webhook, maybe even other log entries. No changes actually happen. I have no idea how this is done, however, but it did stop once the offender was blocked.

Figured out how it works.

Mediawiki won't outright reject your POST request for usergroup changes when you don't actually have permisions to do that. While whatever you do in the UserRights form will silently fail in the background, this is enough to throw a Discord notification with the Reason text supplied. This can be done even if you are not logged in and the wiki does not allow IP edits.

Works with another Discord extesnsion too. Could be a a mediawiki bug.

Character entity references used in edit summaries are not replaced with their character literal. For example:

Dinoguy1000 (t|c) moved Category:Cards needing a passcode redirect to Category:Cards needing a password redirect passcode → password (diff) (m) (+0)

which should be

Dinoguy1000 (t|c) moved Category:Cards needing a passcode redirect to Category:Cards needing a password redirect passcode → password (diff) (m) (+0)

Hello everyone, I encountered a problem that when the add-on is enabled, uploading pictures to the wiki does not work. If you turn it off, the pictures are quietly unloaded.

[7c377a646d61f5d4db582efd] /index.php/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%97%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0 Error: Call to undefined method LocalFile::getUser()

Backtrace:

from /var/www/domain.example/extensions/Discord/src/DiscordHooks.php(261)
#0 /var/www/domain.example/includes/HookContainer/HookContainer.php(338): DiscordHooks::onUploadComplete()
#1 /var/www/domain.example/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
#2 /var/www/domain.example/includes/HookContainer/HookRunner.php(4080): MediaWiki\HookContainer\HookContainer->run()
#3 /var/www/domain.example/includes/upload/UploadBase.php(940): MediaWiki\HookContainer\HookRunner->onUploadComplete()
#4 /var/www/domain.example/includes/specials/SpecialUpload.php(568): UploadBase->performUpload()
#5 /var/www/domain.example/includes/specials/SpecialUpload.php(232): SpecialUpload->processUpload()
#6 /var/www/domain.example/includes/specialpage/SpecialPage.php(701): SpecialUpload->execute()
#7 /var/www/domain.example/includes/specialpage/SpecialPageFactory.php(1475): SpecialPage->run()
#8 /var/www/domain.example/includes/MediaWiki.php(327): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#9 /var/www/domain.example/includes/MediaWiki.php(923): MediaWiki->performRequest()
#10 /var/www/domain.example/includes/MediaWiki.php(576): MediaWiki->main()
#11 /var/www/domain.example/index.php(50): MediaWiki->run()
#12 /var/www/domain.example/index.php(46): wfIndexMain()
#13 {main}

Per title. There might be other log types that the extension currently doesn't send messages for, that it probably should, too.

For example, the unblock here, which produced this message:

removing the discord extension seems to fix the issue, can get annoying because it does not redirect you to the article page

In src/DiscordHooks.php, some functions require a $user parameter to be passed in, whereas others use the $wgUser global. This is inconsistent and potentially a source of errors (e.g. I almost didn't notice the discrepancy in #8 ). If there's a functional difference between these, it needs to be clearly documented.

There might be places where RequestContext.php could be used instead of the current $wgUser.

ApprovedRevs provides the following hooks that can be turned into a webhook message:

ApprovedRevsRevisionApproved
ApprovedRevsRevisionUnapproved
ApprovedRevsFileRevisionApproved
ApprovedRevsFileRevisionUnapproved

Unfortunately, they are not documented. Cargo uses them though, so you might be able to get the arguments the hook sends there.

This would be great for projects that have public editing but require you to have your edits approved. Since we use mw-discord as a public audit log in Discord, it would be useful to be able to have these hooks be used so we can see when a revision gets approved/unapproved and maybe include an approve link in a page creation/update for our moderation team to easily click on.

unfortunately

(https://yugipedia.com/index.php?title=Special:Log&page=Contact+Fusion)

Discord/src/Utils.php in handleError at line 81

I think it need to use a "is_set" function first.

Per https://www.mediawiki.org/wiki/Inclusive_language

diff

Please implement file_get_contents method for calling Discord API and let users select method to use, like DiscordNotifications extension does.

I haven't tested all the hooks but I no longer receive messages from the bot for page edits or uploads after upgrading to 1.39. I have also tried reinstalling the extension.

For the Hook: PageSaveComplete,
The string for the hook name is set to: 'PageContentSaveComplete"

The default config for Discord Emojis, does not contain a definition for "PageSaveComplete".

The end result is Undefined Array Key in https://github.com/jayktaylor/mw-discord/blob/master/src/Utils.php#L85

This sporadically shows up in my php responses in other parts of mediawiki and causes issues:

If $wgDiscordMaxCharsUsernames is set to null, this variable never gets set and breaks the user link sent to Discord. (This was observed on the REL1_31 branch, but the relevant code is functionally identical in the current main branch, so the breakage should also happen there.)

See the above image. A username %login% signed up and it breaks discord message.

Note: As of 1.40, % is not invalid character for username by default. cc: https://www.mediawiki.org/wiki/Manual:$wgInvalidUsernameCharacters

...because Discord's logic on when to display timestamps isn't great for this purpose.

Probably a compact human-readable format would be best, a modified version of ISO 8601 or something.

This would prevent users who are defined as the "performer" of an action (as defined by the MW hook) from having their actions sent to Discord if their MediaWiki username is defined in the configuration.

Not really much point to it.

Because of this removal, uploading files results in this error:
/wiki/Special:Upload Error: Call to undefined method LocalFile::getUser()

This is the line:

Per title.

Raised by Yugipedia.

[6d47fe4abf2e849c3be39ccd] /index.php/Special:Block/testuser Error from line 210 of /var/www/neko.kazdel.com/mediawiki/extensions/Discord/src/DiscordHooks.php: Cannot access protected property MediaWiki\Block\DatabaseBlock::$mReason

When attempting to block a user The Discord Extension is causing this, and when i remove the Discord feed it fixes it however i want to have wiki feed without this error Can you Please perhaps Fix this?