When using the browswer preview option in PHPStorm, I get to:
http://localhost:63342/projectName
Is there a way to configure that to be:
http://localhost:8888/projectName ?
For PhpStorm v8.0.1 and older: Settings | Debugger
For PhpStorm v8.0.2 and newer: Settings | Build, Execution, Deployment | Debugger
Related
Has anyone had success using LXD on Fedora 31? I have been using it on another machine with Fedora 30 just fine, but after installing Fedora 31 on a new laptop, the containers don't get an IPv4 address:
$ lxc list
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
+-------+---------+------+------+------------+-----------+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+-------+---------+------+------+------------+-----------+
| c1 | RUNNING | | | PERSISTENT | 0 |
+-------+---------+------+------+------------+-----------+
Attempting something like ping inside the container gives the error:
connect: Network is unreachable
Nothing works that needs the network, but otherwise the containers seem fine and the network is fine on the host laptop.
The one notable difference I see is the warning on Fedora 31:
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
The version of LXD is 3.18 on both machines (installed using snap), and I've compared with both environments but couldn't see any glaring differences that would point to a problem other the cgroup warning.
This is what the network bridge looks like:
$ lxc network show lxdbr0
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
config:
ipv4.address: 10.192.103.1/24
ipv4.nat: "true"
ipv6.address: none
description: ""
name: lxdbr0
type: bridge
used_by:
- /1.0/containers/c1
managed: true
status: Created
locations:
- none
Any ideas on where to start looking?
According to the official documentation:
sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
I found the fix to the problem. Turns out that cgroup v2 warning was more than just a warning. If cgroup v2 is disabled, it works as expected.
To disable cgroup v2, add the following to the linux boot line:
systemd.unified_cgroup_hierarchy=0
There may be other ways to fix it, but this works for now.
Using MacOS Sierra, PhpStorm and Xdebug, web application configured on port 80 (not running from PhpStorm).
When browsing to localhost:80/index.php, PhpStorm won't stop on breakpoint, when accessing the external IP 192.168.1.2/index.php, PhpStorm hits the breakpoint.
I would like to use localhost for debugging instead of the external IP.
Is there a way to make PhpStorm to work with localhost?
P.S. Visual Studio Code works in both scenarios (therefore I believe Xdebug and PhpStorm are working good).
[xdebug]
zend_extension = /usr/local/Cellar/php56/5.6.29_5/lib/php/extensions/debug-non-zts-20131226/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.idekey=vagrant
xdebug.remote_host=0.0.0.0
Tried to set xdebug.remote_host to 127.0.0.1 and localhost, same behavior.
When debugging localhost:80, xdebug log show:
Log opened at 2017-01-03 14:06:36
I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to ::1:9000.
W: Creating socket for '::1:9000', poll success, but error: Operation now in progress (19).
E: Could not connect to client. :-(
Log closed at 2017-01-03 14:06:36
When using VS Code, there is no error and xdebug shows instead I: Connected to client. :-)
Setting xdebug.remote_connect_back to 0 (the default value) solved the issue.
Xdebug documentation:
If enabled, the xdebug.remote_host setting is ignored and Xdebug will
try to connect to the client that made the HTTP request. It checks the
$_SERVER['HTTP_X_FORWARDED_FOR'] and $_SERVER['REMOTE_ADDR'] variables
to find out which IP address to use.
When Xdebug tried to connect to localhost, it used TCPv6, which PhpStorm doesn't support.
Changing remote_connect_backto 0 caused Xdebug to use the remote_host value, using TCPv4, which PhpStorm supports.
Given a sample script that opens /dev/tty:
# sample.rb
tty=File.open("/dev/tty", "w+")
tty.print "> "
tty.puts tty.gets.upcase
I can run it with normal jruby just fine:
% jruby sample.rb
> hello
HELLO
%
However, if I try to use /dev/tty with nailgun, then the tty is bound to the nailgun server, not the client:
# server terminal | # client terminal
% jruby --ng-server |
NGServer 0.9.1 started on all interfaces, port 2113. |
| % jruby --ng sample.rb
> hello |
HELLO |
| %
(the vertical spacing is to show timing, the actual output for each lacks the blank lines)
Is this expected behaviour, or a bug?
If it's expected behaviour, is there a way I can detect whether a script is being run with --ng so I can
avoid opening /dev/tty?
Looking at the Nailgun client/server protocol, it doesn't look like it supports what would need to happen to use the client's /dev/tty (have client open a file, read/write from client to server).
Whether it's a bug or not, it's outside the capabilities of Nailgun currently.
Detecting whether we're on a Nailgun server can be done via
# true if on a nailgun server, false elsewise
system("ps -fp #{Process.pid} | grep NGServer > /dev/null")
PHPStorm has a nice File Transfer log:
[24.07.2014 12:36] Upload to server.net
[24.07.2014 12:36] Upload to server.net completed in less than a minute:
1 file transferred (36,4 Kb/s)
Anyway I could make it show the name of the file it transferred?
Settings/Preferences on Mac | Build, Execution, Deployment | Deployment | Options
Change Operations logging level to a more detailed one (Details).
Select File | Settings for Windows or select File | Default Settings for set option for all projects.
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.