I put this in to php.ini
include_path = ".;c:\php\includes;C:\wamp\zend\library"
C:\wamp\: here I put the zend frame work
when I run the WAMP sever , I seen a page as usual
How I check whether it's install or not,
How I start my work in the frame work
check the output of php_info() to see if you settings were applied as expected ...
also a screencast to let you get kick off.
Related
I'm having this weird problem. All my settings used to work OK, until I updated my version of PHP. I use macports and have the php5 and php5-xdebug ports installed.
xdebug is working, but it is stopping on the first line of my script even though I have the option disabled in PhpStorm. There is no breakpoint there, and breakpoints in other parts of the code are working OK.
If it helps, here is the xdebug portion of phpinfo (in two parts);
https://dzwonsemrish7.cloudfront.net/items/3K3R2N1f1A190K372n0S/Screen%20shot%202011-08-18%20at%203.06.29%20PM.png?v=54c8964d, https://dzwonsemrish7.cloudfront.net/items/0i133s0U430k3u3w3B1E/Screen%20shot%202011-08-17%20at%205.14.25%20PM.png?v=1278da84 and the proof it is disabled in phpStorm: https://dzwonsemrish7.cloudfront.net/items/3W2S060I1b0W1q0z0c45/Screen%20shot%202011-08-18%20at%203.07.00%20PM.png?v=85471026
Is there an xdebug setting I need to change? When I did the upgrade, I lost my php.ini that had some other xdebug configuration.
The above didn't work for me because as far as I can tell if you're using Xdebug the only debug bookmarklets you get is start/stop and debug this page. I don't see any bookmarklet specific to stopping on first line, and neither the start/stop bookmarklets nor stopping PHPStorm from listening within PHPStorm fixed the problem for me.
To get it to stop I did this (on OS X):
Go to Preferences > Languages & Frameworks > PHP > Debug
Uncheck both of the 'force break at the first line...' options
Apply and close
In the Run menu, uncheck 'Break at the first line in PHP scripts'
For example, even if you have Path-Mappings, the public/index.php path may not be considered as part of the project.
Check the "Force break at the first line..." in the PHP->Debug section of preferences.
BESIDES THAT, also check this setting:
My problem with PHPStorm was that I was doing Drupal and the index.php was outside the project (since the project is a module). I needed to uncheck the settings "Force break at the first line..." in the PHP->Debug section of preferences.
Do you use debug bookmarklets? 'Break at the first line' option could be also controlled via 'xdebug Break On' and 'xdebug Break Off' bookmarklets.
Im trying to configure xdebug to work with Netbeans 6.9 and php 5.3
As far as i concern i have setup xdebug properly.
I can see xdebug extension from phpinfo page.
I have read other post and tried their suggestion but up to no avail
When i hit the debug button, it straight open the page in the browser and i can see message 'Waiting for connection' in the bottom pane of netbeans
Here my setting in php.ini
zend_extension = /usr/lib/php5/20090626+lfs/xdebug.so
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"
Any help would be appreciated
First, check that it isn't actually working for you, and you don't notice. I've done this...convinced it's not working I wasted a chunk of time trying to get it to work, only to find that everything was OK.
Look at your NetBeans status bar. If you see "netbeans-xdebug" and "running" then it is actually working just fine. You probably have the "Stop at first line" option turned off and you didn't hit any breakpoints you set (if any) yet. That would be a reason you are seeing the page with little or no indication that the debugger is actually connected.
If you instead see "Waiting for Connection (netbeans-xdebug)" and the progress bar is cycling, then you are indeed not connected. Open Tools|Options, and go to the PHP page. On the general tab, make sure that the "Debugger port" is 9000 and the "Session ID" is "netbeans-xdebug". You may want to have "Stop at First Line" checked. I don't, as I find it a bit annoying. I would definitely ensure that "Watches and Balloon Evaluation" is not checked. This option causes NetBeans and the debugger to destabilize. If you need a watch, hack a local variable into the PHP code where you need it, and you'll see it on the "Variables" tab when the debugger is running. Also, confirm that file (index.php) is specified in the project's Run Configuration > Index File.
Since you see xdebug in phpinfo(), that end of it is fine. Just make sure that all of the values look reasonable, and that there is some reference to a cookie "XDEBUG_SESSION=netbeans-xdebug" somewhere on that page. (Make sure that you don't have cookies turned off on the browser!)
The only other thing to check is to see if some firewall/security program is running that would be blocking TCP/UDP locally (which would be super-odd, but not out of the realm of possibility), or that port 9000 isn't already used by another application. I am using a different port number in my local setup for some reason. I don't remember changing it, but I am sure that the only reason I would have is if I had hit a port conflict with something else.
One last thing... We've been assuming that you are running NetBeans and the web server on the same computer. That's a common configuration, but not the only one. If your web server is on a different computer, then change the localhost in xdebug.remote_host=localhost to the IP address of the computer on which NetBeans is running.
Another last thing: When cycling through frustrating iterations, until you see xdebug info in phpinfo(), restart apache/php. Once there, still restart NetBeans between iterations. And believe it or not, restart your browser.
For me it was changing
;xdebug.remote_enable = 0 (default value in clean XAMPP installation)
to
xdebug.remote_enable = 1
did the trick
Adding an index.php did the trick for me.
I couldn't figure out why some of my projects would connect to the debugger and others wouldn't. Then I realized that the ones that wouldn't connect started with index.html. Once I renamed these files to index.php, the debugger connected with no problem.
I solved this using a windows -> remote LAMP server config after reading the following post, leaving the link in case anyone finds it handy:
http://stuporglue.org/setting-up-xdebug-with-netbeans-on-windows-with-a-remote-apache-server/comment-page-1/#comment-6227
Having just upgraded to the new Ubuntu 14.4 my NetBeans Xdebug stopped working. I've followed all the answers above to date to no avail.
I found a NetBeans Ubuntu statement that the /etc/php5/cli/conf.d/xdebug.ini file should have xdebug.remote_enable=on. When I checked the /etc/php5/cli/conf.d directory, I found no xdebug.ini file. However there was a link to /etc/php5/mods-available/xdebug.ini there.
Subsequent adding the xdebug.remote_enable=on to that file fixed the problem.
PS - This works on NetBeans 8.0.1
When I tried to debug the Yeoman WebApps powered by PHP backend in Netbeans, the status keep showing 'Waiting for connection'. There's probably because the index.html has nothing to do with php at all. It's only when I've triggered the ajax which needed PHP processing, the connection with xdebug immediately connected and debug as usual. Hope this give another perspective to someone as I have stumbled to 'think' there is a problem and trying to fix the ini.
An alternative is the Dephpugger project. Is like ipdb in python or byebug in Ruby.
https://github.com/tacnoman/dephpugger
Is very easy to use.
The code attempts to grab a test page for example Yahoo.com in this case. I am outputting the var_dump
http://jinimatics.com/test.php (this works)
http://jinimetrix.com/test.php (this does not)
(Curl is installed on both servers along with fairy recent Lamp Stack)
Try to compare whats installed and version differences.
check your server settings with phpinfo();
then you can change settings in php.ini
I'm having some issue with var_dump.i'm using xampp 1.7.3 on windows.
I think in previous version i could output a variable with var_dump without print "<pre>" print "</pre>" firebug is not installed on my firefox and i'm not using xdebug.
Formally i have even red colored and nicely formatted output.Now it's completly unreadable.Can anyonw give me a tips n how to correct that.And html_errors is on from what i saw in php_info.thanks for reading this.
You were using Xdebug before; you're not using it now. Without it, there are no colors, and there are no HTML line breaks (use nl2br, change the Content-type header to text/plain or put the output in a <pre> block).
See the "Variable Display Features" on the manual of Xdebug.
Un-comment this line in you php.ini file.
zend_extension = "D:\xampp\php\ext\php_xdebug.dll"
This topic helped me at the time I was working in PHP5. With a fresh install of Xampp (PHP 7+), xdebug is no longer installed. It must be done manually. Below the explanations :
Goto https://xdebug.org/wizard.php
Make a phpinfo(); on your project and paste it in the textarea on the xdebug website
It returns some informations on your system like Xdebug installed: no
Follow the instructions in the bottom of the results page
After the manipulation, if you check again your phpinfo();
This time we get Xdebug installed: 2.6.0. xdebug works !
I have PHP, IIS7, ReWrite Module for IIS and Zend all installed.
I can execute PHP pages just fine, even got PHPINFO showing up.
I setup a Zend quickstart app on IIS and when I open it this is what I see:
You can see from the source that it's not executing the <= portions.
Any idea what needs to change?
alt text http://www.gonrad.com/200902/zendiis.jpg
You need to enable shortags in your php.ini:
short_opentag = on
However, even though Zend's examples use the open tag, for portability you really should use the full echo statement as not all webhosts allow for short_opentag. The short tag might save a bit of time typing but may actually be worse in the long run.
make sure <? is enabled and not just <?php
if you use <?
php.ini --->short_opentag=On