:-)

Correct array initialization; keep line in parse().

Is that really as trivial as in my last revision?

and now for real, without #[\AllowDynamicProperties]

In D25563#16157, @avivey wrote:

Can we just define the used properties instead? Doesn't look like there's too many of them.

house-keeping...

Changing status for house-keeping.

I'd even suggest we can go one step further, and in the Home tab show the Readme above the files (and maybe change the order/highlight some other UI elements too).

Plenty of creative scope for a follow-up Diff - T15766

I agree and I'm quite sure that just parts is missing

Can we just define the used properties instead? Doesn't look like there's too many of them.

IIRC, The save() command won't generate any Feed item, so the unified feed entry would be either "xxx triaged this task" or "xxx added a comment". Also, for each comment added, a new Feed item will be generated, which is probably not what you'd like.

fix linting issues

Clone custom fields

LGTM

About your Remarkup unit tests, try to rebase. Maybe related to D25559.

Small recap:

I can confirm that the change fixes the exception locally on git master for me. Thanks!

All three changes superseded by D25250 in my understanding. If not, then please reopen. Thanks!

It might not happen on any other card, because we might not be rendering Remarkup on any other card. Interesting....

So this is quite an edge-case:

• PhabricatorMentionRemarkupRule wants to give the mention a different color, depending on if the user can view the "context object", in this case the Project.
• There's an automatic rule, saying a member of a project can always view the project
• When loading the project for the hovercard, we don't bother loading all the member list
• When loading the user for the mention, we don't bother loading all its projects
• so data is not available at the rendering point.

nice, tyty

swap cases - thanks @speck - please double-accept if this is what was suggested :D

I prefer to invert the logic and return early, to avoid having the entire function contents inside a nested level - up to you but this looks good.

simplified logic - thanks @speck

DisableUsernameEditEventListener.php is the root cause.

Another good simple candidate GDPR-friendly:

I flag this as resolved since Code Differences between Phabricator and Phorge solves the problem at the moment. Also because there are no changes in upstream since 2023.

Premising that we may want to rollback 328aee033fbd, probably this line is broken:

Ouch. Probably partially my fault. Feel free to escalate this as Task under Bug Reports - close this as obsolete then

I can't immediately reproduce with that version either. I'll try again later.
In the meanwhile:

• Try clearing your browser's cache
• Try updating Phorge to the latest commit
• Try disabling this extension: assets/DisableUsernameEditEventListener.php

Implement the actual deep clone

I can reproduce this on master with basically any string search.

https://we.phorge.it just works fine. :L

2. Phorge installation

I can't reproduce this.
Which version of phorge/arc do you have (git log -1)?
How did you install the new Instance?