Chrome Xdebug Phpstorm

Posted : admin On 1/2/2022

Xdebug is an extension for debugging your PHP. The following explains how to configure Xdebug and PhpStorm to debug in your local environment. You can use the IDE of your choice. See the vendor documentation for those applications for further configuration information.

  1. Phpstorm Xdebug Docker Cli
  2. Phpstorm Xdebug Vagrant

Setup - xdebug phpstorm chrome. PHP remote debugging: XDebug can't connect to JetBrains php Storm client (2) i's like to get remote debugging to work with the following software configuration: Win 7 Pro 64bit WAMP Server 2.2 (32bit) incl. Apache 2.2.22, PHP 5.4.3, XDebug phpxdebug-2.2.1-5.4-vc9.dll JetBrains PHPStorm 4.0.3. Xdebug is a PHP extension which provides debugging, profiling, code coverage, stack traces and many other capabilities. In this succinct tutorial, I will show us how to set up Xdebug that ships with XAMPP in PhpStorm. See the steps below. Open up php.ini (located at C:path-to-xamppphp) for editing.

You can configure Xdebug to run in the Magento Cloud Docker environment for local debugging without changing your Magento Commerce Cloud project configuration. See Configure Xdebug for Docker.

To set up Xdebug, you need to configure a file in your Git repository, configure your IDE, and set up port forwarding. You can configure settings in the file. After editing, you can push the Git changes across all Starter environments and Pro Integration environments to enable Xdebug. To push these settings to Pro plan Staging and Production environments, you must enter a ticket.

Once configured, you can debug CLI commands, web requests, and code. Remember, all Magento Commerce Cloud environments are read-only. You need to pull code to your local development environment to perform debugging. For Pro Staging and Production environments, we include additional instructions for Xdebug.


To run and use Xdebug, you need the SSH URL for the environment. You can locate the information through the Project Web Interface or your Cloud Onboarding UI.

Configure Xdebug

To configure Xdebug, you need to do the following:

  • Work in a branch to push file updates
  • Configure your IDE, like PhpStorm

For configuring on Pro plan Staging and Production, you need to enter a ticket for Staging and Production.

Get started with a branch

To add Xdebug, we recommend creating a branch to work in and add the files.

To get started with environment branches:

  1. On your local workstation, change to your Cloud project directory.

  2. Switch to the Magento file system owner.

  3. Log in to your Magento project.

  4. List your projects.

  5. List environments in the project. Every environment includes an active Git branch that contains your code, database, environment variables, configurations, and services.

    It is important to use the magento-cloud environment:list command because it displays environment hierarchies, whereas the git branch command does not.

  6. Fetch origin branches to get the latest code.

  7. Checkout, or switch to, a specific branch and environment.

    Git commands only checkout the Git branch. The magento-cloud checkout command checks out the branch and switches to the active environment.

    You can create a new environment branch using the magento-cloud environment:branch <environment-name> <parent-environment-ID> command syntax. It may take some additional time to create and activate a new environment branch.

  8. Use the environment ID to pull any updated code to your local. This is not necessary if the environment branch is new.

  9. (Optional) Create a snapshot of the environment as a backup.

Enable Xdebug in your environment

To enable Xdebug for your project, add xdebug to the runtime:extensions section of the file.

You can enable Xdebug directly to all Starter environments and Pro Integration environments. For Pro Staging and Production, you need to update this file and enter a Support ticket to have it enabled. We enable Xdebug on those environments for you.

To enable Xdebug:

  1. In your local terminal, open the file in a text editor.

  2. In the runtime section, under extensions, add xdebug. For example:

  3. Save your changes to the file and exit the text editor.

  4. Add, commit, and push the changes to redeploy the environment.


When deployed to Starter environments and Pro Integration environments, Xdebug is now available. You should continue configuring your IDE. For PhpStorm, see Configure PhpStorm.

Configure PhpStorm

You need to configure PhpStorm to properly work with Xdebug.

To configure PhpStorm to work with Xdebug:

  1. In your PhpStorm project, open the settings panel.

    • Mac OS X—Select PhpStorm > Preferences.
    • Windows/Linux—Select File > Settings.
  2. In the Settings panel, expand and locate the Languages & Frameworks > PHP > Servers section.

  3. Click the + to add a server configuration. The project name is in grey at the top.

  4. Configure the following settings for the new server configuration:

    • Name—enter the same as the hostname. This value is used in and must match the value for PHP_IDE_CONFIG variable in Debug CLI commands.
    • Host—Enter localhost.
    • Port—Enter 80.
    • Debugger—Select Xdebug.
  5. Select Use path mappings. In the File/Directory pane, the root of the project for the serverName displays.

  6. In the Absolute path on the server column, click (Edit) and add a setting based on the environment:

    • For all Starter environments and Pro Integration environments, the remote path is /app.
    • For Pro Staging and Production environments:

      • Production: /app/<project_code>/
      • Staging: /app/<project_code>_stg/
  7. Change the Xdebug port to 9000 in the Languages & Frameworks > PHP > Debug > Xdebug > Debug Port panel.

  8. Click Apply.

