Thanks for staging this @valerio.bozzolan

6 year old in-your-face unreported bugs like these make me wonder how many people use Phabricator/Phorge :-(

It's not many, but this issue would be specific to anyone using Phabricator/Phorge for PHP development, which is likely Phab/Phorge itself is close to 100% of that market. And Phab/Phorge also itself has its own unit testing framework instead of PHPUnit.

What do you think about keeping the current naming scheme but whitelisting a handful of query params to use instead of using them all? The timestamp adds noise and it's probably nice to see the ID of the diff in the filename, e.g. D25478.id1541.diff? Maybe just allow the the id parameter and regex that it's value is just a string of numbers.

Sorry for the delayed review

Oh interesting

This already has been accepted. I think @Matthew 's old request for changes is what is keeping this from being landable right now.

As I just ran into this again spinning up another machine and had to look this up again, I'd really appreciate if a Blessed Committer could give an "Accepted" state. Thanks in advance!

so something like this might work?

can't repro anymore, looks like the regression regressed

In D25479#13937, @avivey wrote:

maybe use an PhabricatorSearchIntField with a default provided in the buildCustomSearchFields() ?

In D25482#13939, @speck wrote:

Was this the result of a recent change?

Was this the result of a recent change?

If you can hop on IRC/Conpherence in about 4 hours (around 20:00 UTC), I can try debugging this interactively.

maybe use an PhabricatorSearchIntField with a default provided in the buildCustomSearchFields() ?

mmm, ok.

In T15676#14475, @avivey wrote:

What kind of operation are you doing that involves loading all tasks in a browser?

What kind of operation are you doing that involves loading all tasks in a browser?

I'd really prefer not to do that. I pretty often need to work with complete search results (e.g. batch-editing), not with only the first 100 and then repeat all steps for the next 100.

If this is the only place where we have a "limit"/"page size" field, maybe just remove it?

Can someone change ...

In D25479#13906, @avivey wrote:

Is this the only place where we have a "Page size" exposed in the search?

Is this the only place where we have a "Page size" exposed in the search?

Let the Purge begin!

In D25388#13885, @avivey wrote:

In D25388#13843, @Matthew wrote:

I like renaming the function!

We should probably have a timeline for removing the old function. Do we have a task for that?

I feel like that kind of task will just fall down into oblivion....

• rm commented out code

In D25388#13843, @Matthew wrote:

I like renaming the function!

We should probably have a timeline for removing the old function. Do we have a task for that?

Hmm I guess the Test Plan should also cover testing with Conduit. Not sure this may shake something up.

When a phriction markup page is generated , its synchronous, when a diffusion markup page is generated it's asynchronous.
This is going to take a bit of thought.

Another option would be to extend the class PhabricatorSearchTextField and make the new class PhabricatorSearchPageSizeField only overwrite function getDefaultValue(), however class PhabricatorSearchTextField is marked as final and I am reluctant to change that.

In T15671#14420, @avivey wrote:

The feature was removed for performance and private concerns. I thought Gravatar was alread dead.

Maybe this can be done as an extension:

• Abstract the "profile picture provider"
• Allow an extension to write a Gravatar one

There are currently 2-3 sources, so maybe there is some abstraction:

• pokemon-style silhouette
• Character with background (generated from username)
• Upload Picture

I like renaming the function!

1 comment...

The feature was removed for performance and private concerns. I thought Gravatar was alread dead.

I aslo don't see the point of this feature, but that's another issue.

I don't see the point in having this feature. What is it for?

Should this be configurable and behind a feature flag, as some Phorge installations may not want this (plus may slow down performance a little bit)?

This code change adds a small star to handles of new user accounts:

Fix variable names

Obviously, any fixes should be in ManiphestTransactionEditor and not spill into generic parent PhabricatorApplicationTransactionEditor.

Historical references: rP69eab4196de462e42b07b60e2b52071631f4a3c8 and rP4041a7e0f66406dbaa31faa3807d50833b7c7efd (which didn't help much).

• update some copy

• cleanup

Extending this task to include support for PHP 8.3 which is due to be released today.