Could you try arc land instead of git push?

Many thanks for your patience. you're very kind!
but I do have trouble landing this diff.
not sure what I'm doing wrong.

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

arc lint

I skiped the linting and unit testing because they take time to process. too much for this tiny change

Too lazy, just doing the same as in rP43d3fd9eac6e8e44d8a60110d8ad6f01bb240979: Turn "Required" red after the first attempt

Rebase after merging rP59678094fb777aed3c3eb66e8075c082b3dc393f

Replying to a comment in Z1 from a week ago: When Phorge's curtain doesn't allow someone to access the content, it shows either a 404 ("Access Denied: Restricted Maniphest Task") or the login dialog. In both cases, no OGP meta tags are leaked.

Thaaaaanks, it works

Same results as Valerio after testing more. Also remove unused vars $title and $header_name - they are unused.

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?