• Adds map

In D25520#14909, @avivey wrote:

Thanks
also - need to run bin/celerity map before landing?

Thanks
also - need to run bin/celerity map before landing?

please make the title more descriptive of the actual change (what it's doing) - "improve usability" is very vague.
maybe "don't hide title in search" or something like that.

Tested and I like it. Thanks :3

@aklapper @valerio.bozzolan See D25520.

Uh thanks! You are now co-speaker

BTW I like the proposed screenshot. So I also agree to: feel free to share the solution 👍

My fix would work with this css class

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

In T15715#15174, @aklapper wrote:

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...

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...

If it's only for a small number of such words, they should probably just be added to the blacklist remarkup.ignored-object-names - in fact, we should probably add S3 at least as a default; And probably find a way to expose this config option. Maybe a button on the Remarkup box that will help adding things to the blacklist?

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

In T15712#15124, @avivey wrote:

Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?

Looks like the tickets end in a Wontfix in https://secure.phabricator.com/T5301; I didn't follow the whole thing, but often the reasoning in Remarkup boils down to performance.

mm, see this one: https://secure.phabricator.com/T5301#211340

Is the motivation only to allow not-magicking things like "S3" and "F1", or is there more?

Some help is needed there, testing on PHP 8.1+ and getting the right stack trace

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

Useful riepilogue for wild integers

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.

Is that something we can improve in the settings page/docs - give better instructions on this setting?

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

Done; see T15711.

@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()

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

Thanks again for this change. Please try "landing" with these two commands:

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!

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

Thanks - I did mean as an inline comment in the code but either is good.

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