Is there an existing issue for this?
Current Behavior
With Xdebug enabled but no listener to connect to, the command used to check the PHP version and SAPI "fails".
|
$command[] = $phpCommand; |
|
$command[] = <<<'EOF' |
|
-r "echo json_encode(['sapi' => PHP_SAPI, 'version' => PHP_VERSION]);" |
|
EOF; |
|
$command[] = '2>&1'; // Output errors in response |
|
|
|
exec(join(' ', $command), $output, $result); |
|
|
|
$phpInformation = json_decode($output[0] ?? '{}', true) ?: []; |
|
|
|
if ($result !== 0 || ($phpInformation['sapi'] ?? null) !== 'cli') { |
|
throw new Exception\SubProcessException(sprintf('PHP binary might not exist or is not suitable for cli usage. Command `%s` didnt succeed.', $phpCommand), 1689676967447); |
|
} |
Because when Xdebug cannot connect, the output looks like this:
Xdebug: [Step Debug] Could not connect to debugging client. Tried: …:9003 (fallback through xdebug.client_host/xdebug.client_port).
{"sapi":"cli","version":"8.2.27"}
Note the expected JSON is now in the second line of the output (instead of $output[0]), so the check fails, even though $result is 0.
Expected Behavior
The Xdebug output is a warning, and, well hard to suppress, unfortunately. But it should not stop execution of the code… especially since warming up Flow from the CLI works just fine and also subsequent browser requests do work.
Steps To Reproduce
- Activate Xdebug, set
xdebug.start_with_request=yes (as is default in DDEV)
- Do not listen for debug connections
- Call Flow from a browser, with empty Flow caches
Environment
- Flow: 8.3
- PHP: 8.3
- Xdebug: 3
Anything else?
- A way to solve this would be to not redirect stderr to stdout? No, that Xdebug output is not sent to stderr.
- Unset the
subRequestEnvironmentVariables to get rid of XDEBUG_CONFIG? No, with xdebug.start_with_request=yes that doesn't help.
Is there an existing issue for this?
Current Behavior
With Xdebug enabled but no listener to connect to, the command used to check the PHP version and SAPI "fails".
flow-development-collection/Neos.Flow/Classes/Core/Booting/Scripts.php
Lines 939 to 951 in 57bc20b
Because when Xdebug cannot connect, the output looks like this:
Note the expected JSON is now in the second line of the output (instead of
$output[0]), so the check fails, even though$resultis0.Expected Behavior
The Xdebug output is a warning, and, well hard to suppress, unfortunately. But it should not stop execution of the code… especially since warming up Flow from the CLI works just fine and also subsequent browser requests do work.
Steps To Reproduce
xdebug.start_with_request=yes(as is default in DDEV)Environment
Anything else?
subRequestEnvironmentVariablesto get rid ofXDEBUG_CONFIG? No, withxdebug.start_with_request=yesthat doesn't help.