In D25881#24406, @Cigaryno wrote:

In D25881#24380, @aklapper wrote:

Thanks. I'm personally fine with bug fixes for prototype apps.

Me too. Maybe this section should be removed?

Did some digging using the Network monitor. When using the dialog, Phorge sends this:

__csrf__: B@jqccc7335f3e341bab747f2a
__form__: 1
__dialog__: 1
tokenPHID: PHID-TOKN-emoji-7
__wflow__: true
__ajax__: true
__metablock__: 4

but using the direct URL, it sends this:

__csrf__: B@2rdakjrtaeed9a29351d9a9c
__form__: 1
__dialog__: 1

Unfortunately, all I can gleam is that the JavaScript doesn't trigger correctly when clicking on a token, and never sends the tokenPHID key-value pair as a result. It's clearly not handling the separate form correctly, because disabling JavaScript results in a proper experience.

I haven't the foggiest how this transaction is supposed to use its stub variant; attempting to create a document at /w/parent/child causes an error about /w/parent/ being required.

This doesn't seem correct. renderObject doesn't take any arguments. I suspect the intention was renderHandle, as that method takes a PHID, which the metadata key mentions.

In D25868#23446, @slip wrote:

I found this, which suggests that this shouldn't be used for headers. https://secure.phabricator.com/D21862

Followed test plan, confirmed findings, accepted revision.

In D25859#24228, @aklapper wrote:

Yes, I'd like to see this merged, [...]

Use !empty instead of isset to match previous type juggling behaviour

Remove the mailKey column from PhabricatorPaste

In D25900#24197, @valerio.bozzolan wrote:

You know better than me the context. Is there a possibility that an installation is already without that column?

Created D25900 for the deleted paste mailkey migration.

Ran ./bin/storage upgrade --namespace phabricator_quickstart_test2, and that didn't fail.

This is much better. A few spelling errors remain, plus two suggestions to make sentences read a little less awkward.

Yes, please!

In D25859#23607, @aklapper wrote:

I took the liberty to edit the commit message a bit to make reproduction easier (handy URIs to test, plus include the error message which allows easier search).

I find the current iteration too difficult to read, although that may be partially caused by the mutual language barrier.

Took some fiddling with VS2022 to find exactly what I needed to install, but worked like a charm afterwards.

Run unit tests

• APC: Change the setKeys $ttl parameter default to 0

Confirmed on KDE on Debian 12, everything set to Dutch: LC_ALL evaluates to nl_NL.UTF-8. Fails before applying this change, succeeds afterwards.

I can reproduce this (KDE on Debian 12, everything set to Dutch: LC_ALL evaluates to nl_NL.UTF-8). diff returns localized output, but doesn't when using LC_ALL=C.

I have created T15559 with extra information, now that D25342 was closed and the issue behavior changed somewhat.