Yup. Laaaand

The $password variable is not a string anymore in the line after. I guess it's not much more expensive to check if the string $username is nonempty versus comparing to a boolean value

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

Quick notes:

• For testing code changes, make sure to ./bin/cache purge --caches remarkup
• rPcc44ae32c546: Remove obsolete "setDisableMacros()" on "PhabricatorRemarkupControl" once upon a time existed, could provide a base
  • But how to even realize/pass the info that we are rendering strings in a documentation context?
• PhutilRemarkupRule has a isFlatText($text) method but no setFlatText(true) method
• PhutilRemarkupSimpleTableBlockRule::markupText() is handling our $cell which has the meme/macro name as its only string content
• Afterwards, PhabricatorMemeRemarkupRule:apply() is the next step being called

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.

I think line 392 should be:

Not sure if @20after4 has any opinions on this? :) For the records, the code looked like this before this last change: https://we.phorge.it/source/phorge/browse/master/src/applications/config/check/PhabricatorMySQLSetupCheck.php;a41d158490c0cd0a0454653473c39f7ad2b5954f$381-384

Ah. Maybe PhabricatorSearchHost should extend PhabricatorSearchService? Boh

I don't get this 🤔

My userbase is stellar in relentlessly clicking every button you provide them :P

In T15889#18536, @valerio.bozzolan wrote:

Thanks. What happens in older Apache2 versions?

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.

This happens because if ($continue_on_missing && $error->getIsMissingFieldError()) in https://we.phorge.it/source/phorge/browse/master/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php$1248 is true.

Five months later it seems that we survived. Anything left to do?

We might come from different user journeys.
Your users might be aware what the project means, and that the project (and its workboard) is archived, and they do have an initial reason to look at this archived workboard (e.g. default view is not "open tasks" but "all tasks")?
My users clicked an external link to some project tag in something called Phorge, and that project has been archived in the meantime, and that project is set to show the workboard by default, and that is now just empty columns (as the default view of workboards is "open tasks"), and that is confusing and unhelpful.

Skip assigning variable; direct return

Just that oneline

Would anyone be willing to give this another review? :)

Use $caught, not $ex.

• Use $caught, not $ex.
• Include Herald rule monogram in log message for easier finding.

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

Yep thanks

In D25736#20139, @aklapper wrote:

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

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

Correct, the end user will not realize without opening the network tab of their web browser's developer tools.
However, as a downstream admin, I look at statistics/dashboards of HTTP 4xx and HTTP 5xx errors. When the numbers are not very low I'd usually assume something goes wrong and should be investigated. But that is not the case when Phorge throws a "silent" HTTP 400 for no obvious reasons.

Ahh but Transcripts do render an exception when it fails at least. I get a HeraldInvalidConditionException printing Invalid Condition: Condition references a rule which does not exist!, triggered in HeraldAdapter::doesConditionMatch() (only if you reach that condition in the evaluation of course, because https://we.phorge.it/source/phorge/browse/master/src/applications/herald/engine/HeraldEngine.php$437-445 ).
That's called in HeraldEngine in the line $is_match = $adapter->doesConditionMatch (note that class also has a method with the very same name).

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)