This ticket should be closed as won't fix. "Vector 2022" and similar names were terrible from the start and that was obvious to nearly everyone. The issue isn't that skins are difficult to rename, the issue is that a very small number of people have chosen incredibly poor names for skins.

I spent a few minutes puzzling over this last night. The class only being applied to the first link and only when a timestamp is present made it extra enjoyable to debug.

Reverting misguided closure.

Reverting misguided closure.

In T124379#1959173, @Cenarium wrote:

This would be even more of an issue if we implement per-category editnotices this way. By targeting templates like Template:Large category TOC, vandals could literally affect millions of pages. We would likely have to semi or template-protect these templates from editing, which would IMO be an undesirable outcome.

Sorry for the bot spam noise.

In T308995#7951881, @Marostegui wrote:

@valhallasw if you can update https://www.mediawiki.org/wiki/Wikibugs to make it clearer...I think that'd be the only pending thing before we can close this task.

In T194105#5338956, @DannyS712 wrote:

By "rearrange table columns", do you mean like dragging them to move in a user defined manner or sorting the columns based on a value in a specific row (as opposed to sorting rows based on the value in a specific column)

It seems like the regular error page is being rendered now, at least:

In T303774#7776704, @Bugreporter wrote:

I really want to ask: Why we does not have a bot to globally block known proxies? It may be meaningful to bring ST47ProxyBot and so on to global blocking known proxies.

I'm a volunteer and my IRC bot was working its way through a very large queue due to these blocks. Some user many years ago decided to stalk every action on Meta-Wiki in their private IRC channel. That's why I happened to notice and I'll fix the bot when the queue clears and then probably move on with my life.

In T303774#7775994, @Majavah wrote:

Is issuing thousands of global blocks per day now an accepted standard practice?

Apparently yes, and that something that should be discussed on meta and not here.

In T303774#7775994, @Majavah wrote:

Closing since I don't see anything actionable here.

Also likely related: https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archive335#Recent_proxy_blocks.

Likely related: https://meta.wikimedia.org/wiki/Grants:Project/Rapid/GeneralNotability/Bullseye.

In T303774#7775864, @Aklapper wrote:

Hmm, have you asked stewards, as they might know best? :)

Related: P22459.

Possibly a relative of T303010: Query execution timeout for certain Special:Contributions queries.

In T301505#7742137, @akosiaris wrote:

Hi! This resurfaced during the weekend. It is not a single issue (despite appearances), rather the message "upstream connect error or disconnect/reset before headers. reset reason: overflow" that we see can be a symptom of various causes. It is not resolved yet and has a chance of reappearing over the next few days/weeks while we work on what we hope will be a set of more permanent solutions.

This issue is still happening.

We would like to change the default skin version on a new set of pilot wikis from legacy Vector to the most recent version of Vector as per the results of community consultation.

@matmarex: Patch demo is awesome, thank you so much!! I just used it with https://gerrit.wikimedia.org/r/c/mediawiki/core/+/762099 and I was able to spin up a new wiki in 59 seconds and easily test my changes.

Thank you all for investigating this issue. Confirming that I have not touched this script in months, honestly I'd forgotten all about it again. The source code is here: https://github.com/mzmcbride/daily-article.

In T264370#6513972, @AntiCompositeNumber wrote:

The undeniable truth of software engineering and computer security is that bugs happen. While techniques like automated testing and code review are used to try to prevent bugs from entering production, and deployment stages are used to minimize the impact of new bugs, those techniques are not capable of preventing every bug (and thus, every security issue) from hitting production servers. This is because all code is written by humans and humans are imperfect.

Trying to eliminate all security problems is a noble goal, but it is also a futile one. Instead, it is much more important to ensure that there is an effective response to those security problems once they are discovered. The forced logouts are an example of that plan in action. The only ways to prevent them would be to expect perfection from human developers, to stop developing and improving MediaWiki, or to stop adequately responding to security incidents. Those are all worse options.

Isn't this the third or fourth time everyone has been forcibly logged out in the past year? How is this acceptable? Why does this keep happening and who's taking responsibility to ensure that it stops happening?

