The patch is already approved but maybe it's nice to bring more attention to extension developers

Again, expanding a PhabricatorFileAttachment to support a destruction engine to post-pone its destruction does NOT work as intended (as it's still destroyed very after the file) since the destroyObjectPermanently() is always supposed to be executed BEFORE the extensions.

OK I've explored the proposal n. 1 about expanding PhabricatorFileAttachment to support PhabricatorDestructibleInterface, but I'm just moving the problem there. The attachment is still immediately nuclearized BEFORE the extensions can do things.

When you destroy a PhabricatorFile, it seems this happens:

It seems it's necessary to be able to "get the user from a profile picture". This is not easy, since the user seems not mentioned in any obvious way from the file object, as already stated in T15407.

Thanks for the comments. For context (which I should have included initially), this task was borne out of a conversation between me, @aklapper and @valerio.bozzolan about which parts of a downstream hack I was working on (https://phabricator.wikimedia.org/T393289) could be useful upstream. If the answer is "none", I can live with that.

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

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

I have not a strong opinion about author usernames (T16052) but if you say to decline that makes sense, especially if at least as small compromise we simplify bot recognition, T16051 and D25987, so that local installs can rewrite their UX without completely nuking their past history and doing complicated comment→transaction migrations on past data.

I suggest testing by setting window width = 1791px (e.g. CTRL+shift+M on Firefox), and then passing to window width = 1792px. So we can see that the content max width at the moment always seems ~ 800px.

Uhm - but looking at your screenshot, at looking here T15920, it seems a regression

Patch welcome, with "Ref T15920"

When reading the wiki at a resolution of 3440x1440 (34 inch monitor), there is still a lot of white space.

Feel free to throw the patch as-is, as I usual I love to cleanup and test more loool

I have a patch ready, need to clean up and test more

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").

Personally I'd decline T16052 (data duplication) and I do not yet see a need for potential new transaction types either (a comment is a comment is a comment no matter who/what made it).

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.

If you mean this kind of hardcoded CSS rules, yes, it's possible for local installs:

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

Yessss, I agree and we explored a bit the creation of new transactions as good long-term direction, unfortunately it seems still necessary a bit of CSS help from the backend to cover the legacy data (e.g. 10 years old bot-generated comments, with traditional comments)

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.

P.S. I wonder... what happens if we expose the width/height here. But probably just touching that would be enough. Still, patch welcome 👍

Thanks. Yes. I can reproduce. Relevant documentation:

Thanks. I also encourage in not following the mentioned implementation, and not only because they have problems with deleted files (interesting) but also because that solution is verticalized on Wikimedia Commons, and nowadays a "modern" embedder system should probably just use the OEmbed protocol that is quite flexible and would support out of the box an incredible amount of websites, potentially including Wikimedia Commons, with relatively few amount of code, than supporting every single website in the universe.

Triaged this as normal as I don’t think it’s anything urgent, but I personally love it - very helpful when you have lots of files! LGTM in principle.