I am using Yii2 with Firebird and a quite old Yii2 plugin for the Firebird https://github.com/edgardmessias/yii2-firebird.
I have no errors during runtime, but Xdebug session stops with:
Deprecated: Return type of edgardmessias\db\firebird\PdoAdapter::beginTransaction($isolationLevel = null) should either be compatible with PDO::beginTransaction(): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice
I have tried to ask not to report deprecation error messages both in index.php:
<?php
// comment out the following two lines when deployed to production
defined('YII_DEBUG') or define('YII_DEBUG', true);
defined('YII_ENV') or define('YII_ENV', 'dev');
// Suppress deprecation warnings in development
if (YII_ENV === 'dev') {
error_reporting(E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED);
}
require __DIR__ . '/../vendor/autoload.php';
require __DIR__ . '/../vendor/yiisoft/yii2/Yii.php';
$config = require __DIR__ . '/../config/web.php';
(new yii\web\Application($config))->run();
And in the project's .vscode/launch.json:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Listen for Xdebug",
"type": "php",
"request": "launch",
"port": 9003,
"runtimeArgs": [
"-d", "error_reporting=E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED",
"-d", "display_errors=1"
]
},
{
"name": "Launch currently open script",
"type": "php",
"request": "launch",
"program": "${file}",
"cwd": "${fileDirname}"
}
]
}
But still - my project runs smoothly when requests are made without Xdebug session and the mentioned error stops everything if Xdebug session is active.
As suggested, I used code to capture xdebug_output during the debug session:
ob_start(); // Start output buffering
xdebug_info(); // Capture the output of xdebug_info()
$xdebugOutput = ob_get_clean(); // Get and clean the buffer
// Log the captured output
error_log($xdebugOutput);
And the capture was:
Directive Local Value Master Value Docs
xdebug.cli_color 0 0 ⊕
xdebug.client_discovery_header HTTP_X_FORWARDED_FOR,REMOTE_ADDR HTTP_X_FORWARDED_FOR,REMOTE_ADDR ⊕
xdebug.client_host localhost localhost ⊕
xdebug.client_port 9003 9003 ⊕
xdebug.cloud_id no value no value ⊕
xdebug.collect_assignments Off Off ⊕
xdebug.collect_params On On ⊕
xdebug.collect_return Off Off ⊕
xdebug.connect_timeout_ms 200 200 ⊕
xdebug.discover_client_host Off Off ⊕
xdebug.dump.COOKIE no value no value ⊕
xdebug.dump.ENV no value no value ⊕
xdebug.dump.FILES no value no value ⊕
xdebug.dump.GET no value no value ⊕
xdebug.dump.POST no value no value ⊕
xdebug.dump.REQUEST no value no value ⊕
xdebug.dump.SERVER no value no value ⊕
xdebug.dump.SESSION no value no value ⊕
xdebug.dump_globals On On ⊕
xdebug.dump_once On On ⊕
xdebug.dump_undefined Off Off ⊕
xdebug.file_link_format no value no value ⊕
xdebug.filename_format no value no value ⊕
xdebug.force_display_errors Off Off ⊕
xdebug.force_error_reporting 0 0 ⊕
xdebug.gc_stats_output_name gcstats.%p gcstats.%p ⊕
xdebug.halt_level 0 0 ⊕
xdebug.idekey no value no value ⊕
xdebug.log no value no value ⊕
xdebug.log_level 7 7 ⊕
xdebug.max_nesting_level 512 512 ⊕
xdebug.max_stack_frames -1 -1 ⊕
xdebug.mode debug debug ⊕
xdebug.output_dir C:\Windows\Temp C:\Windows\Temp ⊕
xdebug.profiler_append Off Off ⊕
xdebug.profiler_output_name cachegrind.out.%p cachegrind.out.%p ⊕
xdebug.scream Off Off ⊕
xdebug.show_error_trace Off Off ⊕
xdebug.show_exception_trace Off Off ⊕
xdebug.show_local_vars Off Off ⊕
xdebug.start_upon_error default default ⊕
xdebug.start_with_request yes yes ⊕
xdebug.trace_format 0 0 ⊕
xdebug.trace_options 0 0 ⊕
xdebug.trace_output_name trace.%c trace.%c ⊕
xdebug.trigger_value no value no value ⊕
xdebug.use_compression 0 0 ⊕
xdebug.var_display_max_children 128 128 ⊕
xdebug.var_display_max_data 512 512 ⊕
xdebug.var_display_max_depth 3 3 ⊕
I don't see what I can change and how.
The good news is that deprecation errors are reported during the debug session and the execution pauses, but I can continue the debug session with F5 and hence this is not blocking issue, however it is not nice to go through those steps every debug session.
This is wrong:
// Suppress deprecation warnings in development
if (YII_ENV === 'dev') {
error_reporting(E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED);
}
Correct is to configure such settings where they belong to, that is the launch configuration. You do not need to wrap that in PHP code then.
And you already have that as the configuration in JSON Text shows.
That is the right place, well done!
The development environment you need to be able to configure as easily as possible, do not plaster your code with conditional checks of a flag here or there, you control the dev environment already. Stay in control.
Now the second point why that is wrong, is that you suppress diagnostic messages during development where you want them. If development is using the wrong PHP version, then use the right PHP version. If you want to develop for the upgrade of the upcoming PHP version (on that project), you want to have all the diagnostics.
Additionally as your example shows, the diagnostic messages are not the concrete problem you have. What bites ("bytes") you is that the debugger halts whenever an error happens.
That is a different configuration, specific to XDebug (not the PHP error reporting that is for logging and "display errors"). Both not your problem, but the error/exception breakpoint with XDebug.
The extension you make use of in your code editor seems to have them enabled automatically.
You have not shared the name of the extension, so it is a bit a shot into the blue, but perhaps it is "xdebug vscode-php-debug" and this thread (" Option to disable automatic exception breakpoints, break only at explicit points #56") may already shed some light. It has screenshots and all the blows and whistles.
Disable all exception / error breakpoints and you can focus on the breakpoints you're currently looking for.
For reference: DBGP 7.6.1 breakpoint_set EXCEPTION is being set to PHPs' internal Error class or a supertype of it (Throwable) by the debugging extension:
argument description -x EXCEPTION exception name [required for exception breakpoint types]
See as well DBGP 7.6 breakpoints:
Breakpoints are locations or conditions at which a debugger engine pauses execution, responds to the IDE, and waits for further commands from the IDE.
That is where you got "stuck".