Hm, why would being called autistic be considered a personal attack?

In T167547#6276349, @hashar wrote:

Can we stop using this task entirely please? It has been filed in 2017 for a project to migrate out of Gerrit to Phabricator Differential.

In T115329#5232892, @fsero wrote:

This task has been inactive for 3 years, so I'm closing it please reopen if this still needed.

This task appears to be a duplicate of at least one or more of these tasks:

Mozilla recently shut down its IRC server and switched to Matrix: https://wiki.mozilla.org/Matrix.

I appreciate the effort being made toward maintaining capability. Since 2011, I've run the "snatch" IRC bot that sits on irc.wikimedia.org and relays to the "snitch" IRC bot on irc.freenode.net.

I'm unconvinced any proposal here is paying down technical debt. Perhaps refinancing or doing some kind of balance transfer.

In the time since I wrote this ticket, I started and ended a job that had this type of betas infrastructure. It was great. When someone filed a GitHub pull request, Jenkins would automatically spin up an instance of the application and address it at https://pr-1234.beta.example.com. While project managers and other non-technical folks found the most value out of being able to see the changes in a browser easily, developers also loved having their code be automatically built and spun up and easily demonstrable to others. We really should do this for Gerrit changesets if we haven't already.

Related: T62412: ldap/wmf group should not have +2 in Gerrit. This group has been problematic for a while.

This task is a duplicate of T11201: Enable sending e-mail attachments using Special:Emailuser.

In T237503#5639828, @doctaxon wrote:

@Aklapper: Because some of these attachments are copyrighted and only for private research use. If copyrighted I must not upload the content of these attachments to MediaWiki.

In T232702#5486954, @Peachey88 wrote:

Working fine for me, Can you confirm what language you have selected in your user settings?

The problem section doesn't explain what's problematic. It describes the current situation, where we keep sessions server-side and centralized. What's the problem with this approach?

In T228554#5350841, @Bugreporter wrote:

We should have a database table storing the count. $wgAllowSlowParserFunctions can then be removed.

(Is database indexes sufficient?)

In T228553#5350672, @DannyS712 wrote:

Do you mean the number of pages in the category namespace (making this a part of T228554) or the number of rows in the category table? Also, potentially related: T37758

Thank you for the quick fix!

In T225048#5235838, @Krenair wrote:

https://wikitech.wikimedia.org/wiki/News/Actor_storage_changes_on_the_Wiki_Replicas

In T225047#5237716, @MusikAnimal wrote:

The entries in Wikipedia:Database reports include a link to the source code. I suggest we do the same for the other reports, rather than linking to on-wiki copies of the code.

It's pretty wild that this task remains unresolved. It was reported in July 2018 and we're entering April 2019 next week. Eight months!

Hi @smernst. Are you still interested in discussing this Python module?

What needs to happen to move this task forward? An e-mail to legal@wikimedia.org?

Related: https://commons.wikimedia.org/wiki/Commons:File_captions now exists.

@Aklapper: it's neither helpful nor constructive to call out "wtf" as swearing. You're quite aware of this.

When visiting which URLs?

In T204496#4829967, @Legoktm wrote:

I dumped the database of butterfly-m4m (which was using labs-vagrant, wow!) and created a new butterfly-m4m2, accessible at https://m4m.wmflabs.org/wiki/Special:Version

In T210822#4788433, @Nirmos wrote:

should it be "§" instead of an arrow?

This reminds me of T18691. Long story short: "§" does not mean "paragraph" in the broadest sense in all cultures. In some cultures, it only refers to paragraphs relating to laws.

