Using the Web Server Debug Validation tool
If you are having problems configuring your debugger (either Xdebug or Zend Debugger), you can use the Web Server Debug Validation tool to solve common problems with your debug configuration. The tool can be started by using the Run | Web Server Debug Validation option from the menu.
Local Web Server or Shared Folder
If you are using a local web server for development, or a network shared folder (for example, a Vagrant box), then you only need to configure the local Path to create the validation script, and the Url to validation script. These need to match up, so that the path on the local file system (or shared folder) needs to match the url used to call that script on your web server. In the screenshot above, the webroot of the project is the public folder, and the site can be loaded via the local ip address on port 8080. Once these paths match, we can hit the Validate button.
Remote Web Server
If your files are local, but your web server is remote to your development system, then you'll need to select the Remove Web Server radio button, and configure the remote web server. The Path to create validation script should again be the path to the webroot within your project. You'll need to have a Deployment configured in PhpStorm for this project. For more information on creating a Deployment, see the Deploying PHP applications with PhpStorm tutorial.
Once we've created and selected the Deployment, we can hit the Validate button.
There has been a problem connecting to your web server. Make sure that the url (and port) provided to your web server either in the Url to validation script option or within your Deployment is correct.
Please, check that web path to validation script is correctly configured for...
The Path to create validation script within the local project does not map to the Url to validation script or Deployment url option. If you are using a framework and/or the PHP built in web server, this is likely to be because the framework is sending a 404 instead of sending the actual file in that directory. A quick way to test that is to create a test.php file in the directory you have set as the Path to create validation script, and then check that that file is callable from the Url to validation script or Deployment url with test.php appended.
For example, if your Path to create validation script is /var/www/public then you should create a test.php in that folder with the contents, for example, of
If your Url to validation script or Deployment url is then http://192.168.100.100:8080, then you should be able to call that script by visiting http://192.168.100.100:8080/test.php, and see the output "test works".
If you are seeing a 404 generated by your framework, then your url rewriting is wrongly configured, and you should consult your framework's documentation to ensure that the url rewriting configuration will return real files if they exist before sending any other requests to your framework dispatcher.
If you're seeing a 404 and you are using PHP's built in web server, it's likely because you cannot configure this web server to server files on the file system if they exist. You'll need to add the following code to the file you are sending all requests to (typically index.php) in order to send file system files if they exist:
Remote host is configured as 'localhost' despite server host is probably not local
The "URL to validation script" contains something different from localhost, but the xdebug.remote_host value is not set and so is using the default value of localhost, or is set to localhost or 127.0.0.1.
Validation Runs Successfully
In this instance, the validation script has been created and called so the validation can be deemed successful (even though we have some problems). The validator is telling us that my remote host (localhost) does not match the url I'm using to call the validation script (stayup.dev) and this might be a problem. It's also telling us that while Xdebug is installed, and is configured to be running on the same port that PhpStorm is expecting (9000), the Remote debug setting is not enabled so we won't get any debug information.
We can use the (...) to get more information about a particular problem. Once we have all blue i icons, we're ready to step debug successfully.