Account creations there are already logged on #central, not sure about renames

@Niharika: It is acceptable. MIT license is compatible with GPL v2 or later.

Another instance: https://es.wikipedia.org/w/index.php?diff=106943027

Note that the description shouldn't be "When a person is accessing" but "When it is attempting to edit" (or equivalent), which is when we check for blocks. Attempting to check blocks on every page view would kill the site ☺

I would think this is public info. Looking at the pastebin, this doesn't even attempt to be a leak, it's a script for mapping usernames and emails on git. It's very likely that it was made by someone on our community.

I suspect it may be looking for the src attribute look at most at N characters, while in your post there are many characters before it.

I prefer the first mockup, I'm not convinced about the others.

The proprietary nature of Google Chat isn't just a philosophical issue with regards to using the service. It also means that the features (in this case notifications) developed for Google Chat won't be available to developers not directly contracted by WMF.

In fact, those timeouts appear even on the early hops. The ticket also includes a successful tcp traceroute, and no explicit mention of timeouts.

Well, if the server itself is needed, it will be doing its work with a different IP address than the one of wdqs1004, since it would have been suffering the same connection issues as wdqs1004 (just the other half time).

@Huji that is a utf-8 name shown as latin1. Seems there is an extra or missing conversion somewhere.

In T188160#4037130, @jrbs wrote:

Right now it would be incredibly confusing to admins if they see edits from a range that's currently blocked.

Please remember to 301 /wiki/.* to the new url…

Agreed, this is something to fix.

Well, getting notified by SineBot doesn't seem _that_ bad, since the user should have signed the comment themself. OTOH, the admin mentioned by CommonsDelinker doesn't need the ping at all.

Should it really accept pm commands?

Why does this need a second task. I see this as one issue.¹ Whenever the entry on user_groups is removed from there (either by another user_groups action or by the cron job), that must add it into user_former_groups (if not already there).

Use $dbw->insertId()

@Hugi: I think CheckUserHooks::logLoginAttempt will need to be public, not protected.

I would actually find that a that system provides a signed copy (such as a pdf of the edit with some boilerplate explaining the contents) would be more useful.

@Huji I think the point is that nothing can use that User-Agent. You are setting a variable that cannot be read…

The hint for mcrypt.so is

undefined symbol: spprintf

Cool anchors don't change.

I was just trying to address the stated concern, not make it a perfect solution (we will probably still have irc.wikimedia.org for some time, so it would be good that things were better). Also, I am assuming bots will reconnect and rejoin with near-zero downtime, trying several A records as needed.

However, it's operating without any redundancy, in terms of both individual hardware failure, and datacenter failure.

I guess the latin magic words would need to be added as aliases for the translation to Cyrillic script .

They seem to have one: https://github.com/wikimedia/WikimediaUI-Style-Guide (maybe it is already in gerrit?)

Improving FeaturedFeeds seems the way to go…

@Legoktm pointed out that "Gerrit would probably not be able to talk to things in cloud services" and indeed, it seems undesirable that Gerrit login page (an high security context) included content from a lower security one. (E.g. a naive implementation copies html produced there into Gerrit login page, then someone compromises the toollabs project and uses it to steal developer credentials)

I guess the existing विकिविद्यालय should be kept as an alias, so that existing links don't break.

It would be nice to have a generic solution that can be used by other sites wishing to include the POTD, ie. keep the Gerrit-specific part as small as possible.

In T185160#3913793, @bmansurov wrote:

• Some users may have the same babel info in multiple wikis. This may have resulted in duplicate counts in the final result. Let me know how we should deal with identical usernames in multiple databases. Should we consider them different users or the same?

Alternatively, give them a real cookie containing a temporary token, which is what we will be using.

Note we'd then have to vary on that cookie, at least for views served via EditPage.

In T184749#3896917, @Anomie wrote:

The "utf-8" flag is set in the DB, yes. But the text itself is already mojibaked when saved in the DB. The reading back from the DB works fine.

On the BebasNeue typeface, the design agency wanted to use it for certain graphics so it's use is limited. Because the majority of the site is in our open source brand font (Montserrat) we had accepted this artistic choice as a "limited decorative" element.