Set up port forwarding

You must map the XDEBUG connection from the server to your local system. To do any type of debugging, you must forward port 9000 from your Magento Commerce Cloud server to your local machine. See one of the following sections:

Port forwarding on Mac or UNIX

To set up port forwarding on a Mac or in a Unix environment:

  1. Open a terminal.

  2. Use SSH to establish the connection.

    Add the -v option to the SSH command to show in the terminal whenever a socket is connected to the port that is being forwarded.

    If an “unable to connect” or “could not listen to port on remote” error is displayed, there could be another active SSH session persisting on the server that is occupying port 9000. If that connection isn’t being used, you can terminate it.

To troubleshoot the connection:

  1. Use SSH to log in to the remote Integration, Staging, or Production environment.

  2. Enter who to view a list of SSH sessions.

  3. View existing SSH sessions by user. Be careful to not affect a user other than yourself!

    • Integration: usernames are similar to dd2q5ct7mhgus
    • Staging: usernames are similar to dd2q5ct7mhgus_stg
    • Production: usernames are similar to dd2q5ct7mhgus
  4. For a user session that is older than yours, find the pseudo-terminal (PTS) value, such as pts/0.

  5. Kill the process ID (PID) corresponding to the PTS value.

    Sample response:

    To terminate the connection, enter a kill command with the process ID (PID).

Port forwarding on Windows

To set up port forwarding (SSH tunneling) on Windows, you must configure your Windows terminal application. For this example, we walk through creating an SSH tunnel using Putty. You can use other applications such as Cygwin. For more information on other applications, see the vendor documentation provided with those applications.

To set up an SSH tunnel on Windows using Putty:

  1. If you have not already done so, download Putty.

  2. Start Putty.

  3. In the Category pane, click Session.

  4. Enter the following information:

    • Hostname (or IP address) field: Enter the SSH URL for your Cloud server
    • Port field: Enter 22
  5. In the Category pane, click Connection > SSH > Tunnels.

  6. Enter the following information:

    • Source port field: Enter 9000
    • Destination field: Enter
    • Click Remote
  7. Click Add.

  8. In the Category pane, click Session.

  9. In the Saved Sessions field, enter a name for this SSH tunnel.

  10. Click Save.

  11. To test the SSH tunnel, click Load, then click Open.

    If an “unable to connect” error displays, verify all of the following:

    • All Putty settings are correct
    • You are running Putty on the machine on which your private Magento Commerce Cloud SSH keys are located

Configure Pro Staging and Production

To complete configuration for Pro plan Staging and Production environments, you must enter a Support ticket to have Xdebug enabled and configured in Staging and Production environments.

We enable Xdebug in the environment. Be aware that this is a configuration change that requires us to redeploy your Staging and Production environments.

SSH access to Xdebug environments

For initiating debugging, performing setup, and more, you need the SSH commands for accessing the environments. You can get this information, through the Project Web Interface and your project spreadsheet.

For Starter environments and Pro Integration environments, you can use the following Magento Cloud CLI command to SSH into those environments:

To use Xdebug, SSH to the environment as follows:

For example,

Debug for Pro Staging and Production

To use Xdebug specifically on Pro plan Staging and Production environment, you create a separate SSH tunnel and web session only you have access to. This usage differs from typical access, only providing access to you and not to all users.

You need the following:

  • SSH commands for accessing the environments. You can get this information, through the Project Web Interface or your Cloud Onboarding UI.
  • The xdebug_key value we set when configuring the Staging and Pro environments

To set up an SSH tunnel to a Staging or Production environment:

  1. Open a terminal.

  2. Clean up all SSH sessions.

  3. Set up the SSH tunnel for Xdebug.

To start debugging using the environment URL:

  1. To enable remote debugging, visit the site in the browser with the following added to the URL where KEY is value for xdebug_key:

    This sets the cookie that sends browser requests to trigger Xdebug.

  2. Complete your debugging with Xdebug.

  3. When you are ready to end the session, you can use the following command to remove the cookie and end debugging through the browser where KEY is value for xdebug_key:

    The XDEBUG_SESSION_START passed by POST requests are not supported at this time.

Debug CLI commands

This section walks through debugging CLI commands.

To debug CLI commands:

  1. SSH into the server you want to debug using CLI commands.

  2. Create the following environment variables:

    These variables are removed when the SSH session ends.

  3. Begin debugging

    On Starter environments and Pro Integration environments, run the CLI command to debug.You may add runtime options, for example:

    On Pro Staging and Production environments, you must specify the path to the Xdebug php configuration file when debugging CLI commands, for example:

