Set breakpoints in any file.

[hobbes3]

Sorry, I know this isn't really a bug or an enhancement post, but more like a general question.

So far I figured out how to use Vdebug on all PHP file except for PHP files that handle POST variables (especially form submissions). For AJAX calls, I can just copy and paste the URL with the GET variables to start a Xdebug session.

Is there a way to open a form handling PHP file that you know will be called, set a breakpoint, then submit the form and start a Xdebug session at the breakpoint or file?

[qstrahl]

You can configure Xdebug to behave in a variety of ways. I like to have it enabled all the time on my local machine, because only I do development there. Here's a helpful tool to generate bookmarklets you can use to toggle whether or not your browser talks to Xdebug. There's also a few helpful instructions regarding configuration on the Xdebug installation page. Let me know if this doesn't address your problem.

[hobbes3]

I have the Chrome extension to toggle the XDEBUG_SESSION_START GET parameter, which means I can only start the Xdebug session from the URL.

As for the first post, I guess I wasn't being clear, so here is an (overly simple) example:

<form action="welcome.php" method="post">
Name: <input type="text" name="fname">
Age: <input type="text" name="age">
<input type="submit">
</form>

For this form, once I hit submit, how do I debug welcome.php with the POST parameters name and age?

[qstrahl]

1. Set your breakpoints in welcome.php
2. Fill in the form
3. Press <F5> in Vim to begin listening for connections
4. Submit the form

Vdebug should then break at your breakpoints in welcome.php when your browser makes the POST request for that script.

[hobbes3]

Wow, ok I don't know why, but I remembered I couldn't just set breakpoints in any random php file (maybe Vdebug wasn't being loaded?). I feel really stupid now.

Thanks @qstrahl.

I just tested your method with AJAX calls too and it works. The only thing I still haven't figured out is how to debug AJAX calls that loads during the beginning of the page. If I listen on Vdebug and reload the page, it will start debugging on the actual page itself instead of the individual AJAX calls.

[hobbes3]

Ok, I was able to reproduce the error. If the PHP files are all local, then @qstrahl's method works perfectly, but if I try to set a breakpoint on a file that is remotely mounted, it gives this error:

E158: Invalid buffer name: /Users/hobbes3/mounts/nead/Users/hobbes3/mounts/nead/var/www/vhosts/mysite.com/common/functions/email_lib.php
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/hobbes3/.vim/bundle/vdebug/plugin/python/start_vdebug.py", line 135, in set_breakpoint
    self.runner.set_breakpoint(args)
  File "/Users/hobbes3/.vim/bundle/vdebug/plugin/python/vdebug/runner.py", line 223, in set_breakpoint
    self.breakpoints.add_breakpoint(bp)
  File "/Users/hobbes3/.vim/bundle/vdebug/plugin/python/vdebug/breakpoint.py", line 36, in add_breakpoint
    breakpoint.on_add()
  File "/Users/hobbes3/.vim/bundle/vdebug/plugin/python/vdebug/breakpoint.py", line 105, in on_add
    self.ui.register_breakpoint(self)
  File "/Users/hobbes3/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 111, in register_breakpoint
    breakpoint.file,breakpoint.line)
  File "/Users/hobbes3/.vim/bundle/vdebug/plugin/python/vdebug/ui/vimui.py", line 118, in place_breakpoint
    ' file='+file.as_local())
vim.error  

I can tell something is wrong with the filename since it's repeating /Users/hobbes3/mounts/nead twice. I think it has something to do with how I mounted the files with sshfs:

sshfs user@mysite.com:/ ~/mount/nead

Here is my Vdebug config in my .vimrc:

" Vdebug
let g:vdebug_options = {
\   'path_maps': {
\       "/var/www/vhost": "/Users/hobbes3/mounts/nead/var/www/vhost",
\   },
\   'server': '0.0.0.0',
\   'timeout': 5
\}

[qstrahl]

The only thing I still haven't figured out is how to debug AJAX calls that loads during the beginning of the page. If I listen on Vdebug and reload the page, it will start debugging on the actual page itself instead of the individual AJAX calls.

This is a known issue and a non-blocking listener is in production to resolve it (see #58)

If the PHP files are all local, then qstrahl's method works perfectly, but if I try to set a breakpoint on a file that is remotely mounted, it gives this error ...

Hm, this sounds like a remote pathing issue more than anything. Possibly related to #54, but this is outside my scope for now. @joonty may have a better idea of the problem at hand, here.

Note that although I can't set breakpoints in any file, I can still set it when the Xdebug session is running.

Can you give a more detailed description of what exactly doesn't work and under what conditions this happens?

[hobbes3]

After reading #54, it seems that fix-file-paths branch is what I need to test/use. (https://github.com/joonty/vdebug/tree/fix-file-paths)

How do I install that branch with Vundle (and override the original Vdebug installation)? I feel I should use Vundle since I tried to manually install Vdebug before and it didn't work for me (I couldn't even get :help Vdebug to work).

Currently I have Bundle 'joonty/vdebug.git' in my .vimrc.

[joonty]

Hi @hobbes3, you would probably be better off using the dev branch, as fix-file-paths is due for deletion. I don't believe there's anything in there that isn't in dev any more.

There's no way of selecting the branch in Vundle, but you can just cd to ~/.vim/bundle/vdebug and git checkout dev - that's what I do and it works without a problem.

