I've found that when executing php via cli php has access to custom windows system environment variables, but not when IIS runs php.
For example, I can put this in php.ini:
zend_extension="${PHP_PATH}ext\php_xdebug-2.5.5-7.1-vc14-nts.dll"
and php loads xdebug properly when called via cli:
c:\>php.exe -v
MSVC14 (Visual C++ 2015) x86 ) Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.1.1, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.5.5, Copyright (c) 2002-2017, by Derick RethansPHP 7.1.1 (cli) (built: Jan 18 2017 18:50:48) ( NTS
But Xdebug doesn't appear when I call phpinfo() on a page served by IIS. I'm assuming it's because IIS doesn't have access to the custom system variable I created. Can someone show me how to make those variables accessible in IIS, preferably in a way that I can script (whether that be via batch file, power shell or whatever) for automated deployments.
So I found that when executing setx from the command line or a batch file like:
setx PHP_PATH {path to php here}
it creates the system variable in the user space. Since IIS doesn't have access to it, php.ini variables can't be expanded. However, if you pass the /M flag, like the following:
setx /M PHP_PATH {path to php here}
this creates a variable in the global space that IIS does have access to.
Related
I'm trying to call json_decode(). I'm using a shared Hostgator server. I have already checked some other questions on StackOverflow regarding "json_decode"
After ssh-ing in, php -v outputs the following:
PHP 7.4.16 (cli) (built: Mar 9 2021 17:55:07) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with the ionCube PHP Loader + ionCube24 v10.4.5, Copyright (c) 2002-2020, by ionCube Ltd.
and when I search the PHP modules using php -m it does appear to have the line
json
in the output
Try this:
Create a file in the servers web root called phpinfo.php and add the following to it:
<?php
phpinfo();
?>
Go to phpinfo.php in your web browser to confirm that JSON is installed, and that the web server is using the same version of PHP as the CLI version.
In server, it shows 7.0 php like below from either cPanel
or cat /etc/apache2/conf.d/php.version in server
However in php --version, it shows php5.6.
How can I upgrade my php to 7.0? Thanks.
If you change PHP version from cpanel account it will be applied and your website will use the new version.
php -v command shows the default version of PHP for your system but if you want to check PHP version for your cpanel account only you have to modify your ~/.bashrc file:
alias php="/opt/cpanel/ea-php70/root/usr/bin/php"
and then:
source ~/.bashrc
Now you'll find the output some thing like:
php -v
PHP 7.0.33 (cli) (built: xxxxxx) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.33, Copyright (c) 1999-2017, by Zend Technologies
For some reason my phpldapadmin doesn't want to work with my website and it says "If you are seeing this in your browser, PHP is not installed on your web server!!!" Which is not true as if the info.php file is navigated to like here it says php is enabled along with the ldap extension. The apache error log doesn't say anything about the error though.
Every other php page on my website works except phpldapadmin. I am really confused.
This is what I get when I run php -v
PHP 7.1.1-1+deb.sury.org~xenial+1 (cli) (built: Jan 20 2017 09:20:20) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.1.1-1+deb.sury.org~xenial+1, Copyright (c) 1999-2017, by Zend Technologies
with Xdebug v2.5.0, Copyright (c) 2002-2016, by Derick Rethans
Your webserver's document root is /var/www/html and you have to place everything within this folder (may use subfolders /var/www/html/phpmyadmin, /var/www/html/phpldapadmin, etc.). Or you can define alias for certain purposes which can point to a folder outside document root. How to config an alias: https://httpd.apache.org/docs/2.4/mod/mod_alias.html#alias
Everything else what's outside isn't accessible by webserver itself and neither can be processed by PHP.
I am using SublimeText to run PHPUnit tests continuosly. Works great, but now I stumbled upon something strange. I updated to the latest PHP version via Homebrew and if I open a Terminal session and type php -v, this is what I get:
PHP 5.6.7 (cli) (built: Mar 22 2015 19:03:55)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
The shell instance that is used by SublimeText seems not to use this version of PHP. If I do the same there (via writing echo shell_exec('php -v');die(); into a PHPUnit test), I get this:
PHP 5.4.24 (cli) (built: Jan 19 2014 21:32:15)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
I tested around a bit and found out, that automator puts out the same if I run a shell script in \bin\bash shell via automator's 'run shell script' action.
How to tell /bin/bash to use the newly installed PHP version?
When you issue the command $ php, the PATH is searched for the binary. You can find out which one will be executed with the command $ which php.
If you want to explicitly run one or another php binary when multiple ones are installed, use full absolute path to the binary, e.g. $ /opt/php5.6/bin/php.
I recently updated my linux mint via the automatic updater. I had the problem, that it did not execute php scripts. After re-installing libapache-mod-php5 some php started to work. Yes, just some, as phpinfo() is executing properly, but another php file, which works correctly on other machines, and was working on mine too, is now producing the following error in resopnse to an $.ajax call: status: parsererror errSyntaxError: Unexpected token <. what happens is it returns the php file without executing it, even though it executes other php files.
My configs are the following:
Server version: Apache/2.4.6 (Ubuntu)
PHP 5.5.1-1~precise+1 (cli) (built: Jul 22 2013 07:33:14)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies
with Zend OPcache v7.0.2-dev, Copyright (c) 1999-2013, by Zend Technologies
The problem was that after the update the php.ini got overwritten and it was not interpreting shortcode. The solution is to set
short_open_tag=On
in the php.ini as suggested here.