So, I was quite happily debugging my PHP code with PhpStorm - until Windows became severely corrupted ... and my backup regime turned out to not quite as good as I had thought (let that be a lesson to many of us :-( )
Here's the relevant part of my php.ini:
[PHP]
[Xdebug]
; ---- trying to follow PHP storm's advice
zend_extension = "e:\coding\Web_development\php\php\ext\php_xdebug-3.0.1-7.3-vc15-x86_64.dll"
xdebug.remote_enable = 1
xdebug.remote_handler = dbgp
xdebug.remote_host = 127.0.0.1
;xdebug.remote_port = 9000
;xdebug.remote_mode = req
xdebug.idekey="xdebug"
; ---------- previously worked
;xdebug.remote_enable=1
;xdebug.remote_host=127.0.0.1
;xdebug.remote_port=9000
;xdebug.remote_autostart=1
;xdebug.remote_handler=dbgp
;xdebug.idekey="xdebug"
;xdebug.remote_log=m:\xdebug.log
;xdebug.profiler_enable=0
;xdebug.profiler_enable_trigger=0
;;xdebug.profiler_output_dir="F:\DropBox\programs\xampp\htdocs\_PHP_profile"
;xdebug.profiler_output_name=cachegrind.out.%s.%t
And, here's what PhpStorm says :
BUT much of that does not actually exist at https://xdebug.org/docs/all_settings - as if some of those settings are no longer relevant/supported.
So, can anyone post the relevant [Xdebug] portion of php.ini for PHP storm 2020.1 ?
The upgrade that's catching you out here is not PhpStorm, it's XDebug: XDebug 3.0 came out a couple of weeks ago, and has completely overhauled the settings. As mentioned in one of the messages in your screenshot there is an upgrade guide on the XDebug site
It looks like PhpStorm's checking script isn't fully updated yet, so it's recommending a confusing mixture of old and new settings.
The most important changes are:
The new xdebug.mode setting toggles a whole bunch of settings at once rather than having to remember the right combination. Some settings are simply no longer needed because of this.
The default port is now 9003 instead of 9000, because of some other popular software using the same port.
A lot of remaining settings have been renamed to be clearer.
Looking down your old config:
zend_extension = "e:\coding\Web_development\php\php\ext\php_xdebug-3.0.1-7.3-vc15-x86_64.dll"
; this tells PHP to load the XDebug extension
; note that the file name includes the version number, confirming that you're using v3
xdebug.remote_enable=1
; now implied by xdebug.mode=debug
xdebug.remote_host=127.0.0.1
; renamed xdebug.client_host
xdebug.remote_port=9000
; renamed xdebug.client_port
; also, the default is now 9003 not 9000
; so either set to 9000 here, or tell PhpStorm to use port 9003
xdebug.remote_autostart=1
; replaced with xdebug.start_with_request=yes
xdebug.remote_handler=dbgp
; no longer needed, as there was only one valid value
xdebug.idekey="xdebug"
; still supported, but not usually needed
xdebug.remote_log=m:\xdebug.log
; replaced by xdebug.log
xdebug.profiler_enable=0
; now implied by xdebug.mode=debug
xdebug.profiler_enable_trigger=0
; now implied by xdebug.mode=debug
xdebug.profiler_output_dir="F:\DropBox\programs\xampp\htdocs\_PHP_profile"
; not needed for debugging
xdebug.profiler_output_name=cachegrind.out.%s.%t
; not needed for debugging
So your new config should I believe look like this:
zend_extension = "e:\coding\Web_development\php\php\ext\php_xdebug-3.0.1-7.3-vc15-x86_64.dll"
xdebug.mode=debug
xdebug.client_host=127.0.0.1
xdebug.client_port=9000 ; or 9003, but should match the setting in PhpStorm
xdebug.start_with_request=yes
xdebug.idekey="xdebug"
xdebug.log=m:\xdebug.log
Related
I used to have PhpStorm working brilliantly on my computer. No browser extensions. I could put breakpoints anywhere, go to some URL in browser, hit enter and then I would automatically be taken to breakpoint in given file. Files in project would open up automatically as I stepped through code.
Now, it is a total mess.
First here is my Xdebug info in the xdebug.ini (I don't specify anything Xdebug related in the php.ini):
zend_extension=/usr/local/php5/lib/php/extensions/no-debug-non-zts-20151012/xdebug.so
[xdebug]
xdebug.remote_enable=on
xdebug.default_enable=on
xdebug.remote_port=9000
xdebug.remote_host=localhost
If I run php -v I get
PHP 7.0.15 (cli) (built: Feb 13 2017 10:30:54) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.15, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans
iMac:xdebug-2.7.2 $
phpinfo() shows corresponding values set based on my .ini.
In PhpStorm I have PHP CLI set to 7.0, it is showing Xdebug 2.7.2.
Curious about that "Can't load xdebug" message, but php -v doesn't show same message. At first I had zend_extension defined in both php.ini and the xdebug .ini and would see that message when doing php -v but after removing from php.ini the message went away from php -v.
I have no idea if I need to do anything under Debug settings in Build, Deployment, but here is what is there by default:
Also, I have my project set to sync with a remote server but for debugging I don't want to use path mappings. That is how I had it before and PhpStorm messages about debug session ending and no path mappings found was never a problem.
Here is my Run->Config
In the past, I didn't worry about a start URL. No matter what URL I entered in browser it triggered debugging.
And here is what I have tried regarding path mappings:
I did that to see if it would fix things, but no.
My gut feeling says it is either a problem with Xdebug settings, my run->config, or the fact that I am using a virtual host and somewhere there is a localhost entry causing a problem.
So I am at a loss. If I select Listen for incoming... and go to URL, the focus does not go to PhpStorm with current breakpoint. I see in browser that things stopped and I go to PhpStorm and see that debug was triggered. But the second I hit step over or step into the debugging just ends.
Anything glaringly wrong with what I am doing?
Edit: Here is what I see in the xdebug log:
[89603] W: Creating socket for 'dev.courses.com:9000', poll success, but error: Operation now in progress (19).
[89603] E: Could not connect to client. :-(
[89603] Log closed at 2019-10-21 10:42:37
[89603]
[89603] Log opened at 2019-10-21 10:42:37
[89603] I: Connecting to configured address/port: dev.courses.com:9000.
[89603] W: Creating socket for 'dev.courses.com:9000', poll success, but error: Operation now in progress (19).
[89603] E: Could not connect to client. :-(
[89603] Log closed at 2019-10-21 10:42:37
Not sure the specifics of the error... Maybe this hints at something? The question I have is where in the config do I specify localhost vs my virtual host alias? Maybe that is what is messing things up?
You can find out what Xdebug is trying to do by using the xdebug.remote_log=/tmp/xdebug.log setting. This log will indicate which connection attempts are being made, and why they succeed or not.
Ok, so this turned out to be an xdebug issue, though not obvious at first.
Originally I didn't think to check the PHPStorm log. But the PHPStorm log showed
Argument for #NotNull parameter 'remoteFileUrl' of com/jetbrains/php/debug/xdebug/debugger/XdebugDriver.onBreak must not be null
Searching above error took me to
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360001498520-xdebug-works-only-with-first-line
Turns out my version of PHPStorm is known to not work with xdebug 2.7 so I downgraded to 2.6.1 and all is well :-)
thanks,
Brian
I'm working on a Perl6 project, but having difficulty connecting to MySQL. Even when using the DBIish (or perl6.org tutorial) example code, the connection fails. Any suggestions or advice is appreciated! User credentials have been confirmed accurate too.
I'm running this on Windows 10 with MySQL Server 8.0 and standard Perl6 with Rakudo Star. I have tried modifying the connection string in numerous ways like :$password :password<> :password() etc. but can't get a connection established. Also should note that I have the ODBC, C, C++, and.Net connectors installed.
#!/usr/bin/perl6
use v6.c;
use lib 'lib';
use DBIish;
use Register::User;
# Windows support
%*ENV<DBIISH_MYSQL_LIB> = "C:/Program Files/MySQL/MySQL Server 8.0/liblibmysql.dll"
if $*DISTRO.is-win;
my $dbh = DBIish.connect('mysql', :host<localhost>, :port(3306), :database<dbNameHere>, :user<usernameHere>, :password<pwdIsHere>) or die "couldn't connect to database";
my $sth = $dbh.prepare(q:to/STATEMENT/);
SELECT *
FROM users
STATEMENT
$sth.execute();
my #rows = $sth.allrows();
for #rows { .print }
say #rows.elems;
$sth.finish;
$dbh.dispose;
This should be connecting to the DB. Then the app runs a query, followed by printing out each resulting row. What actually happens is the application hits the 'die' message every time.
This is more of a work around, but being unable to use use a DB is crippling. So even when trying to use the NativeLibs I couldn't get a connection via DBIish. Instead I have opted to using DB::MySQL which is proving to be quite helpful. With a few lines of code this module has your DB needs covered:
use DB::MySQL;
my $mysql = DB::MySQL.new(:database<databaseName>, :user<userName>, :password<passwordHere>);
my #users = $mysql.query('select * from users').arrays;
for #users { say "user #$_[0]: $_[1] $_[2]"; }
#Results would be:
#user #1: FirstName LastName
#user #2: FirstName LastName
#etc...
This will print out a line for each user formatted as shown above. It's not as familiar as DBIish, but this module gets the job done as needed. There's plenty more you can do with it to, so I highly recommend reading the docs.
According to this github DBIish issue 127
The environmental variable DBIISH_MYSQL_LIB was removed. I don't know if anyone brought it back.
However if you add the library's path, and the file is named mysql.dll, it will work. Not a good result for the scientific method.
So more testing is needed - and perhaps
C:\Program Files\MySQL\MySQL Server 8.0\lib>mklink mysql.dll .\libmysql.dll
Oviously you can create your own lib directory and add that to your path and then add this symlink to that directory.
Hope this helps. I've spent hours..
EDIT: Still spending time - accounting later.
Something very transitory is going on. I reset the machine (perhaps always do this from now on), and still got the missing mysql.dll errors. Tried going into the MySQL lib directory to execute raku from there.. worked. changed directories.. didn't work.
Launched administrator cmd - from home directory, tried the raku command. Worked. Ok - not good, but perhaps consistent. Launched non admin cmd, tried it from the MySQL lib directory, worked. And just for giggles, tried it outside of that directory.. worked.
Now I can't get it not to work. Will explore NativeLibs::Searcher as Valle Lukas suggested!
Maybe the example in the dbiish repository is not valid anymore.
The DBIISH_MYSQL_LIB Env seems to be replaced by NativeLibs::Searcher with commit 9bc4191
Looking at NativeLibs::Searcher may help to find the root cause of the problem.
I've followed all the suggestions I've found, but I can't get PhpStorm working with PHP 7 and xDebug. I did have it working with PHP 5.6.
Xdebug is being loaded by PHP. I verified in the phpinfo() output. I've switched PhpStorm to use the PHP 7 version and it also lists the correct debugger as xdebug 2.4.0RC3
My xdebug settings are:
zend_extension = "/usr/local/opt/php70-xdebug/xdebug.so"
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.remote_host = 127.0.0.1
xdebug.scream = 0
xdebug.cli_color = 1
xdebug.show_local_vars = 1
xdebug.idekey = PHPSTORM
I have the xdebug chrome extension installed, and it's correctly adding the Cookie:XDEBUG_SESSION=PHPSTORM;. I also enabled the debugging listener in PhpStorm.
Can anyone suggest what else I can do to try get my breakpoints to trigger?
So, in my case, I found that by moving the port from 9000 to 9001 fixed. I guess something else was already using the default port. Problem solved!
In case someone else lands here. For me the solution was that the path to the binary wasn't using "quotes".
[xdebug]
zend_extension = "C:\wamp\bin\php\php7.0.16\ext\php_xdebug-2.5.1-7.0-vc14-x86_64.dll"
Okay, so I've been testing and building a website on my computer through localhost. Everything works fine on my computer! I wanted to then upload it to my godaddy hosting account. Then I get an error. I am using json_decode as an argument for one of for each loops in my php. When I'm running my site through a hosting provider it tells me there is an invalid argument in the foreach() loop on like 43. So, I knew it had to do with my php.ini file, so I copied the one from my computer and pasted it in the php.ini file on godaddy, for my site. Then the foreach() loop worked! But, then all kinds of hell broke loose. Session problems and such. So, my question is, what do I need to add to make json_decode work?
Thanks
Here is my php.ini file with the hosting provider:
register_globals = off
allow_url_fopen = off
expose_php = Off
max_input_time = 60
variables_order = "EGPCS"
extension_dir = ./
extension=json.so
upload_tmp_dir = /tmp
precision = 12
SMTP = relay-hosting.secureserver.net
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
; Only uncomment zend optimizer lines if your application requires Zend Optimizer
support
;[Zend]
;zend_optimizer.optimization_level=15
;zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.3
;zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3
;zend_extension=/usr/local/Zend/lib/Optimizer-3.3.3/ZendExtensionManager.so
;zend_extension_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.3/ZendExtensionManager_TS.so
; -- Be very careful to not to disable a function which might be needed!
; -- Uncomment the following lines to increase the security of your PHP site.
;disable_functions = "highlight_file,ini_alter,ini_restore,openlog,passthru,
; phpinfo, exec, system, dl, fsockopen, set_time_limit,
;
You cant just replace the php.ini file because it has paths hard coded.
For example, with your session error, most likely the setting session.save_path is referencing a directory that doesn't exist or incorrect permissions.
Can you post the line of code that was on line 43? I am guessing that your local php.ini doesn't display the error whereas the godaddy config does.
I installed the XDebug package at MAMP/bin/php5.2/lib/php/extensions/no-debug-non-zts-20060613
I put the following into my php.ini file:
zend_extension="/Applications/MAMP/bin/php5.2/lib/php/extensions/no-debug-non-zts-0060613/xdebug.so"
xdebug.remote_enable = On
xdebug.remote_autostart = 1
xdebug.remote_host = localhost
xdebug.remote_port = 9999
I disabled the zend optimizer.
I set the proper port # in MacGDBp.
I do get a proper stack trace from the command line.
What I'd like to do, though, is load a page in Firefox and debug with MacGDBp.
Shouldn't MacGDBp be reading and parsing whatever's coming though the specified port?
Can anyone tell me what I'm missing?
Thanks!
Well, you are a bit unspecific about your concrete setup but there seem to be few things odd with your settings.
I am not using mac and I don't know MacGDBp ... but MacGDBp suggests that it uses the old GDP-protocol. Though XDebug 2 uses by default the new DBG protocol.
You should make that explicit by setting 'xdebug.remote_handler' to your preferred protocol. In my case as I use the new protocol i feed it 'dpgp.
Here you find some information: http://www.xdebug.org/docs/remote
Also it could be that your firewall is blocking the port.
Maybe that'll do it, otherwise tell us more about the symptoms.
Best
Raffael
I was having the same problem.
What I did was:
install the xdebug-toggler plugin for Safari
load the page I was testing
enable the plugin
reload the page
And suddenly it worked.