(Re-adding Conduit as a non-subproject Tag since we have 5-6 tasks about it)

This is probably not so simple. Doing that change causes this problem:

Somehow "Normal" in 2023 I think - at least in Maniphest. But probably not so important.

This is a nice contribution and definitely would be a valuable addition to the docs, IMO.

I honestly have nothing more to be done here. I would like to set as resolved but there are sub-tasks opened

In T12071, @epriestly mentions that individually selecting env-vars to copy "build[s] some resistance to "Shellshock" class vulnerabilities", which is kind of a compelling argument.

Ok, looks like my personal install is missing $HOME as well, so I can probably try to reproduce.

In any case, it should be generic - on "search results page", although probably requires each SearchEngine to define the available fields in order to actually support this feature.

Yep that is my current workaround. Premising I pretty damn like the current export engine in Maniphest. It should not be that impossible to replicate to Projects as well.

You can already "export" to json from the conduit. Maybe "teach conduit search methods to produce csv" would be a better solution.
Alternatively, an external script to convert the resulting json to a csv.

In T15188#9488, @speck wrote:

It looks like upstream just straight-up removed the call to utf8_decode() in the master branch: https://secure.phabricator.com/diffusion/ARC/browse/master/src/utils/utf8.php$290-292

It looks like upstream just straight-up removed the call to utf8_decode() in the master branch: https://secure.phabricator.com/diffusion/ARC/browse/master/src/utils/utf8.php$290-292

Fixed thanks aklapper

@valerio.bozzolan F267558 in the task description is not attached, thus it cannot be seen by others.

Premising I am trying to make few variations to the current behavior implemented by Evan

Tagging also as Affects Wikimedia since during Wikimedia Hackaton I've talked with a couple of very friendly staff members from WMF-CiviCRM that would really love this thing.

I discovered this while testing this patch: D25216: Fix PHP 8.1 "strlen(null)" exceptions setting up Username/Password Authentication Provider

So apparently this is not a problem in the unit test itself but just with T15375

I was probably able to reproduce the issue:

The title maybe should be "Allow not to diverge too much only to allow hardening with open_basedir"

I don't see a reason to open it. If you know what you're doing and want to enable this feature, you can just change the code locally.

By the way the only usages are:

Yeah no problem!

In T15368#8316, @valerio.bozzolan wrote:

Hi @aklapper. Are you affected by this as well?