DisableUsernameEditEventListener.php is the root cause.

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

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?

Interesting. This cannot be reproduced here in this website https://we.phorge.it? isn't it? I think no

:p

(Please edit file Visibility to make them Public :D It's another bug ihih - thanks! <3)

The exception throw out when I search text in search bar:

Please also include your exact search. I think you are searching by https://foo and that is unfortunately not possible without "doing this"

Ouch

Also note that we have a similar PhabricatorDataNotAttachedException in PhabricatorRepositoryCommit (via getRepository()) in downstream https://phabricator.wikimedia.org/T360714. It's without reproduction steps but sounds a bit similar.

Yeah sorry. That exception also occurred to me, before this change: https://we.phorge.it/transactions/detail/PHID-XACT-TASK-tuchgj42nb2ujtc/

I could not even reproduce but get an informative error instead:

Thanks avivey. Added this:

Look into the "is creation xaction" - we had a similar diff recently about creating Revision from raw diff that had a similar behavior.

Maybe unrelated. But after we fix PhabricatorCursorPagedPolicyAwareQuery, maybe we will find a crash test also for the first two lines:

Interestingly I was able to reproduce, but only creating 101+ tasks manually and going to the next page. So after that ?after=100 is introduced.

Heck yeah, changing phutil_nonempty_string() to phutil_nonempty_stringlike() there fixed the issue I had mentioned in a comment in T15737: Include information for installing required PHP version in Diviner docs.

I'm triaging as "wishlist" for now, but realistically - I don't believe will ever reach a point where we'll try to fix this -- see https://secure.phabricator.com/T13154 for discussion.

can confirm, https://we.phorge.it/D25342?id=1111 does show an error for me in an incognito window.

Probably, something should "Attach" these files by default to that Diff, during the upload phase.

A workaround is to make all files as "Public". I fixed for example the diff D25079: Trigger: Add Sound "Coin" by setting the audio file F1271256 as public.

Old upstream WONTFIXed this in https://secure.phabricator.com/T13154

Note that at least for Phame, http://phorge.localhost/J1 seems to always redirect to http://phorge.localhost/phame/post/view/1/blogpost/ instead of keeping the monogram in the URI.
So the baseURI is already wrong (not being http://phorge.localhost/ only) before concatenating the $ref (monogram and anchor).
As an ugly workardound, could probably make "Quote Comment" work by calling getObjectNamePrefix() in PhamePostRemarkupRule and LegalpadDocumentRemarkupRule and then use them in a preg_match to remove the monogram from the $ref but function is protected and... still ugly.

Can you try changing this line in your local install?

can't repro anymore, looks like the regression regressed

Other edges have probably been eliminated in the past. For example this one:

Is this only related to the "Authored on ..." field, as far as you can see?

I cannot reproduce anymore. This does not happen anymore in latest master.

Interestingly I was able to reproduce the issue with this nonsense patch, in the hope to emulate an email plain-text generation, even if it's not the case:

For interesting reasons, I cannot, in any way, get an email about somebody renaming a single Mockup photo. And, my email preferences are like "email me for everything from every application" and email delivery is "email me about myself".

Initially, the task is in the project's default column:

MariaDB [phabricator_project]> SELECT cp.id, p.name AS projectName, cp.boardPHID, c.name AS columnName, cp.columnPHID FROM project_columnposition cp INNER JOIN project_column c ON cp.columnPHID = c.phid INNER JOIN phabricator_project.project p ON cp.boardPHID = p.phid WHERE objectPHID ="PHID-TASK-f6ri2kdpcvtb3yncho2n";
+-----+----------------+--------------------------------+------------+--------------------------------+
| id  | projectName    | boardPHID                      | columnName | columnPHID                     |
+-----+----------------+--------------------------------+------------+--------------------------------+
| 509 | T139396-parent | PHID-PROJ-yt43plz2cxlidyu4dlia | Backloggg  | PHID-PCOL-no7jbin6vngwkrghrmrk |
+-----+----------------+--------------------------------+------------+--------------------------------+

In T15653#13929, @valerio.bozzolan wrote:

Yeah so we are all for "let's just append as default and maybe think about something more for the future, if they ask"

Yeah so we are all for "let's just append as default and maybe think about something more for the future, if they ask"

What if it were possible to intentionally remove a tag by passing the tag prepended with - to signify removal? like ?tags=-ABCDE to remove a tag but otherwise the behavior would be to just append. I realize this doesn't have the same compatibility advantages but it does offer slightly more flexibility for use in ad-hoc workflows.

Thanks for reporting.

I've probably understood what is going on here

Triaging to "Unbreak Now!" so to be kindly shown in the homepage :)