@aaron, @Krinkle: Can we use the stash cache for storing the half-parsed wikitext of references (for the duration of the parser cache)? (see https://gerrit.wikimedia.org/r/#/c/277445/13)

Strip markers would remain in the half parsed text but would be explained in the API:

I've made an attempt to refactor EditPage in https://gerrit.wikimedia.org/r/#/c/338276/.
This goes a bit beyond factoring out a backend as I've also rewritten the UI part based on an MVC pattern.

Yes, I'll merge it.

In T157715#3044879, @jmatazzoni wrote:

As part of our RC Page Improvements, we are implementing:

• A filter for patrolled/unpatrolled
• Various ORES filters that will enable users to find the edits that are most in need of review.
• User-defined highlighting as an alternative to or in addition to filtering, so users can decide which edit properties they want to spotlight.

Using these tools, which will be out this spring, users can easily find edits that are likely damaging and unpatrolled. (See this video for a demonstration of the tools generally.)

This sounds promising, though I'd still like a way to integrate other sources than ORES, such as AbuseFilter and bots.

In T156083#3002405, @Pginer-WMF wrote:

There are several points in the process where knowing that your edit is pending review seems relevant. Ideally it would be great to be able to tell editors of issues on their edits as the users makes them, or as soon as they try to save.

In case of abuse filter deferral, I've made so that the user is shown a notice after saving the page:

Notifications can work well to inform of the deferral event right when it happens. This approach is consistent on how we inform about related events such as edits being reverted. For the case of anonymous users, we may want to inform that those notifications may be because of activity from a different user:

I've added a warning about that, see image below. I've put it at the bottom to avoid being too obtrusive to experienced IPs and in light yellow from the color palette to differentiate it from other notifications.

Hm yeah, but the special page would be hard to implement compared to just adding some options.

Not just moves accross namespaces are an issue, see this recent discussion.
I think we need something like Special:NewMoves and move patrol (T98617).

Inclumedia seems to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Inclumedia seems to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Inclumedia seems to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still finds a convincing use for it, feel free to reopen it.

Mirror tools / inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still find a convincing use for it, feel free to reopen it.

Mirror tools / inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still find a convincing use for it, feel free to reopen it.

Mirror tools / inclumedia seem to be dead, and the project's initiator is globally locked. As such I am closing this task. If however, someone still find a convincing use for it, feel free to reopen it.

Looks like this is broken since January 31, see here.

I tried to load Special:Tags at Wikidata. After waiting almost 25 minutes, this is what I got: 504 Gateway Time-out nginx/1.11.6.

I think we absolutely need a form of patrol intermediary between NPP and RCP.
But tags can't be the solution, though they may be part of the solution.
We should check if an edit is worth being shown as needing patrol from a variety of sources, including: problem tags (as this task suggested) , but also ORES and AbuseFilter, and bots via the API.
Problem is how do we store this data? It would be nice for the patrol flag to have three states: -1 for "needs patrol", 0 for "not patrolled", +1 for "patrolled". Unfortunately, rc_patrolled is unsigned in the rc table, so we would need a schema change.
I'll make a task for selective patrol in a short while.

Low if this were only that, but I've addressed some related issues in the patch set, the code needed some refactoring.

@Aklapper Ok, thanks for the heads-up. I'm not sure yet if I'll rewrite the task description or simply make a patch myself.

A Revert object is a good idea, I think I'll implement this in a new version of https://gerrit.wikimedia.org/r/#/c/329651/.
This should be kept separate from the Revision object though, a revision shouldn't be aware of the Revert object, a Revision object is standalone and shouldn't depend on the page history (revisions can be moved around for instance). So I don't think we should have a method on Revision to indicate if it's a revert, but the goals underlying this task can be accomplished without.

I've done the edit, thanks for checking the tags.

This would be helpful for contributions, we don't have any built-in way to check non-redirect page creations by a user.
I'm not saying this would replace a log, but this would be easier to implement.

I could easily add a page creation tag as part of https://gerrit.wikimedia.org/r/#/c/194458/ (for T73236).

Isn't this resolved by the confirmed usergroup?

They both would make it unnecessary for extensions to set ConfigRegistry, but T155154 suggests a GlobalVarConfig object while this one suggests a new LocalConfig object (see https://gerrit.wikimedia.org/r/#/c/335383/5/includes/config/LocalConfig.php) that would be based only on the extension's own settings and handle merging with local settings. Eventually, this aims to deprecate GlobalVarConfig, and do the same thing for core (achieving a separation of configs and the removal of configuration globals).

I've done this in https://gerrit.wikimedia.org/r/#/c/335383/ as part of T156877.

Yes, it works. Thanks

It takes several minutes to load Special:Tags at wikidata, the way we're retrieving hitcounts is not efficient or sustainable.
It's also a concern for the dropdown (T27909) on cache misses.
My suggestion, implemented in the above patch set, is to create a table holding tag hitcounts, updated when adding/removing tags.

I've looked into this and the titleblacklist log entry will only appear at the wiki where the user created the account, not on the central loginwiki.
It certainly would be appreciable to have a centralized log of titleblacklist hits (same for spamblacklist) but it doesn't look easy to accomplish.

Regarding the feasibility of anon notifications (T58828), I had made a rough patch that didn't alter the db and was mostly OK for the purpose of deferred changes, so it can be done without hassle. But we might as well provide full support for anon notifications while we're at it; the implementation is relatively straightforward, I've updated the patch (https://gerrit.wikimedia.org/r/#/c/329374). We just need to make sure that the changes in the db schema are OK.

Assuming we can alter the db, I've modified the patch set to offer the same level of functionality than notifications for logged in users. They can be marked read / unread and filtered by titles, and cross wiki notifications are possible. The last one requires caching the IP address in a global key.

In T156083#2963904, @Catrope wrote:

In T156083#2963892, @Mattflaschen-WMF wrote:

E.g., Deferred Changes applies to new and anonymous users only. Would it be possible to delay Save of these users only so that the Deferred Changes analysis can be part of the Save function for them?

I think this is just a social convention currently (though we could change that). Edit filters could be used to defer anyone, I think.

It is not possible to defer edits authored by users who have the 'review' right (which there are few of: admins and designated reviewers), but AIUI that's the only limitation. Users with the 'autoreview' right (which there are many of: all non-new users) presumably would not have their edits deferred upon save, but how that works exactly isn't clear to me.

Edits are immediately autoreviewed in the NewRevisionFromEditComplete handler, while abuse filter deferrals are run in a deferred update, so the deferral always occurs after the autoreview, thus these users would still be deferred.

I don't know CentralAuth enough to answer.

In T58828#2963503, @Mattflaschen-WMF wrote:

Issues to discuss include:

• Random expiration when server caches expires

At first I only wanted this to cover the deferred changes case, but we might as well build a full fledged system. I think the cache would be enough in the vast majority of cases for the IP to get the notification. And having an archive of notifications for IPs is IMO not essential, but sure if we can, it would be preferable overall to use the db. My only concern is whether we can do so, as I was under the impression that some tables are too sensitive to be altered in some ways.

In T156083#2963681, @jmatazzoni wrote:

Hi Cenarium. Our messages crossed paths. As you can see on T58828, this task was created precisely so that we can consider whether Notifications are in the only or best way to deal with IP users impacted by Deferred Changes. The project of extending Notifications to IP users is more complex than might at first meet the eye. It's not something we want to wade into without considering alternatives.

I see now :)
I don't see any alternative, we need an asynchronous system, we can't delay the save for performance reasons,. I don't mind delaying deferred changes implementation until we get anon notifications in place personally, which IMO is a must have for various reasons. I don't think we should build a system just for deferred changes when a general one exists.

@jmatazzoni: I'm actually working on implementing anon notifications in echo, which I think is the only proper way of notifying anons of a deferred change. See T58828.

Users will not be able to make the save attempts since they have been blocked from accessing the edit URL (except in the case where a blacklist entry is added while the user was already editing the article, but it's too rare to be useful). Users are blocked from the edit URL so they don't waste their time making edits that will end up being blocked, as for protected pages.

Yes, the titleblacklist is hit by merely having &action=edit in the URL. See T23206 for a thorough discussion of this.

@JEumerus, @Billinghurst: only account creation attempts can be logged (since it's a POST request, others are GETs, so this could be abused).

@Billinghurst I've clarified the meaning of T155967, it doesn't remove the log entries by IPs, but replaces "IP(talk) matched..." with "An anonymous user matched...".
Regarding your suggestion to display the IP to members of a privileged usergroups, Jforrester said that we needed to log accesses to this data, and the only way to do that is through the checkuser extension.
How I imagine it: in addition to the "Get IP addresses", "Get edits", "Get users" options, there would be a "Get creation attempts" option showing the IPs that attempted to create a disallowed username.

So to wrap this up, I think from the consensus we need to:

1. avoid displaying anons publicly, for this I did T155967, so the log can be displayed to admins
2. if WMF wants it, remove anons from the log entries after 90 days, but this can be done with a job on the servers
3. build a way inside the checkuser extension to view disallowed creation attempts on a given account name, for this I did T155969

For this specific task, only 1 and 2 are blockers.
I've made a patch for 1 awaiting review. 2 can only be done by someone at the WMF. 3 is a bit more complex than 1 but looks feasible for anyone interested.

The parser cache might not be there but then it can fall back to the persistent storage, page_props. As for correlating between a hash and a parser cache, I don't understand because there's only one parser cache for the current revision, and one for the stable revision.

This appears to also be an issue for the graph extension then.
A revisioned page_props would not work, since transcluded content can change (which FlaggedRevs can handle in different ways, see $wgFlaggedRevsHandleIncludes).

Does this mean that <mapframe/link> does not work at all on old revisions, or that it works but requires a re-parse of the content ?

The patch for Wikibase consists in passing udoafter as base rev id, this can be merged before https://gerrit.wikimedia.org/r/330587.

Note that with rMW85cabc80e92c (https://gerrit.wikimedia.org/r/#/c/329651/), we should only need to check the revision's sha1 against the base revision's sha1.