For debugging web requests

The following steps help you debug web requests.

Phpstorm Xdebug Docker Cli

  1. On the Extension menu, click Debug to enable.

  2. Right click, select the options menu, and set the IDE key to PHPSTORM.

  3. Install the Xdebug client on the browser. Configure and enable it.

Example set up on Chrome

This section discusses how to use Xdebug in Chrome using the Xdebug Helper extension. For information about Xdebug tools for other browsers, consult the browser documentation.

To use Xdebug Helper with Chrome:

  1. Create an SSH tunnel to the Cloud server.

  2. Install the Xdebug Helper extension from the Chrome store.

  3. Enable the extension in Chrome as shown in the following figure.

  4. In Chrome, right-click in the Chrome toolbar.

  5. From the pop-up menu, click Options.

  6. From the IDE Key list, click PhpStorm.

  7. Click Save.

  8. Open your PhpStorm project.

  9. In the top navigation bar, click (Start listening).

    If the navigation bar isn’t displayed, click View > Navigation Bar.

  10. In the PhpStorm navigation pane, double-click the PHP file to test.

Debug code locally

Due to the read-only environments, you need to pull code locally from an environment or specific Git branch to perform debugging.

The method you choose is up to you. You have the following options:

Chrome Xdebug Phpstorm
  • Check out code from Git and run composer install

    This method works unless composer.json references packages in private repositories to which you do not have access. This method results in getting the entire Magento codebase.

  • Copy the vendor, app, pub, lib, and setup directories

    This method results in your having all code you can possibly test. Depending on how many static assets you have, it could result in a long transfer with a large volume of files.

  • Copy the vendor directory only

    Because most Magento and third-party code is in the vendor directory, this method is likely to result in good testing although you will not be testing the entire codebase.

To compress files and copy them to your local machine:

  1. Use SSH to login to the remote environment.

  2. Compress the files.

    For example, to compress the vendor directory only, enter

  3. On your local environment, use PhpStorm to compress the files.

Published on 2020-06-21 • Modified on 2020-10-18

In this post, we will see how to do step by step debugging with Xdebug, Symfony and PHPStorm. We will do a basic example where we will stop the execution of the Symfony code just before rendering a template to check the data passed to it. Let's go! 😎

» Published in 'A week of Symfony 704' (22-28 June 2020).


I will assume you have a basic knowledge of PHP, Symfony and that you know how to modify your PHP configuration thanks to the php.ini file.


Why this blog post? Well, because of this tweet:

PHP developers that don't use Xdebug for debugging are amateurs.

— Derick Rethans 🔶 (@derickr) June 20, 2020

This is the kind of tweet I don't like, a typical troll, trying to make a generality of something more complex. It brings negativity as It can be interpreted by people not using Xdebug by:

“If you don't use Xdebug, you aren't a real developer.” 😔

Even it's not what Derick meant to say, it's what people may understand. There is no smiley. We don't know if the tweet is pure sarcasm or not. I wanted to answer at first. But what about transforming something negative to something positive and useful? 😀 That's why I decided to write this blog post. 🙂


I use the following configuration, but it should be OK with previous versions of each of these components. Here, I use the Symfony binary to serve my application. If you use another type of setup (Apache, Docker...), you'll probably have to make small adjustments to the following instructions.

  • PHP 7.4
  • Symfony 5.2
  • Xdebug 2.9.6
  • PHPStorm 2020.3


I will assume you have a working PHP/Symfony installation. So first let's install Xdebug, it can be done with PECL:

If not done, activate the Xdebug extension in your php.ini file. You can find this file by running:

Verify that in this file, the (or .dll) library is loaded. You must see a line like the following (it can also be loaded in an external file like conf.d/ext-xdebug.ini):

If everything is OK, you should now see Xdebug when getting the PHP version:

Or when grepping the module list:

The debug bar also shows if Xdebug is available when you pass over the Symfony version number with your mouse:

Now that Xdebug is activated let's see how to configure it for PHPStorm.

Phpstorm Xdebug Vagrant

Configuring Xdebug and PHPStorm


First, we must enable the remote option of Xdebug. Add the following parameter in your PHP configuration as we did previously:

We keep the other default parameters to keep the configuration as minimal as possible. So, with this setup, the port used by Xdebug is 9000 and the default IP address is Check out the xdebug.remote_host and xdebug.remote_port parameters in the documentation.


Now, let's check the configuration inside PHPStorm. Open the menu entry: Run > Web Server Debug Validation. You should see this window:

