I'd still not expect it to actually break anything - the docs say this const is "deprecated" not "removed", so I'd expect a warning and everything to keep working.
maybe something in the lint pipeline is dumping the warning on stdout instead of stderr.

1. see parent task
2. This wouldn't actually help the described use-case anyway.

(see parent task - I'm against this).

It kind of makes sense.
maybe some day we'll need to extract the Identity table to a different place.

To put it another way:
I think the described use-case is too narrow, and a naive expansion of the use-case isn't scalable.
The described use-case fails for at least one possible use-case ("some bots have something useful to say").

Yes, this is where my first comment enters - I feel this is a rabbit-hole we shouldn't venture into, etc.
The current script appears to have 3 names, and referring to "legacy data" implies that there won't be any new names to add.

the legacy data can be handled by the already-existing hard-coded names...

I feel this is a rabbit-hole we shouldn't venture into.
The slippery-slope argument will make us adding a custom class for each individual user, so css extensions can be used to hide/highlight comments from boss/intern/etc.
It's also probably not enough to remove the hard-coded requirement either - in some environments, one "bot" user is copying comments from another platform, and another is making statistical updates about a jira ticket, so you'd still need a better filter.

In D25984#26354, @valerio.bozzolan wrote:

Should we phlog($e) in your opinion?

Re "implement in php" - AFAICT, there's no built-in support for websockets in php, but I found at least 2 pure-php implementations out there that might work.

In J6#66, @Cigaryno wrote:

Thanks for this! Is this any related to the security vulnerability warning I got with npm install last month, which prompted me to run npm audit fix?

Possible ways to reduce risk for future issues:

• add a Setup Check that runs npm audit
• remove node, use php-based websocket implementation

@aklapper want to land this?
I figure users need to just run npm audit fix to be safe, and then fix the mess it did on the git diff.

1. Can we specify the .10 in packages.json itself?
2. Do installs need upgrade instructions to complete the upgrade?

As a general rule, I prefer the have the abstractions as much as possible, to allow extensions to do things.
In this case, an abstraction would also make this feature easier to enable/disable, which I think is desired.

All these options make me want to just go with Sprites (See "Tokens" and "Authentication" in https://we.phorge.it/uiexample/view/PHUIIconExample/).

That's almost a year old. Time to update.

In D25966#25761, @mturdus wrote:

In D25966#25739, @bekay wrote:

First of all: you should create the copy button server side. Ideally inside the remark rule for creating a code block. There you can attach the ressources too. And you can add sigils to the button. Javelin uses sigils to attach behaviors and listen to events.

I'm still creating the button via javascript because if I do if on server side I may break some remarkup unit tests ...

Sure, 7 years is probably long enough to migrate cookies.

Looks good, yeah.

So, this turns out to be a lot harder than I thought.

There might be some security implications to this.
Why is this needed?

I don't understand the problem described...

I'm not familiar with MediaWiki's packages - the model I'm copying is VSCode.
My thought is that in the install manual we'll say "now run ./bin/extensions install phorge-recommended-extensions" (near the ./bin/storage) step, and phorge-recommended-extensions would be the equivalent of "extension pack" hosted on the default Extension Store, which is hosted here.
(VSCode also has "bundled extensions", which I think doesn't work for us because we use "clone the repo" as the primary distribution system).

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

Really!? Phacility SaaS instances do not allow enabling prototypes and self-hosted Support (from the Support application on admin.phacility.com that was oddly marked as Prototype) likely wasn't even available for prototype applications.

On this server, we changed the config to /^(Q|V|M)\d$/ because we don't have P1 tickets.
I'm also not sure what M is short for.

To me, "obsolete" manes "no longer appliable" - basically, "the information in this page doesn't apply any more".
Some (made up) examples:

• "Can Phorge run on PHP 7.0?" (The answer is no, because of a specific bug in 7.0, which was EOL a long time ago)
• "I have this problem in the Chatbot app" (We've deleted the chatbot app)

The V123 syntax is disabled by remarkup.ignored-object-names config by default; The default is /^(Q|V|M|P)\d$/ (basically anything starting with Q, V, M, or P and only having one digit), for "Q1" (biz-talk for April), "V1" (for versions), "M1" (for ?????) and "P1" (Jira for "important bug").

My thought on this is that long term, we'll remove the concept of "prototype" completely in favor of Extensions.
The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

@Cigaryno please create a task under Discussion Needed for this - I'm not sure we want to make this policy change.

Do we have a task to remove this file from source-control?

close enough for my taste; Just add . at the end of each sentence.

• There's already a "description" field on these, which I think was supposed to be displayed; We might have lost it at some point, which is concerning.
• Use pht() for all human-visible text, to allow translation.

Need to go over the relevant code for deciding if a commit has an approved Revision - I think it looks mostly on the commit message.

See also https://secure.phabricator.com/T1751 and rARC3116d3656ad017783e75df7e863368053d753e7f - looks like we had arc backout at some point for this, but it's no longer there.

try now

@valerio.bozzolan go ahead and give it a try? I think you have access to create rules.

I've deployed it (https://www.phorge.it/)

I'd like people to clone from GH less for the bandwidth and more for the availability - GH is more likely to be up then us.
Technically I guess GH might have an issue with that, but they probably won't notice anyway.

https://secure.phabricator.com/T13105 is the relevant historical meta-task, I didn't find a matching one here.

Oh, I miss-understood the problem statement. The 4096 limit is on the size of the image that we can resize from...

I'd expect it to just resize the image as needed....

two items re: phrasing, but otherwise LGTM.

I've set can create to Trusted Contributors for now. I don't see a problem with people being able to create documents.

If the goal is to make it denote "inserted text", I think it should be visually different to "underline" - something more similar to the green we use for actual diff views, maybe more subtle. Will need special handling in the color-blindness themes.

The "Grant permission" button works for me on Chrome/Windows.

I think that for the "the name I use is not my legal name" use-case, I'm pretty sure it's fine to use the name that is actually used (because that's what the person is normally known as). It's probably easier to justify accepting a name that is used in real life then "internet handle", but ㄟ( ▔, ▔ )ㄏ

In T15121#20192, @BlankEclair wrote:

Would the CLA have to be signed with one's legal name?

(we can probably keep this ticket open, so that we have the 2nd part on the backlog. I'm pretty sure we want it to happen "eventually".)

Sounds reasonable.

"Steal credit" might actually lead to a real issue: If a new user can get themselves identified as an old, trusted, user based on commit history, their changes might not be checked as rigorously by the rest of the team - similar to the XZ Utils backdoor issue, only faster.

Please "remind" me about this ticket as often as possible, so I will fix it. I have everything I need to actually fix this, except the willpower.