Valet: Odd breakpoint behavior on PHPStorm + XDebug + Nonstandard Port

[maiorano84]

Overview

In order for XDebug to function properly, Port 9000 cannot be used as PHP-FPM uses that port by default. EDIT: This portion no longer true since v2.0. This was done on version ~v1.x and carried over into a later installation.

When configuring PHPStorm and XDebug to use a nonstandard port, followed by triggering a Debug configuration on a Web Application path that uses a breakpoint, PHPStorm will first break at line 7 of ~/.composer/vendor/laravel/valet/server.php as if an invisible breakpoint is set there, and require a Resume Program action to be executed before hitting the expected breakpoint.

This example uses PHP 7.1, but this behavior has been consistent across other versions of PHP and other machines.

To replicate:

brew install php71-xdebug
nano $(php -i | grep "ext-xdebug.ini")

Settings:

[xdebug]
zend_extension="/usr/local/opt/php71-xdebug/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_port=9090

Create new Project in Parked directory.

PHPStorm->Preferences->Languages & Frameworks->PHP->Debug
XDebug->Debug Port: 9090

Edit Configurations->Add New Configuration->PHP Web Application
Server->...->Host: \ Apply
Select Server in new Configuration

Create File->index.php

sleep(0); //Add breakpoint here
phpinfo();

Run Debug Configuration

[drbyte]

Since version 2, Valet no longer uses port 9000. It uses a Unix Socket to connect nginx to PHP-FPM.

Ref: https://github.com/laravel/valet/blob/master/cli/stubs/valet.conf#L27

[maiorano84]

Currently running Valet 2.0.3. Removed nonstandard port in Xdebug Config.

php -i | grep "xdebug"

Full output:

/usr/local/etc/php/7.1/conf.d/ext-xdebug.ini
xdebug
xdebug support => enabled
xdebug.auto_trace => Off => Off
xdebug.cli_color => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.coverage_enable => On => On
xdebug.default_enable => On => On
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.extended_info => On => On
xdebug.file_link_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.halt_level => 0 => 0
xdebug.idekey => no value => no value
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.overload_var_dump => 2 => 2
xdebug.profiler_aggregate => Off => Off
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => /var/tmp/ => /var/tmp/
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => Off => Off
xdebug.remote_connect_back => Off => Off
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => localhost => localhost
xdebug.remote_log => no value => no value
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => Off => Off
xdebug.trace_enable_trigger => Off => Off
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => /var/tmp/ => /var/tmp/
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3

Followed this with:

brew services restart --all
valet restart

The replication process highlighted above still yields the same results: invisible breakpoint behavior on line 7 of ~/.composer/vendor/laravel/valet/server.php

[jpcaparas]

@maiorano84,

Solved this by unticking this option:

• [ ] Force break at the first line when a script is outside the project

... on Languages & Frameworks → PHP → Debug → Xdebug

These are my vanilla Xdebug settings:

zend_extension="/usr/local/opt/php71-xdebug/xdebug.so"
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remote_port=9000

This is probably because the vendor file ~/.composer/vendor/laravel/valet/server.php is acting as the router file and is on a different directory, triggering is outside the project condition.

[jpcaparas]

@drbyte can we close this? This is an IDE-specific issue and does not require changes to be done on the Valet code base.

[drbyte]

Agreed. Either @maiorano84 or @adamwathan can close it.

[maiorano84]

Agreed also. I didn't even know about this option in PHPStorm, so thanks to @jpcaparas for pointing it out. Closing, as the underlying issue is unrelated to the functionality of Valet itself.