Correct array initialization; keep line in parse().

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.

LGTM

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!

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.

Would anyone give this another review? Might make sense to apply the one-liner in D25527 to have a simple test case on the Maniphest Advanced Search page

On the other hand, as the variable is called $html_details let's go for phutil_implode_html() to be super-safe? ping @roberto.urbani

In D25546#15665, @valerio.bozzolan wrote:

I also don't get if in this part we have access to any thing related to Maniphest, ManiphestEditEngine or this kind of stuff, to just call $something->getCommentPanelPlaceholder() and have the business logic there in the specific application itself.

I assume we should change strpos("\0", $value) to strpos($value, chr(0))

In T15670#16064, @valerio.bozzolan wrote:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

refactor as recommended

Thanks, this is way cleaner (and slightly more performant) than my D25476. I've tested this locally, also in combination with other actions (e.g. opening another action field without changing it) and behavior is as expected.

Superseded by D25550

Would you like to go to court to defend that statement? :)

I could not sign it if it required brushing three times a day. Removed purely due to egoistic laziness reasons.

Well, I would rewrite quite a bit, so I'll post a draft here before editing directly:

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

As Wikimedia uninstalled Differential I cannot further debug in downstream.
We can either decline the ticket and its patch for now (if someone runs into this again, they could reopen or file a new task), or could get the patch in (setting a default value) without a test plan to have more robust code. Shrug.
Opinions? :)

As Wikimedia uninstalled Differential I cannot further debug in downstream.
We can either decline the ticket and its patch for now (if someone runs into this again, they could reopen or file a new task), or could get the patch in (setting a default value) without a test plan to have more robust code. Shrug.
Opinions? :)

Cannot reproduce (or I misunderstand the steps):

1. Created https://github.com/aklapper/emptyrepository for testing
2. Went to phorge.localhost/diffusion/edit/form/default/?vcs=git and created emptyRepo.
3. Went to http://phorge.localhost/diffusion/26/uri/edit/208/ and set URI's I/O Type to Read Only
4. Went to http://phorge.localhost/diffusion/26/uri/edit/ and set URI to https://github.com/aklapper/emptyrepository and I/O Type to Mirror
5. Went to http://phorge.localhost/owners/paths/1/ , edited/removed existing path by setting it to: Include R26 emptyRepo / , and clicked "Save Paths"

Second issue got already fixed by rPa7fb04f96c92d4ff57ac8c01213e6dd73a03f5d6 which wasn't linked to this ticket

@jeanguyomarch: If you could provide stacktraces of these issues, that would be awesome.

First part is D25483

In T15121#3880, @valerio.bozzolan wrote:

I don't think that the author should ever allow to re-license its work. [...] Normal volunteers do not accept that.

Clean up my local testing mess

Most phurl.io short URIs point to old upstream tasks. The two related patches make the code at least point directly to these tasks (to still be found on https://web.archive.org/ if secure.phabricator.com ever went down) as there's no direct content equivalent on phorge.it.

@valerio.bozzolan Are there any prehistoric traces that this extension has been successfully used in the past? :P

Makes sense, thanks everyone. Let's decline for the time being.

Interesting. What's the use case you have in mind?

In D25079#15507, @valerio.bozzolan wrote:

https://we.phorge.it/T15178#4880

I guess I'm fine with adding that mp3 file.
I am personally not convinced by the creation of src/docs/flavor/project_credits.diviner: I've seen way too many "let's create some list, with best intentions, and at some point unfortunately forget about updating it" examples in FOSS projects. Every added line in software projects creates additional maintenance costs (and in some cases bitrot); human resources are in theory unlimited and in reality rather sparse.
Credits could go into the git commit message, maybe?

See discussion and reasons in https://secure.phabricator.com/T11833