(I'm side-stepping whether this change should have been made at all or in this fashion to answer this specific question.)

In T208315#4709703, @Aklapper wrote:

@MZMcBride: Do you plan to add more information for a completely new MediaWiki contributor to the task description, or why did you add good first task?

This task description says that "we don't actually support HTTP anymore" and @Bawolff said the same on IRC this evening. This statement feels misleading since we do support HTTP and will continue to do so indefinitely. Keeping the HTTP --> HTTPS redirects working means supporting HTTP, as far as I'm concerned.

We could also add pages to a maintenance category such as "Pages that contain non-whitelisted external images" or similar.

In T206694#4657075, @Legoktm wrote:

It's unclear to me why these problems have become so pressing that they merit shutting off l10nupdate indefinitely. We've known about them for years, but the value provided by l10nupdate has always outweighed the minor inconveniences (e.g. scap undoing l10nupdate).

I can confirm this buggy behavior on Meta-Wiki. I was able to replicate the issue described in the task description.

What's the upgrade process? I don't suppose one of us can just run apt-get upgrade or similar?

In T200987#4561556, @MGChecker wrote:

Can we please just set something up here? I would like to add patches to a queue like that for sure.

In T62740#4544330, @MZMcBride wrote:

I would really like the transclusions count at https://en.wikipedia.org/w/index.php?title=Template:Infobox_SCOTUS_case&action=info.

I would really like the transclusions count at https://en.wikipedia.org/w/index.php?title=Template:Infobox_SCOTUS_case&action=info.

Regarding the task description, is "Wikimedia's" more accurately "Wikimedia Foundation Inc.'s"?

In T29006#4466341, @Varnent wrote:

No longer applies to new site.

In T200141#4455436, @MarcoAurelio wrote:

Deployed and seems to be working as expected. Regards.

In T181070#3790237, @TBolliger wrote:

Let's keep this conversation constructive. There are a few worthwhile topics to discuss:

1. The 24-hour throttle between password reset emails
2. The UI and functionality of Special:PasswordReset
3. The proposed new functionality of passwordless login

For topic #1 — I acknowledge and agree that a throttle is needed to prevent abuse. And upon further testing, I do not believe we need to alter the 24-hour throttle because the temporary password functions for 24 hours and the throttle is reset when the password is updated by the user.

I believe that topics #2 and #3 could bring usability improvements but would best benefit from a product team (e.g. product manager, interaction designer, developers, community manager) to think thoroughly about all the requirements and corner cases, given the history and complexity of MediaWiki/Wikimedia's user account infrastructure. If David or anyone else thinks these topics are worthwhile to further explore, I would recommend they create a new Phabricator task(s) to propose these as changes to existing functionality, rather than as a defect to the current system.

In T27602#2483080, @ArielGlenn wrote:

Let me create a new task that does what I should have fixed this one up to be, and I'll add the subscribers of this one to it.

Is there a maintenance script to add a bunch of users to a user group? It seems like that could potentially be a feature within this script and might be a more common case.

Another report in the #mediawiki IRC channel just now:

I think the relationship between Wikimedia Foundation Inc. and Go Fish Digital has every appearance of being highly problematic, as I outlined here: https://lists.wikimedia.org/pipermail/wikimedia-l/2018-July/090737.html. And I don't think XML site maps are going to help Wikipedia's search engine optimization. Any discussion of improving Wikipedia's SEO has long been taken as a joke given Wikipedia's existing ridiculously high placement in Google search results. That said...

Okay, posted: https://lists.wikimedia.org/pipermail/wikimedia-l/2018-July/090737.html.

I'd really be interested to know what's potentially libelous about labeling activity such as this as whitewashing (from https://gofishdigital.com/online-reputation-management/):

Has the account approval queue been re-enabled? From the #wikimedia IRC channel this evening:

This is an old topic. If you search this Phabricator installation for "password length", you'll find a bunch of related commits and tasks. There are also wiki pages such as https://www.mediawiki.org/wiki/Requests_for_comment/Passwords and mailing list posts about this.

Related to T34138: User preference to make images tap to display.

Yessir. Thank you for noting the behavior as of 2018-06-27 in this task!

It looks like we have a generate_watchlist_count.sh script. Does that need to be re-run? If so, are @Marostegui and @jcrespo the only two who can do it or can any shell user?

I agree with what Timo wrote in T189763#4055149.

Am I understanding this issue correctly? The current behavior when a new user registers a Wikimedia Phabricator account to file a bug or report some kind of issue is presenting them with this screen?