In T200391#5457005, @D3r1ck01 wrote:

In T200391#5456871, @MBH wrote:

@D3r1ck01 Will Educational Program namespaces be deleted in projects where EP was installed? For example, ruwiki, EP namespaces still exist (but its localization already gone).

Yes @MBH, we'll clean those up as well. I see related things in mediawiki-config, see links below;

• https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L18686
• https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/CommonSettings.php#L2965

So far as I can tell, we've yet to resolve the matter of retrieving the old data from the education extension. This should probably stay open until then.

In that case, since this is a long-running epic -- one who's main task has not yet been resolved -- I have reopened it, and also added the other task for tracking.

I believe that's what this bug is already doing, judging by the related tasks list, comments, and commits. Changing the title might be more apt than closing (something like "Support native client-side SVG rendering"). Also when considering that its related subtasks are still open, it doesn't make much sense to close at this point.

Wasn't this bug about native client-side SVG rendering, without relying on third-party scripts?

Is there any plan to let the maxage parameter work correctly? Currently it still returns a Cache-Control header with max-age=0 despite explicitly setting it to a higher value. Using bcache=1 isn't changing the behavior either.

@kzimmerman First off, thanks for checking up on this.

Just my two cents, but wouldn't it make sense to reserve all one-, two-, and three-letter URLs for future use? The extension could start the counter at four-letter codes (like 'aaaa' or something) and leave the shorter ones open. That would allow the single letter ones to be used for important things like projects, and the two- and three-letter ones to be used for language codes and such.

If we're concerned about new users being shown unnecessary info, this could be restricted to logged in users or even privileged users when using Special:CreateAccount

@Tbayer Sorry to keep bugging you, but have you been able to find time to finish this? We've been making waves on the Village Pump (again), and with the new discussions underway, I think this data would help shed some light on how the namespace is used. Off the top of my head, I can't think of anything else to add to the above request - not until we see the data, at least. Thanks again for looking into this.

No worries, I figured things would slow down over the holidays.

And your request had the bad fortune of being the first time that this issue in our existing data surfaced...

Nice. Gotta keep you guys on your toes somehow. :)

First off, thanks for looking into this. Now let's dig in.

If you were to add a user preference "Don't open redlinks in edit mode" that applies regardless of the currently configured editor, that would pretty much solve the problem. The interface would just have to not append &action=edit to links that have &redlink=1 in the URI. I have a bit of user JS doing pretty much this exact thing as mentioned in T195914.

In T209749#4801975, @MarcoAurelio wrote:

It only exists so the Toolforge admin panel can verify 2FA tokens

Can you please clarify this? I'm not sure why Toolforge (a shared project with tools created and maintained by regular people) needs to access my 2FA tokens. I am sure I am confused here, but I'd be glad if this could be clarified. Thanks.

I agree with @NickK that being able to show more than 1000 entries is very handy for RC and CVN work. At the moment I have to use multiple tabs, each with different filters to "break up" the number of entries, since I'm limited to only 1k per tab. Perhaps restoring the previous limit of 5k would be better? If it's a question of users abusing the high limits, maybe limit it to extended confirmed or higher?

In T209749#4801895, @Platonides wrote:

I think we should decline this task as worded.

@1997kB I didn't think about that. Then yes, we'd need a way for sysops and account creators to override that. I'm not even sure how that would work. Would there be a box added to Special:CreateAccount to input a global account name and force local creation? Or would there be a limited access to Special:Block specifically to override the account creation blocked flag?

An alternative would be to modify how the "Account creation blocked" flag works, so that it doesn't apply to an autocreate via the global account.

In T210822#4789323, @Dvorapa wrote:

It could also help to restructure the order of items. Currently we have (watchlist):

 diff    _ hist .. tag    _ page _ time   .. size   .. author _ talk   _ contribs _ ->section _ summary
(change _ page .. change _ page _ change .. change .. change _ author _ author   _ page      _ change )

I would restructure it like this:

 page _ section _ hist .. tag    _ summary _ size   _ time   _ diff    .. author _ talk   _ contribs
(page _ page    _ page .. change _ change  _ change _ change _ change .. change _ author _ author  )

In T210909#4791710, @Anomie wrote:

With how much people complain about the inconvenience of using 2FA, I suspect that disabling all their user scripts really won't fly.

