In D25505#14525, @20after4 wrote:

Is this needed simply because PhabricatorApplicationSearchController doesn't actually have a try { } block to catch this particular case? Maybe we could improve the exception handling instead of return null?

Without D25505 applied:

Remove a forgotten debug line

This is not ready for merge yet.

Indeed ideally I'd prefer to convert the current use of PhabricatorSearchTextField for an integer value to a functioning PhabricatorSearchIntField (which should return a future new AphrontFormIntControl()) instead, thus I'm reluctant to land this (though it remains a mystery to me how to set a default value (not: placeholder) in any non-dropdown field).

Replace minus dash by its UTF8 representation to pass lint

In D25479#14404, @avivey wrote:

Yeah, looks like IntField isn't doing much now (yet?). It could get setDefault() like PhabricatorSearchSelectField, plus validateControlValue()

This also needs rework because I still get a Query overheated when not being logged in and going to http://phorge.localhost/feed/transactions/query/all/

There might be room for performance improvements - currently for each $query, PhabricatorApplication::isClassInstalledForViewer is called again though some queries share the same application.

Document abstract function that it can return string|null

Also looked into very hackish $application_of_query = preg_split('/(?=[A-Z])/', get_class($query)); but the *TransactionQuery.php class naming scheme is too inconsistent, e.g. PhabricatorSpacesTransactionQuery instead of SpacesTransactionQuery (same for Slowvote, Phurl, Owners, Badges, Calendar, Packages, Paste, maybe more).

Improve performance (as proposed by Valerio)

Argh, note to myself: Simply define $hide_packages = (!id(new PhabricatorPackagesApplication())->isInstalled()); and add ->setIsHidden($hide_packages)...

I'm too stupid to see the exact optimization, performance-wise (but probably not important). :)

I can confirm that this patch fixes the string problem. However, I am super super puzzled that after applying this patch, the CSS definition line-height: 22px for .phabricator-wordmark is suddenly missing in both Chromium 120 and Firefox 120, moving the wordmark a bit higher in the upper left corner (on my two screenshots, that is "Phoriorge").

I assumed that $this->newStringIndex($value) in the next line implies a string here but let's play safe, indeed.

Right, makes sense as I do not fully know the internal logic.
As PhabricatorStandardCustomField is generic, also keep null check type-generic

Abandoning as superseded by rP1c098c273d06ea3cf8215245ea109f41c59593d9 (which first requires commandeering)

In D25419#12616, @waldyrious wrote:

Should I go ahead and submit a different patch? Or could I somehow contribute the edit to this patch?

Note that I did *not* test this locally yet; just putting it here so it does not get lost (again)

Still WIP, was just checking that nothing explodes locally (yet)

git commit --amend --author="Mukunda Modell"

Urgh, indeed not the brightest proposed patch (though it worked locally).
Also need to rework/expand patch because there are several more places in this very file to fix.
More stacktraces triggered by going to http://phorge.localhost/maniphest/ :

Also fix line 14

Hmm, I guess the patch should also change line 14 in the same way? I managed to reach that line with the same problem but do not remember the exact steps I performed...