Thanks. Have you already tried with just CSS? Any issue in that? Maybe something like this:

lol whatever, but please consider this instead to make happy also future/better versions of PHPStan

Giving this:

Double-slam-accept

Double-accept asd

Yep. In all cases it's at least a full-table-scan on file_attachment. Probably a bit more RAM-efficient with the NOT EXISTS thing since it does not need to have all file PHIDs in memory.

The title cannot exceed %d characters :D

Thanks. Also please show to the end user the same number, using some semantic pirouettes. So this limit is easier to be found.

Seems super-reasonable. Please save that 255 in a variable and re-use in pht("Bla bla %d bla", $title_max_length) or similar, so it's easier to customize without invalidating translations

Tested, makes sense, lovely feature, no possible NULL pointers since isCommentTransaction() calls hasComment() that eliminates the possibility of getComment() being NULL; no possibility to get exception "Comment for this transaction was not loaded" since that was already checked with just isCommentTransaction(); green light 🌈

Little premise, in this method the return statement is dead, unreachable code:

I like ping-pong :D

Thaaaaaaanks 🦄

This seems ready. Just the proposed inline things if you like to. Thanks.

Tested again. This feature is beautiful. Thanks again. Let's increase the Wealth token.

I do not understand this thing more than this. Help welcome.

OH GOSH YES

Tested again. Double-accept.

Triple-slam-accept

We can take inspiration from Phame (?)

It's perfect as-is. Just adding last notes since I'm in verbose mode

I thought there was a ->setFormErrors($errors) but it's not the case. Nice as-is. Tested thanks :3

Uhm. Before the change, the method returns void. After the change, the method returns void. So this proposed change would be "to make PHPStan happy" but I expect it will highlight in future versions of PHPStan as well.

Double-slam-accept

git rebase master (just because we can)

Seems good thanks. It seems we can also have it shorter with canResolve() 🤔

Please evaluate the same change also here to fix the "Pattern Search"

arc lint

Thaaaaanks, it works

Yup. Laaaand

As temporary Phorge workaround, we may want to document these email keywords rendered as "progress". So we can just manually add backtics (?)

Thaaaanks. I wonder why $has_password has a dedicated variable, and instead $has_username has not 🤔

Flagging all comments as done (but feel free to share other things)

Thanks again @speck. This is probably useful to answer your performance question:

😐

Thanks. It seems that line 17 impose edit capability. Also, appendForm() does not accept a null.

I cannot imagine any situation where the incoming viewer from handleRequest(AphrontRequest $request) could be different from the implicit viewer from AphrontController#getViewer() ($this->getRequest()->getViewer()).

In T15889#18557, @aklapper wrote:

In T15889#18536, @valerio.bozzolan wrote:

Thanks. What happens in older Apache2 versions?

Nothing. :) This issue only popped up in our error logs after an Apache update.

Ah. Maybe PhabricatorSearchHost should extend PhabricatorSearchService? Boh

I don't get this 🤔

OK. If you are partially mentioning nonsenses in we.phorge.it itself, you are indeed right.

(Wow. I've never clicked on that button in my life, also when working)

By the way I cannot reproduce in Apache 2.4.61 🤔 Debian package 2.4.61-1~deb12u1

Thanks. What happens in older Apache2 versions?

Thanks! Looking at PhabricatorSubscriptionsMuteController that works with PhabricatorTransactions::TYPE_EDGE, this seems good to me.

Setting as "new validations probably need to be managed". Thanks again

Thanks :) Interesting weird transaction.

Just that oneline

In D25736#20139, @aklapper wrote:

(Hmm should I replace $ex->getMessage() with $caught->getMessage() or not?)

So this is "just" something visible from server logs or browser console, right? It is not an error ever visible to user interface.

(Trying to make this task a bit more about the root problem, and less about the proposed solution)