In the first parameter put the full path of your project public directory where is stored the Symfony front controller (generally public/index.php with Symfony 5). In the second parameter, put the local URL of your project. Then click on validate. If everything is OK, you should see ✅ like above. You can ignore the error of the last line, it seems to be a known problem, but it won't prevent the debugger from working. The final step is to tell PHPStorm to start listening to Xdebug connections. It must be done with the Run > Start Listening for PHP Debug connections menu entry.

Step by step debugging

Now that PHPStorm has validated our setup let's try to add our first breakpoint. Open one of your controllers and click between the line number and the start of the code editor panel of the line you want to stop the execution. A red disc 🔴 appears like this (at line 33 in this example):

Now, open your browser and access a page that calls the action where we put the breakpoint. If it works, PHPStorm gets back as the active window of your OS, and you get the following output:

As you can see, the code window is different from what we use to have. First, after the controller method declaration line, we have the values of the parameters received by the action. $_locale is 'en', $goals is an array with two keys, and lastly, $articleRepository is the Doctrine repository of the Article entity. Just below, we see that the line of the breakpoint is highlighted; this is to show that the code has stopped here like expected. Just before this line, after the declaration of the $data (at the right), we see the value of this new variable. It is empty as we just declared it.
Just below, in the debug panel, we have a Variables section where we can inspect all the local variables available at the breakpoint.

This panel is very convenient; we can see all the variables (even the globals) and expand them to check their content. We also find the function parameters ($_locale, $goals, $articleRepository). As this controller extends the Symfony AbstractController, we can notice that it has access to the dependency injection container ($this->container).

Now let's try to advance to the next 'step', to go to the next line. We can use the 'Step over' button (F6 with my setup).

As you can see the highlighted line has changed, it's now line n°34. We can see the value of the $date variable just above. This new $date variable is now part of the 'Variables' panel. We can continue like this until the end of the action to check that the $data array contains the correct keys and values and can be passed to the Twig template. To continue the execution of the script, click on the 'Resume program' button ⏯️ (F8).
If you don't need the breakpoint for now but want to keep it for later, you can right-click on it and deselect the 'Enabled' option. The red disc appears now as a circle. Refresh the page, and you will notice that the script doesn't stop anymore.

The browser extension

We can also install a browser extension (available for Firefox, Chrome, Safari, Opera) to disable/enable the debug on the fly. When disabled, nothing is caught by PHPStorm even there are still some active breakpoints. It is faster than deactivating the breakpoint manually or altogether disable Xdebug in the PHP configuration. It looks like this:


Et voilà! We have a practical step by step debugging workflow using Xdebug! What about telling Derick that we are now professionals PHP developers? 😁

About the original tweet, I really liked the answer of Jordi; this is precisely what I think:

I can see a debugger being valuable when code is very complex or unknown, and often use it in JS. In PHP code though I usually am familiar enough with what libs I use and find no benefit to debugging interactively. Like most things, it depends. No need to call people amateurs IMO

— Jordi Boggiano (@seldaek) June 20, 2020To see parodic tweets of the original one, click on this link 😜.

If you don't drink Guinness you are an amateur

— Gary Hockin (@GeeH) June 20, 2020

PHP developers who don’t use @doctrineproject are amateurs.

— Jonathan H. Wage (@jwage) June 20, 2020

Developers that don't use a computer to develop are amateurs

— Gregoire Pineau (@lyrixx) June 21, 2020

PHP developers that don't write there own frameworks are amateurs

— Simon Bennett (@MrSimonBennett) June 20, 2020

PHP developers that write bugs and need to debug are amateurs.

Chrome Xdebug Phpstorm— Liam Hammett (@LiamHammett) June 20, 2020

That's it! I hope you like it. Check out the links below to have additional information related to the post. As always, feedback, likes and retweets are welcome. (see the box below) See you! COil. 😊

They gave feedback and helped me to fix errors and typos in this article, many thanks to jmsche. 👍

Did you like this post? You can help me back in several ways: (use the Tweet on the right to comment or to contact me )

  • Report any error/typo.
  • Report something that could be improved.
  • Like and retweet!
  • Follow me on Twitter
  • Subscribe to the RSS feed.
  • Click on the More on Stackoverflow buttons to make me win 'Announcer' badges 🏅.

Thank you for reading! And see you soon on Strangebuzz! 😉

[🇬🇧] New blog post, this is my answer to the tweet: 'PHP developers that don't use #Xdebug for debugging are amateurs.' Proofreading, comments, likes and retweets are welcome! 😉Annual goal: 4/6 (66%) #php#strangebuzz#blog#blogging#debug#bug#blogging

— COil #StaySafe 🏡 #OnEstLaTech ✊ (@C0il) June 23, 2020

Introducing CW: a cache watcher for Symfony

Adding a custom data collector in the Symfony debug bar