In T34815#9437885, @Bugreporter wrote:

Simply we can just do so:

• Remove the user row from user table. Now MediaWiki will treat the account as unregistered
• Change the actor_name to something like "Deleted user #123123" so histories and logs now shows the anonymized name, and (optionally?) actor_user to null
• Some table (e.g. user_groups, user_properties) now contains rows that make no sense, and can simply be removed
• Now the user is deleted for good

For non-Wikimedia wiki, this provides a simple way to remove e.g. (1) spam/vandalism only account and (2) account closed on GDPR request.

Does some extensions assumes the existence of a user_id? Check and fix them

https://en.wikivoyage.org/wiki/Wikivoyage:Listing_editor seems to cover everything requested here. MediaWiki-extensions-Listings is being archived and listings are now just template calls so this sort of thing should be handled by on-wiki gadgets not extensions

And https://www.mediawiki.org/wiki/Talk:Moderator_Tools

This is also being discussed https://www.mediawiki.org/wiki/Talk:Growth#c-KStoller-WMF-20240627182400-Alexanderkowal-20240609170800

So was flagged revs giving some users rights to mass revert back to a previous rev? I still don't think I get it lol. Apparently the German wikipedia uses proposed edits unilaterally for new editors, so you might be able to copy that and put it behind a checkbox? The edit history shenanigans may be more technically complex

@Aklapper

Hi, one of the things that inflame edit wars is the binary between published and unpublished. If someone makes an edit that they feel corrects a grave injustice and it is published, they have achieved their goal. If someone reverts that and makes it unpublished, they would receive it as regression and likely respond angrily. Encouraging the use of proposed edits for controversial edits means that that editor has to work with the reverter in order to achieve their goal of getting the edit published, and the process is one constant progression.

Hi @Alexanderkowal, thanks for taking the time to report this and welcome to Wikimedia Phabricator!

Please do not "bump" tasks in Phabricator. Thanks!

I would like to bump this again, just in case anybody out there is still working on these sorts of things.

one could try to fix the current tool, for instance by migrating it to a Cloud VPS instance (as sketched in Wikidata_talk:Edit_groups)

Quick update on this: undoing edit batches on Wikidata via the current EditGroups has been broken for about two months now and the few hours I have spent trying to fix it have not been sufficient so far.

In T3605#6851298, @BrandonXLF wrote:

One major use case would be the {{Empty section}} and {{Expand section}} templates at the English Wikipedia. The templates would be able to use this magic word in edit links by adding &section={{SECTION}] to the links. This would make it easier for editors to help expand these sections and not have to navigate to them by scrolling through the editor for the entire page. See this section on the Village Post.

Boldly calling resolved now that interwiki usernames are a thing.

I don't think there are hackathon-sized improvements to MediaWiki core specifically that would help here.

Long resolved via VisualEditor. Besides, many experiments that tried to make it easier to upload images ultimately failed because the communities (most notably Commons) got spammed with unlicensed selfies and images downloaded from random websites.

On WMF wikis at least, each project with oversighters decides how they want to intake such requests to their workflow - it is certainly not consistent, by choice. Would this replace all of the other systems with some sort of of-wiki workflow (akin to perhaps the globalrenamequeue)?

While the Design-System-Team doesn't plan to focus on this any time soon, I think it's something to consider for the future so I'm going to move it to our roadmap parking lot.

just a side note (because it is only addressing a set of extensions based around SMW), but there is a crowdfunding now for Semantic MediaWiki using Open Collective Europe: https://opencollective.com/smw

About "talk pages" I think that would be possible only creating something based on Flow, but, as far as I know, that is sadly under some kind of decommission :(

In T187749#9291121, @kerberizer wrote:

FWIW and in case anyone's interested, on bgwiki we have a Python daemon that does the job for us for a few years now: https://github.com/wikimedia-bg/git-sync

The JS, Module, Spam-black/whitelist, and Titleblacklist pages are trasnparently synchronized to https://github.com/wikimedia-bg/ -- the wikipedia-{ui,lua,spam,tbl} repos respectively.

There's also a small gadget that provides proper links to GH in the page histories: https://bg.wikipedia.org/wiki/MediaWiki:Gadget-ParsePhabLinks.js

Note there is a Reading List feature, though it is only available in Apps. See https://www.mediawiki.org/wiki/Wikimedia_Apps/Synced_Reading_Lists.

Thanks. I'll have to check how it's configured on my wiki.

No the search engine searches are listed separately, the Site Search Keywords report "lists the Search Keywords that visitors searched for on your internal Search Engine". On my Matomo instance it definitely shows searches that have been done via the wiki's search box.

@Samwilson those are search engine searches, not searches done on wiki.

The Matomo extension works with site search and shows what keywords have been searched for. It requires a separate installation of Matomo, but that has other benefits anyway.

Thanks for the review @Samwilson - you are correct; I had misspecified the element that this would customise.

I'm not sure I understand the request here. Are you talking about the <head> element? It sounds like you want to add more formatting to the <title> element.

I'm not sure that's a duplicate: it seems like it wants ?section=append to add a new untitled section at the end of the page (with the normal editing form). This task sounds like it's more about a in-page textbox.

IP Info now exists.

Semantic MediaWiki issues are now tracked on GitHub not Phabricator.

MediaWiki-extensions-DocBookExport now exists, which I guess doesn't quite resolve this task.

Related: Incident-Reporting-System

Can this be closed as resolved now that Edit Recovery exists?

Related/possible duplicate: T311797

DiscussionTools now does this.

FWIW and in case anyone's interested, on bgwiki we have a Python daemon that does the job for us for a few years now: https://github.com/wikimedia-bg/git-sync

So I kind of actually implemented this myself 🙂

There is an experimental extension MediaSpoiler that can hide certain images/videos.

@Dringsim: Please use the feature request form (linked from the top of the task creation page) to create feature requests, and fill in the sections in the template, instead of deleting them.