Ah, okay. So those pages are currently cache-bypassing without being session-starting. I assume the patch would need to change this to do both. Or is there another way? I haven't checked the numbers, but I imagine we should be able to handle the increased load from that (basically, anon bounce rate of edit page; possibly inflated by crawlers).

This bug only happens when $wgLegacyEncoding is set. But the variable doesn't seem to be checked anywhere!

Anomie said:

EditPage::internalAttemptSave() → WikiPage::doEditContent() → WikiPage::doModify() → Revision::__construct() calls RevisionStore::newMutableRevisionFromArray()

I don't think the file license would be compatible with scaps run by WMF employees. Could be used by those run by volunteers, though.

I guess your manager at WMDE should confirm here that you are indeed a WMDE developer?

This task says: We have docs at https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki and https://www.mediawiki.org/wiki/Manual:Upgrading Someone should try installing using that documentation, and see if they are outdated or is wrong with such documents.

The extension seems to work with the provided changes. A Special:WatchSubpages special page is added, and it allows adding pages to the watchlist.

I expect other developers would be interested on this as well, but I can help mentoring this (added).

In T177809#3813320, @Reedy wrote:

I suspect, it's possible to grep for this... But I imagine it would need some post-processing...
Grep for php files with a class in it, get the file name, group and order by file name.... and exclude if after grouping it's just 1?

Maybe it would be possible to extract from swift the list of files stored there? Then no HTTP requests would be needed (unless this shows that the problem lies on a different layer, of course).

Completely confusing indeed.

Rather than "prevent", I think the UI should offer to "replace" the existing request (conceptually equivalent to cancel + open new one, but nicer UI)

There is a third extension fighting for 'v' accesskey on edit page: FlaggedRevs.

I don't think it makes sense to have different actions depending on browser, either.

Thanks fo the answer, @Sagorika1996!

Let me also support the position of not restricting <templatestyles> to a specific namespace.

No problem. I was just reporting that the assumption that it was issued just once and never again turned out to be false.

Is this expected to be a private tool (only showing your own contributions) or a public one (you can view the contributions of any user)?

I just received this ghost notification a second time. This time with &uselang=en version:

I don't think there are any news to investigate here.
I get a "new device" notification every other day or so (but I don't login to the wiki everyday), since I enabled it as stated on T174263#3574597

I remember suffering silly self-conflicts. An additional issue is that ~~~~ magic expansion almost ensures that there will be a conflict, even if it could otherwise be automatically resolved.

@IKhitron By definition, if the system does something that it shouldn't be doing, it is a bug. You may consider it unlikely, or even that the reporter was wrong. But if we admit that it happened, well, how else would you categorize it? :)

I wonder if it is worth creating a course on Visual Basic 6 on 2017 (19 years after release, unable to create 64 bit apps, unsupported for ~12 years…).

1- That captcha is not accessible, is annoying (all captchas are to some point, though), slow to solve, sometimes ambiguous, and generally a pain to pass (even in the best case).

That's the bug. Supposedly, that shouldn't happen…

So, you can't be sure.

What's ambiguous about:

I don't think we should be setting per-wiki defaults for these preferences that should be global. See T174263#3557302

In T174568#3572584, @IKhitron wrote:

In T174568#3572046, @Platonides wrote:

Perhaps Google is smarter and uses more datapoints/configured differently.

Did you check this?

They are now 301s to http://www.aol.com/

Maybe they do. Perhaps Google is smarter and uses more datapoints/configured differently. They could even not be using Gmail.

@IKhitron if the browser is configured to delete the cookies on exit, it will be unfamiliar every time, so you are back to "Did he edit recently from a nearby IP address?".

In T174568#3571338, @IKhitron wrote:

Well, I already that my oppinion. Email when login fails is something small and not important. The mail message when somebody evil succeeded to log in to your page js the important issue.

I am surprised by this. I thought this was GPLv2 (like MediaWiki). Maybe we talked about it on Berlin but forgot to write it down? O_O

In T174263#3560842, @IKhitron wrote:

In T174263#3560835, @Niharika wrote:

We were concerned about spamming users with too many emails/notifications.

If anybody is beeing spammed, they can ask to block the IP, or just opt out in preferences.