As for the file path issue, @qstrahl is absolutely right, this was tackled in #54. It should be fixed in dev, so give that a whirl.

Cheers

[hobbes3]

Oh cool, I didn't know bundles were also part of a git repo.

But I must have done something wrong with checking out the remote branch since it's still showing the same error when setting a breakpoint on a file that's remotely mounted.

This is what I did:

[hobbes3@hobbes3] ~/.vim/bundle/vdebug $ git branch -r
  origin/HEAD -> origin/master
  origin/dev
  origin/fix-file-paths
  origin/fix/issue-60
  origin/master
  origin/refactor
[hobbes3@hobbes3] ~/.vim/bundle/vdebug $ git checkout -b dev origin/dev
Branch dev set up to track remote branch dev from origin.
Switched to a new branch 'dev'

Then on Vim I typed :BundleInstall! and it gave me this error.

Done!
Error detected while processing /Users/hobbes3/.vim/bundle/vdebug/plugin/vdebug.vim:
line  161:
E122: Function vdebug:edit already exists, add ! to replace it 

which is weird since I did type ! at the end of BundleInstall.

[qstrahl]

You shouldn't have to do :BundleInstall; once you've switched to the dev branch, you should be set. You could try a git pull from inside ~/vim/bundle/vdebug to be sure you have the latest dev branch.

[hobbes3]

Thanks for all your help so far, @qstrahl.

I tried git pull and it's still giving me the same breakpoint error. I know I checked out origin/dev... Was there anything else I was supposed to do? Or maybe this is a new bug (related to sshfs mounts)?

[qstrahl]

As long as your local dev branch is up to date with origin/dev, you should have the fix. If you go to ~/.vim/bundle/vdebug and do git branch -vv, it should show that you are on branch dev and that dev is pulling from origin/dev. Verify that to be sure. At this moment, origin/dev is at commit Fix vdebug.vim and it has a SHA starting with 716d7d9; the command should show that as well, all in the same line.

If you're completely up to date and using the correct branch and it still isn't working -- silly question, but I have to ask -- did you restart vim after updating? If no, try that. If yes, we have a new problem on our hands. Thanks a lot for helping us get to the bottom of this issue.

[hobbes3]

I did another git pull today and now it worrks! Thanks @qstrahl and @joonty!

git pull did somehow do a merge on my local branch though (I don't know why). Sorry, I'm really new to git and Vim extensions.

[hobbes3@hobbes3] ~/.vim/bundle/vdebug $ git branch -vv
* dev    a1d0e01 [origin/dev] Merge pull request #76 from Chronial/fix-winclose
  master 84fae34 [origin/master: behind 1] Merge pull request #66 from xbot/master

[hobbes3@hobbes3] ~/.vim/bundle/vdebug $ git pull
remote: Counting objects: 83, done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 66 (delta 39), reused 50 (delta 25)
Unpacking objects: 100% (66/66), done.
From https://github.com/joonty/vdebug
 + a1d0e01...716d7d9 dev        -> origin/dev  (forced update)
 + bd6dd27...e6d8dad fix-file-paths -> origin/fix-file-paths  (forced update)
Auto-merging plugin/python/vdebug/util.py
Auto-merging plugin/python/vdebug/ui/vimui.py
Auto-merging plugin/python/vdebug/runner.py
Auto-merging README.md
Merge made by the 'recursive' strategy.
 README.md                        | 20 +++++++++++++++++++-
 plugin/python/vdebug/event.py    |  2 +-
 plugin/python/vdebug/runner.py   |  2 +-
 plugin/python/vdebug/ui/vimui.py |  6 +++---
 plugin/python/vdebug/util.py     | 16 ++++++++++++++++

[hobbes3@hobbes3] ~/.vim/bundle/vdebug $ git log
commit bd447c1e89e5c374975ed055c808b2c0fbab47bb
Merge: a1d0e01 716d7d9
Author: hobbes3 <hobbes3@gmail.com>
Date:   Thu May 9 09:54:17 2013 -0400

    Merge branch 'dev' of https://github.com/joonty/vdebug into dev

commit 716d7d93d497059acbc7c469e0e826b71efcc101
Author: Jon Cairns <jon@joncairns.com>
Date:   Thu May 9 14:22:45 2013 +0100

    Fix vdebug.vim

[qstrahl]

The merge isn't your fault; I got it, too. The dev branch must have had a history rewrite somewhere, which is bad! Basically, some commits disappeared from the history of origin/dev, and your local branch is therefore out of sync and has to merge rather than fast-forward to the new HEAD commit on dev. You can reset your local branch to the remote using git reset --hard origin/dev. Be careful, though, as this will get rid of any changes you might have made.

As you've said it works now, I'm closing the issue.

[joonty]

Hey guys, this was all my fault.

I noticed a problem with the dev branch, where commits had been duplicated back to the beginning of time. To fix it I had to do the biggest, meanest interactive rebase ever. I got it sorted in the end, but that would account for the history rewrite.

I also noticed that I was completely wrong, and @hobbes3 was completely right - the fix-file-paths hadn't been merged into dev, which it totally should have been. Therefore, I also did that. That would account for it now working for you.

Sorry @hobbes3, and sorry @qstrahl

😺

[qstrahl]

Aha, that explains it all.