Also remove unused $result array

I propose to remove that unused $result array. It's been unused before and looks we were not aware of any issues created by that fact.

Original change which triggered this: rP324470e39b0d4539a7487c2144157d686f5d0906

User content is also content, thus yes.

I'm still puzzled by the unused $result variable in line 46.

Tested locally and works in most cases, however would love to avoid creating broken (404) URIs due to T15579 before merging

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.

In D25505#14533, @avivey wrote:

How about other functions that might require a logged-in user? "current Viewer's Projects" for example?

My fix would work with this css class

I did not realize you had a fix. Please share it. :)

For parallel popcorn consumption, a slightly related (and slightly hung over) FOSDEM talk from 2015 with some shattered dreams included, from the perspective of an organization at that time: https://archive.fosdem.org/2015/schedule/event/wikimedia_adopts_phabricator/

I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...

This patch is a cleaner approach to tackle T15676 than D25479 was.
In future steps,

• T15700: An "Integer" search field could be addressed (patch available for review),
• the type of the "Page Size" field in ManiphestTaskSearchEngine.php could be switched from PhabricatorSearchTextField to PhabricatorIntTextField - see T15723: Convert "Page Size" field in ManiphestTaskSearchEngine.php to PhabricatorSearchIntField,
• an AphrontFormIntControl class could be introduced to set type="number" for the control in the HTML,
• we could introduce an overwrite validateControlValue() function in PhabricatorSearchTextField.php as in theory, future code could accidentally pass invalid data types to setDefaultValue() - see T15714: Validate PhabricatorSearchTextField value

Nah, I vaguely remember I accidentally set up something which didn't make sense and the followup PEBKAC moment when realizing but don't remember details now

In D25515#14842, @valerio.bozzolan wrote:

I wonder if it then, upon deletion of the profile image, it attempts to delete the builtin image

Abandoning my patch becaue creating a child class for each and every single field does not scale.
Instead there should be a setDefaultValue() function on a PhabricatorSearchField level to be called by the SearchEngine.

Indeed, this is invalid due to me not understanding the config settings at that time.

@jeanguyomarch: Hi, would you like to arc land your accepted patch?

My initial choice of words was wrong: It's not "duplicated". SELECT * FROM differential_difftransaction WHERE dateCreated > 1705224003; shows two transactions differing in id, phid and transactionType (differential:diff:create versus core:view-policy).

In D25419#14821, @valerio.bozzolan wrote:

I'm just unsure between implode() or phutil_implode_html()

https://we.phorge.it/source/phorge/browse/master/src/applications/repository/storage/PhabricatorRepository.php$348 got fixed by rP222a6fea0a1d9318198fe73a0501cf6444420ce3 in T15658, thus resolving

In D25515#14801, @avivey wrote:

Do we have a setup-warning about the gd extension being missing?

(see also https://secure.phabricator.com/T2378 which links D5561, D5968, D5670 for those not logged in.)

I believe I had some weird aggressive local browser cache pollution with rPaa8af1d79e8bfeb09e72d5e3b9330780e78b7aeb as I cannot reproduce the wordmark problem anymore, so: LGTM

As the patch was merged I assume that this issue is resolved. If not, then please reopen - thanks!

Is the input to parseDiff guaranteed to be UTF-8 encoded?

I'm tempted to just change that one line to $left = idx($view_data, 'left', 0); so there shoud not be a crash at this stage anymore but instead the default value 0 is passed to the DifferentialDiffQuery and to the new DifferentialTransactionView... but I lack a reproducer to check if all other code is fine with this.

PHP 8.2.14, Phorge at cc964550f945b08c64970c01a34b55314e8ef0aa

1. As an admin, check that /config/edit/user.require-real-name/ is set to Make real names optional
2. Log out of Phorge
3. Go to http://phorge.localhost/auth/register/
4. See that the Real Name field does not state Required on the right
5. Enter values into the fields Username, Password, Confirm Password, Email
6. Click the Register Account button

Reference: rPdfcccd4cb882a171d10ba8a5c2763dcc73654256

+1 on Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under Apache 2.0 or other open source licenses.

In T15582#12521, @valerio.bozzolan wrote:

clarify why the Disable User button [...] not sufficient for this purpose.

I'd like to keep this boring:
Projects are hashtags are tags. You can use them for code bases, teams, or anything you need to group.

Also, apart from the linter results, this patch should not include the changes from D25512

Also hide "Buckets" search field on diffusion/commit/query/advanced/ when Audit is uninstalled

In D25507#14682, @valerio.bozzolan wrote:

Yeah I honestly don't know if uppercase or lowercase.

manual rebase

LGTM. Tested locally and works as expected, use case also makes sense, plus this is only about public keys.

In D25390#11765, @valerio.bozzolan wrote:

if (!is_array($value)) {  // ←←←←←←←←← May be this needs to be converted to is_string($value) or similar thing

This seems reasonable since it's nonsense to me to decode an integer, or decode a float. Only decoding a string makes sense to me.

Only call json_decode() in PhabricatorStandardCustomFieldPHIDs.php on string values, instead of not calling setValueFromApplicationTransactions() in PhabricatorCustomFieldEditField.php as proposed by Valerio

Tested locally, all in all +1 but capitalization is inconsistent comparing to maniphest.custom-field-definitions: Custom Fields twice and User Profiles once should use lower-case.

Use strlen() instead of empty string check

Simplify some code / fix TODOs as proposed by Valerio

Just for the records and bystanders: All expectations described in D25503#14539 are also what the patch currently does.

Use strlen() instead of empty string check

Ideally, comments are a general things and should be kept. Also changing Tags and Subscribers etc. is generic and should be kept.

Does anyone dare to accept the last revision? :)

The updated one-liner welcomes another review :)