The test plan should be:

Just try to move the method in PhabricatorDashboardPanelSearchEngine as-is

Wow, this was super-interesting

In D25660#18437, @speck wrote:

Oh I see you did confirm it’s fixed upstream. Should we just update the version we’re using?

Oh I see you did confirm it’s fixed upstream. Should we just update the version we’re using?

Since this is a third-party dependency can we check if this was fixed upstream, and that an update to phpmailer would fix this?

Swear I’ve come across this before… it might be fixed in our forked branch so I’ll take a look. Does $limit also need same treatment?

Nice!

restore newline

Thanks for the upstream link

In D25669#18389, @avivey wrote:

Don't we have something like phutil_is_integer method somewhere?

Very cool!

Don't we have something like phutil_is_integer method somewhere?

No changes; merely trying to reset "Changes planned" in Differential

https://www.reddit.com/r/ProgrammerHumor/comments/9xat04/the_ancient_code/

Obviously this is very WIP (but still works).

In D25671#18362, @speck wrote:

In D25671#18360, @speck wrote:

Agree the current non-serious language needs updated.

Though, I’d guess Phab/Phorge will actually reject these short passwords.

In D25671#18360, @speck wrote:

Agree the current non-serious language needs updated.

Agree the current non-serious language needs updated. Maybe something like,

Change commit message to reference spelling

"And complained on WMF, where this feature is disabled?" is true but misleading IMO - there was nowhere better to complain than WMF's instance since this took place after Phabricator was abandoned but before Phorge's initial release, and WMF's instance has received numerous other reports of Phabricator translation problems that were later redirected here or to old upstream.

Well, I understand why this patch completely removes that joke.

This is spelling, not formatting.

Using a password in 2024 is a bad advice in general.

And yes, I did read https://we.phorge.it/book/phorge/article/tone/ before filing this patch. You are welcome to berate me (and by extension Verdy_p on translatewiki.net, although they've been blocked there so the chance of them seeing anything you say is low) anyway.

Sorry, this isn't an upstream problem. It's an instance of the general "Phabricator lacks message documentation" problem, since nav is a bit of remarkup that niether Verdy_p on the translatewiki side nor I am familiar with. But I can handle that on the translatewiki.net side and there's nothing for upstream to do.

I upstreamed this as a largely procedural action (go through all requests for source message changes in translatewiki.net that haven't been resolved and move them up to Phorge so they can be evaluated properly rather than ignored).

Admins of any Phorge installation are free to enable serious-business if they do not like such jokes and/or assume that users in their installation would happily follow such instructions...

Read the originally requested changes more carefully

@mturdus Can you spare some time to review this diff?

In D25619#17560, @valerio.bozzolan wrote:

Maybe "feature" but note the left sidebar, is not anymore connected to the end of the viewport:

Before	After

./bin/celerity map

• Fixes non stretching nav bar if content is absolute or does not fill entire page height

@avivey that's an excellent observation.

Uh, Conduit also says Task IDs must be integer numbers. Nice. But how can I reset "Planned Changes"? Only by pushing another revision?

TODO: Check how Conduit reacts to this

Add PHPDoc; tested that return value is always plain string, also with custom logo

In D25668#18281, @avivey wrote:

need to also test the result of renderPhabricatorLogo() when no logo set, when a custom logo is set, and when a custom logo is set but hidden (maybe. Maybe the logo file should be Attached to something public, so this situation can't really happen?)

Move policy.allow-public check from method itself to calling the method

need to also test the result of renderPhabricatorLogo() when no logo set, when a custom logo is set, and when a custom logo is set but hidden (maybe. Maybe the logo file should be Attached to something public, so this situation can't really happen?)

That "don't sign a CLA" article should be titled "don't sign away your copyrights", to be more accurate and less click-bait-y. A CLA may ask you to sign away copyrights (which I feel makes the project non-open-source) ; It doesn't have to.

Note to myself: Still need to test resulting URI when a custom logo is set

Replace a call with a variable

This probably needs more work but seems to function locally.