I installed the phptidy plugin for Sublime Text 2 and tried to use it to clean up some ugly code like
$tdt="<td class=\"tit2\" ";
$linka='<a href="products.php?action=history5&item=';
while ($row=mysql_fetch_array($r))
{ extract($row);
But after running Php Tidy, a console flashed and it seems to have edited the entire file, but nothing actually changed. Does anyone know if the plugin below still works?
https://github.com/welovewordpress/SublimePhpTidy
I ran into the same problem. Console would open and close too fast to read what was going on.
Step 1: I opened up the Sublime Console (CTRL + ` on Windows)
Step 2: Reading the output gave me the hint. PhpTidy relies on php.exe being installed on your machine (duh)
This last step might seem obvious, but I was networked into another computer where the code lived and coding it over the wire. As such, when I ran phpTidy on my local machine, it failed due to the lack of php itself.
At first you must add the <?php ?> to beginning and end of your PHP file.
If you based-on Win, see the output of PHPTidy Processes on the 'Ctrl+`' Console.
There is a tip:
PhpTidy: calling php.exe -v returned: 0.
If it returns 1, maybe 'php.exe' wasn't found, add the path of your ‘php.exe’ to ENV.
Related
In my Symfony application I am using IntelliJ Ultimate + Xdebug + Vagrant VM with an remote debug setting in IntelliJ. In the Vagrant box there is PHP 7.2 and Xdebug 2.6 installed
When I start a debug session via browser, everything works fine. I can step through all my code perfectly.
But when I start a remote debug session inside VM via
XDEBUG_CONFIG="remote_host=10.10.0.1" PHP_IDE_CONFIG="serverName=abc" bin/console <command>
The Xdebug works also but it misses the lines in my local source code. In IntelliJ I am always one line ahead as the debugger seems to be. I can see it when for example a new variable is created in my local source code. Just one step later the debugger info shows me, that it was created. Another example: if I step over a code line I am suddenly on an empty line.
If I set the breakpoint as follows
$a = "abc";
o echo $a;
echo "test";
The debugger stops, but $a isn't initialized yet (as seen in the variables section). If I now step over
$a = "abc";
echo $a;
o
echo "test";
$a is initialized now, but not outputted by the echo command and the debugger is on an empty line.
Next step over leads to
$a = "abc";
echo $a;
echo "test";
o
and so on ...
The only tip I can find is: Check the path mapping. I am sure, the path mapping is really okay because it actually finds all the files I want to debug but it stops on the wrong line.
I also compared the files in my vagrant source code and my local source code. They are exactly the same. I think they cannot be out of sync cause the source code is shared with the VM via shared folder.
I also looked into Xdebug log file which tells me line numbers. These line numbers are exactly the same as in my local code, so nothing unusual here.
Strange is: The bin/console php file works correct, but classes instantiated from here does not.
Does somebody has a clue, what I can check else? Is there a known bug or anything else? Its no option to debug all my command line executed code via die() and print() commands ...
Does anybody know how to debug CLI PHP scripts from the CLI?!? I don't want to debug a PHP web page - I don't have a PHP web page. I don't want to debug a remote script either - I'm running/debugging right here on this system. I don't want to (at this time) try to get some IDE (Eclipse, PhpStorm or whatever) to debug a CLI PHP rather I just want to debug some PHP CLI script at the Linux command line itself. In Perl this would be simply perl -d <script.pl> <options>. Debugging a script, to me, is not figuring out compile errors or other simple things. To me it's setting break points, running code, examine the contents of variables and being able to arbitrarily execute or eval ('<php code>') at the debugger.
Sure later I'd like to configure this into my IDE of choice (at this time this is Eclipse) but I have not managed to get that working. Debugging from the CLI a PHP CLI script would be a good start for me.
Thanks.
I don't know why I'm limited to a character count when posting a comment. Perhaps I can add more text here.
Here's what I have tried in order to use xdebug and/or Zend debugger with Eclipse:
Base Eclipse version Mars.1 Release 4.5.
Eclipse PDT UI Plugin version 3.7.0.2015112
Tried installing xdebug using pecl install xdebug. Says I need to add "zend_extension=xdebug.so" to php.ini. Really? Which php.ini? I have several:
Andromeda:sudo find / -xdev -name php.ini
/etc/php5/cli/php.ini
/etc/php5/apache2/php.in
/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php53/php.ini
/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php.ini
/opt/eclipse/plugins/com.zend.php.debug.debugger.php56.linux.x86_64_13.0.1.v20151112-2045/resources/php56/php.ini
Andromeda:
I put the zend_extension thing in both /etc/php5/cli/php.ini and /etc/php5/apache2/php.ini. Made a phpinfo.php page and I see Xdebug in there (yea!). Configure a Debug Configuration in Eclipse to use xdebug and try to debug:
Launching renameUser has encountered a problem. An internal error occurred during "Launching renameUser" java.lang.NullPointerException.
Oh goodie...
I had also installed the Zend Debugger and added the following to those same two php.ini files:
zend_extension=/usr/lib/php5/20121212/ZendDebugger.so
zend_debugger.allow_hosts=127.0.0.1/32, 192.168.0.0/16
zend_debugger.expose_remotely=always
Changed debug configuration to use Zend Debugger and attempted to debug. Received:
Error launching 'renameUser' The debug session could not be started. Please make sure that the debugger is properly configured as a php.ini directive.
Restarted Eclipse and now the debugger attempts to run but simply terminates with a 255 exit value attempting to run /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi. Why it's runnign php-cgi is beyond me. I said this was a CLI not a CGI. In any event I get the following when trying to run this from the command line:
Andromeda:/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi
/opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/php5/php-cgi: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory
Found a libiconv.so.2 in /opt/eclipse/plugins/org.zend.php.debug.debugger.linux.x86_64_5.3.18.v20110322/resources/lib and set LD_LIBRARY_PATH to include that but this just fails to launch the debugger at all stating to make sure that the debugger is properly configured as a php.ini directive... UGH!
Other odd stuff:
When Eclipse starts up it fails to open my RSE based project thus displaying edit buffers from the last run as empty
Eclipse will no longer exit! Select File: Exit. Nothing happens. Click on the X in the title bar - nothing happens. Now I have to kill it to close it!
When debugging on the command line you need to tell PHP you want to debug also
http://xdebug.org/docs/remote
says
export XDEBUG_CONFIG="idekey=session_name"
php myscript.php
assuming xdebug is enabled (it doesnt matter which .ini file its in, but there is a standard place per OS for this, usually in a conf.d folder called xdebug.ini which is auto included)
This allows you to debug a cmdline script.
Personally I use Vim with Vdebug extention (xdebug for vim) to debug and nothing other than a command line is needed
What worked for me was using dephpugger. I found the steps to get CLI debugging working here:
https://hackernoon.com/how-debug-php-applications-with-dephpugger-98cc234d917c
I had previously installed xdebug and tried out exussum's answer.
The steps I followed are included here for completeness.
Install dephpugger:
composer global require “tacnoman/dephpugger”:”dev-master”
Put dephpugger on the path:
export PATH=$PATH:$HOME/.composer/vendor/bin
make sure to include in the php file at the breakpoint:
xdebug_break();
open up 2 terminal instances. In one run:
dephpugger debug
In the other run
dephpugger cli /path/file.php
replacing /path/file.php with the path to your file. if you need command line arguments to the php script put the path and arguments in quotes. It still seems a little hacky. I think the real trick is to write in a language that has a better debugger built in.
exussums answer works for me.
In addition I have the following in /etc/php/7.0/cli/conf.d/20-xdebug.ini
zend_extension=xdebug.so
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_enable=true
#xdebug.remote_enable=false
And I had to do this: https://github.com/vim-vdebug/vdebug/issues/363
Being able to set break points in a PHP script requires some kind of debugger extension being loaded, either XDebug or Zend Debugger.
And then you need some kind of interface to this debugger to make your wishes about break points known. I am unfamiliar with the Perl debugging, but I haven't heard about any PHP CLI based debugging - it is always taking place in an IDE that is able to handle the debugging protocol of one of the extensions.
Of course there is the good old var_dump();die('hi'); debugging, but this does not include continuing code execution after the script ended. ;)
I have a question regarding running a shell command via PHP. My goal is to successfully run compass compile [project] via PHP. I have tried the following:
echo system('compass compile [project]', $s); // prints [31m[0m
echo $s; // prints 1
echo passthru('compass compile [project]', $p); // prints [31m[0m
echo $p; // prints 1
echo shell_exec('compass compile [project]'); // prints [31m[0m
echo exec('compass compile [project]', $e, $ee);
print_r($e); // Array ( [0] => [31m[0m )
echo $ee; // prints 1
I even tried running a shell command to an executable file that contained compass compile test and I still got the same results as the trials above.
My questions
What does [31m[0m mean? Does this represent binary data? Do these represent bash colors as search engines suggest?
As far as I know, the output should be the following:
For kicks, I tried to execute via system(/usr/local/bin/compass compile [project]); and I got the same result. I double checked my path so I know I can execute these commands as expected. Here is the output from echo $PATH:
/usr/lib/lightdm/lightdm:
/usr/local/sbin:
/usr/local/bin:
/usr/sbin:
/usr/bin:
/sbin:/bin:
/usr/games:
/usr/local/games:
/var/lib/gems/1.9.1/bin
Is there a way to compile compass projects using PHP?
I've seen a similar error before.
Typically it is due to the things being output in the bash startup scripts. For example, I had an echo in one of my bash startups that jacked up a lot of scripts till I realized what was causing the problem.
Or, perhaps the user (www-data ?) doesn't actually have a home dir and appropriate startup scripts in place?
You can try this to get a non interactive shell:
exec("/bin/bash -c \"compass compile [project]\"", $e, $ee);
print_r($e);
echo $ee;
If you still have issues, try redirecting the output to a tmp file, an checking it:
exec("/bin/bash -c \"compass compile [project] > /tmp/compass.compile.output\"", $e, $ee);
print_r($e);
echo $ee;
See also: What's the difference between .bashrc, .bash_profile, and .environment?
The issue was fixed by using sass --compass and redirecting the stderr to stdout via echo shell_exec("sass --compass [project] 2>&1");
It was a pretty long and arduous process figuring this out since it's been awhile since I've dabbled in command line programs. Remember that error streams and output streams might be on different outputs. The easiest way to test this is to shovel the output into a file via:
# do this once with a good file and once with a file that will give errors
sass --poll style.scss > output.txt
If output.txt is empty then the error output is on the stderr stream such as the case above. We can correct this by redirecting the stderr to the srdout. For example:
sass --poll > output.txt 2>&1
#shows results
cat output.txt
I created a simple PHP script that redirects the output from one textarea to the other. The code can be found here.
First guess would be a permissions issue. Odds are the user account running PHP (unless you're running this from the command line, I'm guessing that this is the user that the httpd apache daemon is running under) doesn't have the permissions to do what you're asking. The errors are extremely unhelpful, however.
From what I can tell, it looks like an attempt to have the error show up in red on the command line. My guess is that there are hidden (or somehow never printed out) characters in-between the codes. Check out some of your apache and/or PHP error logs to see if anything helpful is showing up there that never made it into the PHP variable. Or, for kicks, try copy and pasting the output with the bash colors into a basic text editor and first delete each character from the beginning one by one... see if anything magically appears. If that doesn't work, try the same in reverse, backspacing from the end. Either way, there's an error occurring, so important that it must show in bold red letters to you, it's just not getting to you.
If it does in fact turn out to be a permissions issue, and it's one you can't remedy through permissions wrangling, you could create an intermediary file that your Apache user has permissions to write to, and your cron user has permissions to read from. Instead of running the code directly from PHP, put it in the file, then run a cron on a frequent basis looking for anything in that file, CHECKING IT FOR VALIDITY, and then running it through the compiler and removing it from the file.
It'd be ugly, but sometimes pretty things don't work.
You guessed it right it is colors but the way it is defined is not right. For more information regarding using colors in console please refer to this document. Also, for compiling SCSS via compass you can use shell_exec command in linux. For more information regarding shell_exec please refer to this document. Let us know how it goes.
I have netbeans setup with xdebug so it can debug php. However, this only works if I create a php project. It will not work if I try opening a stand alone php file. So my question is, is it possible to debug a stand alone php file which is not part of a netbeans php project?
If that is not possible, how do I debug stand alone php files with netbeans?
No, There is none that I am aware of. As Myrddin mentioned the debugger needs some configurations that is a part of netbeans project.
but the best way you can debug a single file is to copy it on a project folder, and click the debug project, once the debug session is set then you can browse the PHP File that you want to debug and it will actually go through xdebug.
Good Luck!
Each project can have it's own configuration (you can have 1 project that has PHP5.4 interpreter, one the is PHP5.6, one that is a command line and another that is a web project), but if you configure a general PHP 5 Interpreter:
If you work on a windows machine you can use this code (filename is php.cmd)
set XDEBUG_CONFIG="idekey=netbeans-xdebug"
#php.exe %*
If you want to be able to debug, your interpreter should have the XDEBUG_CONFIG system variable and make sure it's connected to netbeans. You should set this to the same value in your Debbugging section of the PHP's config:
Next thing - if you right click inside the editor you will have the Debug File option, and a prompt window will pop:
You don't really need anything here. Just hit the "OK" button.
As you can see, this final result is debug session of the t1.php file within c:\TEMP\ (which is not a working project):
Short answer: CTRL + SHIFT + F5
You can find the answer here:
https://blogs.oracle.com/netbeansphp/entry/run_file_without_project
I'm not entirely sure, but I think it is not possible, because you need some configuration to get the debugging working, and this configuration is part of a project.
You can always use print_r and var_dump to debug a single file. But that is probably not the answer you're looking for.
xdebug is very heavy and old tool you can use Kint php debuger here.
its free, so you can download Here
it's pretty replacement for var_dump(), print_r() and debug_backtrace().
you need to add kint.class.php file using include or require function.
require '/kint/Kint.class.php';
that's it.
and you can use like
########## DUMP VARIABLE ###########################
Kint::dump($GLOBALS, $_SERVER); // pass any number of parameters
// or simply use d() as a shorthand:
d($_SERVER);
########## DEBUG BACKTRACE #########################
Kint::trace();
more help is available on https://github.com/raveren/kint/
Good Luck :)
I am using xdebug plugin for vim. After making few changes i was able to run debugger but not able to set breakpoints.
So, I enabled xdebug.remote_log and below is the log statements corresponding to setting breakpoint.
<- breakpoint_set -i 5 -t line -f file:///C:\htdocs\testLocal.php -n 36
->
Its issuing request to debugger in proper format only but no idea why debugger is returning "command is not avilable".
Please let me know if anything is wrong.
Make sure you set breakpoints on lines that contain a php expression, not on blank lines or lines containing just a closing bracket.
Setting breakpoints on blank lines doesn't work, and returns the cryptic 'command not found' error you are getting.
I had the same problem. When I checked the xdebug logs, it showed file:///http://myapp.local
As you see my ide (PHP eclipse) seems to insert the extra "http://" treating this as a URL instead of a file.
Luckily, this was the case with just my index.php. Other file breakpoints were being communicated correctly to xdebug and I was able to set and hit breakpoints on php expression as long as they didn't know span multiple lines. The latter for some reason would cause breakpoints to not hit and just pass by.
Hope this helps!
I spotted an extra "/" in "file:///C:\htdocs\testLocal.php", mayby the vim plugin isn't compatible with windows filepaths?
I recently just installed this same thing and found a tutorial by Blake Johnson all about installing and using Xdebug from within Vim.
Also, try clearing any cookies on the page you might have. This often times would cause the plugin to get screwed up in a strange way.