I'd like to give this a shot, as part of streamlining extensions as discussed in T15568

I was thinking "out out", but only visible to admins - and then, only as a yellow notice at the top of the page:

I've explored a bit the codebase and this seems a desired non-feature.

This is a good plan. Would this be opt-in, e.g. this Phorge instance would be the main one with this on but other installs wouldn’t see this by default?

Where do you receive feature requests?

D25360 is probably the fix for the bug, but I'm not sure about how to test it yet. It's probably fine. No idea what would happen if you just re-encode a file and select an encoding...

Cool, I'll play with it and see what I can find.

Okay, I think I created a minimal example reproducing the problem. The repository is publicly available here: https://sourceforge.net/p/tinloaf-phorge-problem/code-hg/ci/default/tree/

This is also consistent with the installation notes where a toaster and other things are mentioned (since We live in interesting times).

For me, the larger observation is that because the general dependencies are aligned to the LAMP environment, an opportunity emerges for the project to be adapted as suitable for the shared hosting space. In principle, such adaptations are not dependent on removing features that support large-scale deployments on dedicated systems or more capable environments. Rather, such adaptations may simply support a greater variety of deployment cases.

Do you know off the top of your head whether the binary-detection in the commit view and the code browser view differ in some way?

To be clear - it's a single file in a single commit, in the equivalent of this page: https://we.phorge.it/rARCa604548101025875de20a9c263df3790fea425b3 - is that right?

Please understand that you are a stakeholder of interests that are just different from the current situation, and not necessarily because we don't know what we are doing :)

A git commit is a user-initiated event that may be processed synchronously. It is unclear why interaction with a daemon would be necessary to support a suitable user experience.

Another problem dramatically frequent for newcomers (at least in my office).

You should be more reluctant to make critical comments, especially as you're obviously not familiar with the project or its history (hint: it was never a commercial product).

Yeah you are describing a problem that is affected by a system administrator decision, not by a limitation of the underlying system.

I recognize that Phorge is a community effort inherited from an earlier commercial product. I am reluctant to make comments that may seem critical.

Uh thanks! Feel free to increase the "Hours invested" counter in the Task description ihih

• background tasks: Phorge needs a "traditional service" that runs forever after its startup
• databases: Phorge for scalability reasons needs 60+ databases :) :) :) circa one database for each component (like one for Ponder, one for Diffusion, one for Maniphest, etc.)

a php 8 fix

Ok, I got bored.

I understand the objections, and the realistic constraints.

I'm going to open this question's visibility, and also answer your questions here - in the hopes we can put this issue behind us.

I wish to repeat my earlier request that the issue would remain open and visible.

I don't see file F281219

ah, the original intention for the second query was "even if the diff is closed", circa 2015. Back then, it was probably not possible to update a diff owned by someone else, so it made sense to add the withAuthor..

I was finally able to read the code and understand what's going on here.
The original code is strange, and the withAuthors() part in it is definitely wrong in context.

I don't remember how to explain things to humans

Tested, works, thanks :)

I'm not sure if I understand your question.
I thought the fix was already implemented by aklapper?
What do you want me to do?

In D25021#10296, @avivey wrote:

@kwisatz maybe file a new task / re-open the old one?

Do you want an help to land this? (No problem, in case)

I think we have an implementation:

(Implementation notice: in both phorge and arc, this is handled in PhutilErrorHandler::handleError(), and the check is simply $num === E_DEPRECATED), and maybe E_USER_DEPRECATED.

I also tried going outside running:

@kwisatz maybe file a new task / re-open the old one? the screnshots are not unreadable, but if its bad enough that people complain then maybe we can find a solution.
Didn't somebody invent "webfonts" or something, so we can just package Segoe-UI and know that everyone is getting a decent view?