So I was tinkering around to get Xdebug 2.2.4 working with PhpStorm 7.1.3. It does work fine, in example when I
- create an empty project, add a single PHP file with some test code
- create a composer project with laravel/laravel as the base package
I try to debug command line execution via Laravel Artisan in the latter. When telling PhpStorm to "Break at first line in PHP scripts" it breaks in the first line with code of the Artisan script, perfect. Now the problem: I have already started a laravel web application project some weeks ago when I did not even think about PhpStorm yet. When I try to set up PhpStorm to debug that, Xdebug always fails to connect to PhpStorm. The following ways fail:
- opening the directory with PhpStorm
- check out of the Trunk form version control with PhpStorm
- create an empty project in PhpStorm and copy the files into the project directory with Windows Explorer
I always set "Break at first line in PHP scripts", start listening for PHP Debug connections and create a project debugging configuration based on "PHP Script" targeting the artisan file. Everything with PHP 5.5.9 (64 Bit) on Windows 8.1. Everything just as in the two example cases described at the beginning. Oh, and everything is taking place on localhost, no remote stuff. Just an ordinary Subversion working copy in my user directory. PhpStorm is telling that xdebug is installed during validation and that I should check configuration options. But they do not differ from the ones which are working, because they are the same. It must be something with the files in my working copy, because it probably cannot be because of the PhpStorm project (directory) which is created new in every of the three failing cases.
How could files in a project affect PhpStorm or Xdebug behaviour? What could be the cause of this problem?
Update: I created another composer project in a directory on the desktop and copied selectively some application files over, it works fine then. Maybe it is also related to composer, I do not know, at least a "composer update" did not change anything. I also checked out a working copy on the desktop, too, of the application I actually wanted to debug, in a a separate directory (that's where the files came from which I copied into the new composer project in PhpStorm). When I remove all the files in the working copy directory and copy the contents of the newly created project into the working copy directory, the problem arises again. So is Subversion somehow messing with Xdebug? That sounds totally unplausible. I am getting clueless: Two directories with identical content, one a subversion working copy, the other one not, but only the one can be debugged, which was created with PhpStorm as a composer project (I copied the .idea subdirectory as well).
Update: A diff of the .idea project directories did not reveal anything suspicious. The workspace.xml was a bit different because of other window and pane dimensions. The misc.xml however was extended by Subversion configuration like this:
<component name="SvnConfiguration" maxAnnotateRevisions="500" myUseAcceleration="nothing" myAutoUpdateAfterCommit="false" cleanupOnStartRun="false" SSL_PROTOCOLS="all">
<option name="USER" value="" />
<option name="PASSWORD" value="" />
<option name="mySSHConnectionTimeout" value="30000" />
<option name="mySSHReadTimeout" value="30000" />
<option name="LAST_MERGED_REVISION" />
<option name="MERGE_DRY_RUN" value="false" />
<option name="MERGE_DIFF_USE_ANCESTRY" value="true" />
<option name="UPDATE_LOCK_ON_DEMAND" value="false" />
<option name="IGNORE_SPACES_IN_MERGE" value="false" />
<option name="CHECK_NESTED_FOR_QUICK_MERGE" value="false" />
<option name="IGNORE_SPACES_IN_ANNOTATE" value="true" />
<option name="SHOW_MERGE_SOURCES_IN_ANNOTATE" value="true" />
<option name="FORCE_UPDATE" value="false" />
<option name="IGNORE_EXTERNALS" value="false" />
But that should not interfere with Xdebug connecting to PhpStorm...
Update: I attached PhpStorm log files. One contains all entries from start of the IDE over stopping at a breakpoint to shutdown. The other one, too, except for no stop at a breakpoint but only information about Xdebug failing to connect:
java.net.SocketException: Connection reset