Linux Mint 15, Aptana Studio 3.4.1, Chromium 28.0.1500.71
Sorry, this is a little lengthy to explain. Please let me know if something's not clear.
The title is my goal. I have a local server set up with Apache2. I don't know if it matters, but I have dnsmasq set up to redirect, for example, site.dev/index.html to /home/wastvedt/Projects/site/www/index.html (described here).
I've followed the tutorials I can find. XDebug is running, I have the helper installed in Chromium, and the debugger, interpreter, and web server set up in Aptana.
I'm working on a WordPress site and want to break on one of the functions in my theme's functions.php file. I created a breakpoint in the function in Aptana, turned on the XDebug helper in Chromium, and updated a post, which calls the function in question. Aptana recognizes what I'm doing and prompts me with the option of breaking on the first line. Regardless of what I select, I see "XDebug JIT Session [Remote Launch]" in the Debug view. The prompt appears three times, but nothing else happens in Aptana.
I think the problem might have something to do with linking files in the editor to files in Apache. When I try this JIT debugging thing with "localhost" (located at /home/wastvedt/apache2/www/index.php), Aptana brings up /home/wastvedt/Projects/site/www/index.php. This isn't right, but maybe the real problem is somewhere else. To be honest I'm a little lost now.
Any thoughts? I'd provide some sort of dump or output, but I'm not sure which or what.
Thanks for reading,
Trygve
In order to properly setup XDebug with Aptana I setup the below options by going to the Window menu -> Preferences -> Aptana Studio -> Editors -> PHP -> Debug:
Allow multiple debug sessions: Always
Break on first line when an unknown remote sessions (JIT): Never
Then click on XDebug in Installed Debuggers -> Configure:
Use Multisession: OFF
Accept remote session (JIT): any
That pretty much made it work for me.
Related
I am using Aptana 3 studio to work on my php (drupal) projects. All of the sudden, the debug function stopped working. It used to work flawlessly. Now when I select a debug configurtion and debug it, an empty page opens in firefox.
Is this connected with how Aptana communicates with the browser? With the server?...
EDIT:
So I decided to try a new thing altogether and installed a full new system based on LXLE 14.04 (based on the same ubuntu 14.04, which I used in a full unity version before).
Now, after some quirks, I have a running debug in Aptana on that system. I am pretty sure, though, that this is the configuration that worked for me in the first place.
I also remarked some weird window behavior on the system - sometimes the Aptana window would get so small it is hardly noticable (1px*1px?) and gets to the top left corner.
I found that setting xdebug.remote_autostart=1 in php.ini and restarting Apache allows me to debug somewhat. Although Firefox still opens a blank page, opening the page myself in the browser now allows me to get a break in Aptana.
I got a real problem with Komodo Edit v8.5.3: I use XAMPP XAMPP v1.8.3 [PHP: 5.5.6] to provide a local hosted server for Komodo.
[Edit -> Preferences -> Languages -> PHP] ; here I configured the PHP stuff like this:
**Default PHP Interpreter** C:\xampp\php\php.exe
**Path to alternate PHP configuration file** C:\xampp\php\php.ini
**PHP Directories** nothing
After restarting I tested this feature: But no autocomplet and calltips, syntax checking did sometimes work ...
If I wrote some code, it began to scan the php directory of XAMPP for completing, but this search got freezed everytime somewhere (in the PEAR directory).
I don't really understand what's wrong with Komodo and XAMPP. (I did also reinstall Komodo.)
Komodo is great, but withoutd this the most importent feature is impossible.
Komodo php autocomplete didn't work for me, too.
My situation might be different, but I'm sharing for the next Googler to visit.
I installed Komodo before php5. Whoops. Installing php wasn't good enough, I had to also delete the config files in ~/.komodo-edit (or whatever folder it created).
That still wasn't enough, I also had to delete the ___.komodoproject file I was working on as well.
Then I was awed by Komodo's awesomeness.
Komodo Edit 8.5.3 has a memory leak problem. To confirm this check your process list and you will see Komodo Edit main thread and Python child thread. Watch to see the memory footprint of the Python thread as the scan progresses.
If the memory is large (for me is was over 1GB), try upgrading to a later release.
At time of writing this, you can find version 8.5.4 here:
http://downloads.activestate.com/Komodo/nightly/komodoide/latest/
I would like to know how i can get XDebug work with Aptana Studio 3 (I already have Aptana Studio 3 on this machine with XAMPP).
Do you know a recent article telling me how to do this and explains XDebug? I have no experience nor any knowledge about XDebug, i looked for articles but all seem outdated to me.
I realize that this is a old thread but I also had a difficult time finding out how to debug php with Aptana Studio and FireFox so here is a quick how-to to get it working...
The easiest way I found is to install wamp server V2.2, this is a very useful program as it installs Apache Server, PHP and MySQL and other tools, everything can be easily configured via the taskbar.
1.) Install Aptana Studio V3.3.X or higher Download here
2.) Install WampServer V2.2 or higher Download here (XAMMP users read bottom).
WampServer:
1.) Make sure XDebug is accepting remote debug, click on the WampServer icon in the taskbar and go to PHP->PHP Setting and make sure that "(XDebug): Remote debug" is checked if not select it click on the WampServer icon and "Restart all services".
2.) Verify that XDebug is running:
a.) If you had WampServer insert index.php enter "localhost" in the URL and under "Tools" click "phpinfo()" and check to make sure XDebug is running, you should see the following in FireFox:
b.) If you didn't overwrite the index.php create a file (/www_dir/phpinfo.php) with the following:
<?php
phpinfo();
?>
b.1) In FireFox enter "localhost/phpinfo.php" and look for XDebug as shown in the previous image.
Aptana Studio:
1.) Click Window->Preferences
2.) In the Preferences dialog go to Aptana Studio->Editors->PHP->PHP Interpreters
3.) Click "Add..."
4.) Enter the information like
5.) Click "OK"
6.) Click on the debug icon and select "Debug Configurations"
7.) Double click on "PHP Web Page"
8.) Click the plus next to "PHP Server"
a.) Enter a name
b.) Base URL will be "localhost"
c.) Document Root will be the path to your index.php
Finally in Aptana Studio click the Debug Icon Arrow and select the configuration you named above. If Firefox prompts you install the Aptana Studio plugin...
Hope this helps out...
-------------
XAMPP USERS
-------------
Follow the steps provided but your directory link in the
In the Preferences dialog go to Aptana Studio->Editors->PHP->PHP Interpreters
should link to C:\xampp\php\php.exe and C:\xampp\php\php.ini respectively
***** UPDATE *****
If you are using Firefox V20+ there are some compatibility problems with Firebug V1.8+ that basicly breaks Firefox's context menus, I could not find a fix for it so I ended up having to go another route and figured I should make a post, Aptana Studio is based on Eclipse so the best way IMHO to get PHP Debugging is to install Eclipse with PDT and remove Aptana Studio... The above instructions will work to get everything working with XDebug
Here is a nice link on how to get everything up and running eclipse-pdt
At the moment, there is no PHP debugger support in Aptana Studio 3. However, there will be soon. See: http://jira.appcelerator.org/browse/APSTUD-769 and add yourself as a watcher to get informed when it's done.
For now, you can install PDT from eclipse.org if you really need to debug.
They also provide up-to-date docs on how to use it. There is a small learning curve, but it will work pretty much the same in Aptana (once it's released), so you have nothing to lose :)
Here is a mini how-to configure and start using XDebug with Aptana Studio 3.3, assuming you have installed xdebug on your system. (In Ubuntu/Linux it's just a sudo apt-get install php5-xdebug).
Configure the debugger
In preferences->Aptana Studio->PHP->PHP Interpreter click on Add..., and specify a name, the php executable(/usr/bin/php in most Linux distributions), the php.ini(/etc/php5/conf.d/20-xdebug.ini on my system), and leave XDebug in the select field of PHP debugger.
Using the debugger
Make a php file and put some code in it:
<?php
$defined_var = 'some value';
echo $defined_var;
echo $undefined_var;
exit();
?>
Save it and press Run->Debug As->PHP Script and you will be prompted to switch Workspace.
Specify a Line Breakpoint by double clicking next to a line number, for example at the line of exit() function.
Press Resume(F8) and you can see that the Debug Current Instruction Pointer moved there.
At the variables tab, you should now see which variables have some value or they are uninitialized. The output can be found at the console tab.
Pressing resume again will terminate the debug.
Of course, this is only the tip of the iceberg regarding debug, but it's a start.
There are many other options to explore and ways to debug your scripts.
I have use Aptana Studio 3.2.2 to develop my Drupal site and use XDebug to debug the project. The Aptana Studio supports xdebug. You need to follow some steps to enable xdebug in Aptana Studio.
Configure xdebug in your php engine properly.
Edit the preference by going Preference -> Aptana Studio -> Editor -> PHP Interpreter.
Add a PHP interpreter and save it.
Now create a new Web Server if no web server is currently working.
Now Apply the changes.
Next, Edit the Debug Configuration using Run -> Debug Configurations -> PHP Web Page.
Add a new web page by selecting a initial script file for the php project.
In the last step, start debugging.
You can find a details step by step procedure in the following link:
http://devcircle.blogspot.com/2013/02/enable-xdebug-in-aptana-studio-3x.html
Hopefully it helps to solve the problem.
For me it worked only after
1. Performing stuffs from here (basically - setting-up the XDebug for remote debugging)
https://jira.appcelerator.org/secure/attachment/26404/ScriptPHPDebugging.pdf
2. installation of "XDebug helper" for chrome, and something similar for FF.
After that I have my remote sessions working just-like-they-did-in-Eclipse.
My Xdebug works fine when I use eclipses' internal browser but when I use it in an external browser apache crashes.
I am using xampp and on windows 7 64 bit. If someone needs more information let me know.
For some reason if I have the variables tab open in the php debugger in eclipse it crashes apache. So to stop it I just can't have variables tab open while debugging. So this avoids the problem but doesn't fix it. I would like to be able to have this tab. Any suggestions?
It is possible that the XDebug build and type does not match your apache & php build and type...
Apache compiled with VS.NET 2008 (VC9) for 32bit and using PHP as a module would require XDebug: 32bit, VC9, Thread Safe.
http://xdebug.org/download.php
Also, you could test another WAMP package that comes with XDebug (for example WampDeveloper) and if it also does not work for you, it's probably not a build mismatch issue.
Hey I got this working
Eclipse 3.6.1 (because on later versions key shortcut for putting line comment don't work)
Xampp 1.7.4
Xdebug 2.1.2
The trick is to change php from VC6 to VC9 and then it just works correctly.
BTW. It's the variables panel that causes xdebug to crash apache on php VC6.
Remember to get VC9 version of xdebug for new php AND if you put your new php in directory other than
\xampp\php, then on phpinfo(); you'll see that there's no php.ini loaded so just rename old php (co you can swich them from one to other anytime) and put new php in the same directory in which original php was in "\xampp\php" and copy your php.ini (because paths doesn't change). Also remember to obtain any additional php extensions you've been using in VC9 version for new php and put them in "\xampp\php\ext"
I can confirm most of what t0meck said. Except I've moved up to xampp-win32-1.7.7-VC9 which has PHP 5.38. Taking the phpinfo() results from that to Xdebug's custom installation analyzer, it specifies the php_xdebug-2.1.2-5.3-vc9.dll, but the problem isn't entirely eliminated. As I've documented in my 'notes to self' page, the following is working for me.
After following the above procedure, the 'run as' should work on the first try, but the 'debug as' may crash Apache at every attempt. This is an issue that has driven many people to severe distraction. There is an apparent bug exposed using the debug perspective. At the top center of the perspective is a window with two tabs, the variable view and the breakpoint view. Usually, Apache crashes only when the variable view is highlighted, so highlight the breakpoint view instead. Then set a breakpoint on your project. Now, if you are one of the chosen, you will be able to step through the script using the debugger, but when you switch to the variable view it may still crash Apache. What a drag. Repeat the process and the next time you should actually see the variables and the problem will magically go away, until you restart the project. Just repeat the procedure and be satisfied with being one of the lucky ones.
Don't know if this help, I have same kind of issue, but it relate to array depth xdebug >handle in Variables view. And you can change it. Widnow > Preferences > PHP > Debug > >Installed Debug > Xdebug > Configure enlarge the "Max array depth" solved my issue.
http://bugs.xdebug.org/view.php?id=658#c1767
Just set it to 10 or bigger and it should work
I'm having trouble with debugging a PHP project through NetBeans using XDebug, and was hoping someone out there might have had this problem before.
Debugging works fine for the requested php file - so if I go to index.php on the remote server, I can put a breakpoint anywhere in index.php in NetBeans and the code stops there and I can step through.
The trouble is, all the other files appear on the call stack like this: "file:///home/user/site_html/library/class.requestprocessor.php" and because that's a path to a file on the remote server, NetBeans is unable to resolve the name, and so I can't step through the code for it. It makes debugging practically useless! The php file that was requested, for example index.php, appears just as "index.php", it's just all the other ones which are included that NetBeans can't resolve properly.
Is there some setting in NetBeans or XDebug that I can use to solve this problem? I have tried my best looking through all the project settings and options in NetBeans, and also looked through all the configuration options of the XDebug extention, but to no avail. Surely someone out there must have had this problem before? How did you solve it? I'll be very grateful if you could let me know.
If there's no other way, do users of Eclipse PDT and XDebug have this problem when debugging on a remote server? If not I'll make the switch.
This issue appears to be fixed in NetBeans 6.7.
Okay it seems no one is going to answer the question, so I'll post the results of my research.
As I was unable to find a way to make NetBeans successfully debug as I wanted, I tried using Eclipse PDT and Visual Studio 2008 with the VS.php extension in order to solve my problem. Eclipse PDT was hell to setup, and I wasn't happy with the way you couldn't specify a port to use for your FTP server in its Remote Server Explorer. I found VS.php did everything I wanted, it automatically uploads the code, as well as having perfect debugging, and it was EASY to setup. The only thing is, it looks ugly and I can't find a way to customise its colours. However, I'm going to choose function over fashion, and so I've settled on using VS.php as my final solution. Which to be honest is a shame, NetBeans was really great, I just can't live without a working debugger.
I had this same issue. I'm running Netbeans 6.8. You have to right click on your project, go to project properties/run configuration/advanced and set up path mapping. Map the folder on the server to a folder locally so that Netbeans knows which files to open locally when it hits these methods.