Also repeating here: that snippet above using just an a.new selector only works for redlinks in the page body (since they're only generated inside mw-parser-output). It will still leave links with &action=edit elsewhere in the interface (article/talk page tab, edit history, contribution history, log entries) if the page is nonexistent. Adding an option to not open the new wikitext editor in edit mode on new pages would be helpful.

I agree with Majora and Risker that this change should be communicated to all the projects affected (enwiki is already aware, of course). This should be posted to all the relevant Village Pumps or equivalent.

@Tbayer Just curious if the analytics team had time to pull any data for this yet.

As I just posted on WP:VPT, I use the following snippet in my common.js to neutralize the annoying behavior:

(function() {
    var len = document.links.length;
    for (var i = 0; i < len; ++i) {
        var l = document.links[i];
        if (l.href.indexOf('&redlink=1') > -1) {
            l.href = l.href.replace('&action=edit', '');
        }
    }
})();

Essentially, we would like to be able to disable the default behavior of automatically opening redlinks in edit mode.

Related VP discussion: WP:VP/T#Issue with my Special:Contributions page?

Issue opened on Github: https://github.com/openzim/wikimedia_wp1_bot/issues/7

Thanks for looking into this. We're still in the process of discussing the construction of the RfC and the criteria for the guidelines, so we have time. We want to be thorough and build a proposal that will withstand thorough community scrutiny. You can see the ongoing discussion for details on how that's progressing.

In T135301#2311507, @Niharika wrote:

The reason behind this request was that reviewers shouldn't need to leave the tool to post a message to the editor's talk page. I liked your idea about having a button to notify the user appear after the reviewer marks it as a True Positive. Maybe we could do something along those lines.

Ok, so I managed to pin down why the editor save box doesn't show up sometimes. When editing a non-talk page, clicking the tab for that page triggers the editor save box (e.g. "read" tab on an article, "project page" tab on project namespace, etc.), but clicking anything that would change the URL (talk page, main page, your user page, etc.) triggers the browser's unsaved changes prompt (so no ability to discard).

In T85470#4095858, @jberkel wrote:

I've been a few times now in this situation where unwanted changes were recovered.

Maybe it would make more sense to place this "cancel" button in context, just below the message: "Your changes have been recovered" => "Abandon/reload etc".?

This sounds to me like something that T107595 (Multi-Content Revisions) could be useful for.

In T197603#4404438, @ggellerman wrote:

@Deskana
Now that RemexHTML has been enabled on English Wikipedia, what is the plan for deploying TemplateStyles there?

In T198552#4392139, @MusikAnimal wrote:

It's not really helpful, but a log (if you want to call it that) is at https://phabricator.wikimedia.org/feed/?userPHIDs=PHID-USER-7ztcnkn7p4jjem6mirro. All actions under that account were part of the cleanup effort.

In T198552#4391111, @MacFan4000 wrote:

The bot would appear to have finished! Now all that is left is to fix anything missed by the bot.

In T198574#4384662, @Aklapper wrote:

Anyone can easily filter out mail notifications by filtering on the sender.

In T198552#4365979, @MusikAnimal wrote:

It would appear that @Community_Tech_bot is currently tackling these, although I'm not sure it's getting every change. In several cases, it's missed the priority (T197020) or even the title (T197103) when reverting changes. I'm not sure if maybe it's built a queue of changes to revert that aren't necessarily in order and it will get to them eventually, or if it failed on those and just moved on to the next one. Might be something for the operator to look into further, once the bot is done with this run.

Currently running as @CommunityTechBot (a formal phab bot), and as of ~16:00 UTC July 1, it is properly restoring the priority.

It is still regularly hitting the rate limiting, as am I. It would be wonderful to make bots exempt. @20after4 tried to help me with this, to no avail.

If the bot didn't revert the title or anything else, it's because it hit the rate limit.

In T198552#4370325, @Vachovec1 wrote:

Ugh. Is there any way to grant the bot an exception from the throttle limit?

Was this the same vandal as 14 days ago (T197456)? There should definitely be a permanent throttle(s) for how many tasks can be modified by one person in predefined timeframe (f. e. 5 or 10 tasks per minute and/or 100 tasks per hour with exception for admins and certified bots).

Perhaps there should be a user preference implemented to turn off bot-generated notifications.

And now the latest example: https://phabricator.wikimedia.org/p/Vvjjkkii/ - Wrecked several thousand tickets, before they were disabled on 20180630.

In T198552#4368421, @Scott wrote:

Yeah - on enwp we can use RevDel to remove the visible traces of vandalism, but that's obviously not an option here.

@AfroThundr3007730 wrote:
The potential for damage probably outweighs the benefits of attempting to do a DB-level revert. If there were regular snapshots, the entire instance could be rolled back to the most recent good version. That may not be viable, depending on how much legitimate user activity was occurring at the same time.

Surely the answer would be to roll back the tasks that were last touched by the vandal, not the entire DB?

In T198552#4368316, @Scott wrote:

Once the reversions are done, will it be possible to get the traces of this attack wiped? TBH it seems to me like this matter would best be handled at DBA level.

In T198552#4365979, @MusikAnimal wrote:

It is also regularly hitting the rate limiting, as am I. It would be wonderful to make bots exempt. @20after4 tried to help me with this, to no avail.

If the bot didn't revert the title or anything else, it's because it hit the rate limit.

In T198552#4362683, @Jsamwrites wrote:

@Aklapper Is reverting being done for all the affected tickets. I see that the changes have been reverted on ticket https://phabricator.wikimedia.org/T195219. But there are other tickets as well (like https://phabricator.wikimedia.org/T195197, https://phabricator.wikimedia.org/T195036). In fact, it looks like a long list: https://phabricator.wikimedia.org/feed/?userPHIDs=PHID-USER-4f6g67fxmrb2t5z7dzky

In T198552#4362456, @Mainframe98 wrote:

There's an additional problem caused either by this vandal or the cleaning up done afterwards: Projects that were added (including: CheckUser, #Connected-Open-Heritage-Batch-uploads_(RAÄ-KMB_1_2017-02), Tamil-Sites, Gamepress, Hashtags, Jade, KartoEditor, Language-2018-Apr-June, New-Editor-Experiences, Mail, WMDE-TechWish) will no longer show, and instead display the error

>>> UNRECOVERABLE FATAL ERROR <<<

Maximum execution time of 10 seconds exceeded

/srv/deployment/phabricator/deployment/libphutil/src/utils/utils.php:1168

In T198552#4362430, @SUM1 wrote:

They vandalised practically all of the tasks I started. :(

I think we've got them all at this point. At least I don't see any more from his activity feed. I stand corrected.