When I check phpinfo(), I see /usr/local/php4/lib/php.ini
That means PHP4, right?
But When I execute the line of code below, it returns PHP5. WTF? I thought PHP4 did not have the DOMDocument class. I need to test for PHP4 and do a workaround, but this specific test is confusing me. Is there another more foolproof way to check for PHP4 in script?
if (is_admin() && class_exists('DOMDocument')) {
echo "PHP5";
} else {
echo "Awe PHP4";
}
The version of your PHP is listed right on top of any phpinfo() output. You can also determine it by echoing phpversion() or from CLI with php -v.
Apart from that, no. PHP4 does not support DOMDocument (at least not the one you are refering to). The old DOM XML extension has a similar named class though.
Try the following:
echo extension_loaded('domxml') ? 'old' : 'new';
phpinfo() is a cool function :)
edit, lots of similar functions here
http://www.php.net/manual/en/ref.info.php
you seem like you'd be interested in
phpversion() and version_compare()
The correct way to check your PHP version from phpinfo() is to read the header at the very top, but when doing checks in PHP code, checking php_version() is the way to do. There is also a predefined constant PHP_VERSION.
Well if phpinfo says you run php5 you are running php5. assuming by php_info you mean phpinfo.
you may wanna check the function phpversion
The path you are referring to is just the configured config file which could be anything.
You probably updated and kept it ages ago.
Related
I recently upgraded from php4 to php5 and with it came the notice that all my remote php file access no longer worked. I've been doing quite a bit of research into this and I dont seem to have a clear answer as to what is the correct way to include remote urls in php5.
The first example is to include the file this way
<?php
$data = file_get_contents("http://example.com/example.inc.php",0);
echo $data;
?>
The 2nd is this way
<?php
$ch = curl_init("http://example.com/example.inc.php");
curl_exec($ch);
curl_close($ch);
?>
and 3rd is to set in my php.ini file
allow_url_include = On
allow_url_fopen = On
and use the good old
<?php include_once('http://example.com/example.inc.php');?>
I want to do this right and secure.
All solutions are correct and there is no real difference in safety AFAIK.
I think the difference can be summed up like this:
The ini-settings provide the behaviour as known from prior versions. The reason why they are disabled by default is the security thread, but that is equal to all three solutions. Including remote files is a security problem, regardless of whether you control the rmeote site or not.
file_get_contents() and the curl extension creates some overhead, since you have to buffer the content, but for php include files that is more a cosmetic thing. Their usage is slightly more complex when reading through a script. But the buffering also adds benefits: you might create a local cache for example or a checksum towards a basic plausibility check. Also a syntax check prior to execution is possible thus preventing the crash of your calling script.
Curl is provided as a php extension. So the curl solution only works when the extension is installed, but it offers a much higher grade of freedom, much more options. If you don't require those stay with the builtin functions.
Well,
First method => Is correct and you shouldnt worry using it.
Second method= > Is correct, but curl extension should be enabled
Third method => Is correct, but using this option is not recommended because enabling allow_url_include likely makes your site vulnerable. For more detail see http://en.wikipedia.org/wiki/Include_vulnerability and this link http://wiki.dreamhost.com/Allow_url_include
I am writing a class that detects whether cURL is available, does one thing if it is, and another if it isn't. I therefore need to know how to disable cURL temporarily to test this class. I do not want to change the PHP INI file. Any ideas much appreciated.
Just wondering, Im writing an alternative for if cURL is unavailble, how likely is this? Am I wasting my time. Is cURL usually available?
Curl is enabled / disabled in your php.ini. You can't enable and disable it any other way.
Open php.ini find the below and put a semi colon before it to comment it out:
extension=php_curl.dll
AFAIK there is no way to do this at run time, because modules are loaded during PHP startup, before any of you code is executed. The only way to do it is by disabling (or rather, not enabling) an extension in php.ini. You probably can't even do that with cURL, as it will probably be compiled in, not dynamically loaded.
Having said that - why not just change the check to test your "if not available" code - presumably you have a block something like this:
if (curl_exists()) { //obviously there is no such function, but you must have some condition that determines this
// Do stuff using curl
} else {
// Do something horrible
}
well, just change it to this temporarily:
if (!curl_exists()) {
// etc etc
I think the best option is to change your detection script to allow disabling it with a manual configuration.
You cannot disable function on the fly. You need to change php.ini for that.
http://www.php.net/manual/en/function.dl.php
dl — Loads a PHP extension at runtime
bool dl ( string $library )
Loads the PHP extension given by the parameter library.
Use extension_loaded() to test whether a given extension is already available or not. This works on both built-in extensions and dynamically loaded ones (either through php.ini or dl()).
Warning:
This function has been removed from some SAPI's in PHP 5.3.
<?php
// Example loading an extension based on OS
if (!extension_loaded('sqlite')) {
if (strtoupper(substr(PHP_OS, 0, 3)) === 'WIN') {
dl('php_sqlite.dll');
} else {
dl('sqlite.so');
}
}
//this deals with sqlite but would be easy to figure out how to use it for cURL :)
?>
So you can comment out the loading of cURL extension in php.ini and then "dynamically load" it when needed.
HTH
probably the easiest way is by open file curl.ini, Im use ubuntu 12.04 and file located at
/etc/php5/apache2/conf.d/curl.ini
leave a comment by adding semicolon before extension=curl.so
You can see the location of curl.ini through phpinfo ();
dont forget to restart the Apache
sudo service apache2 restart
Curl is available as long its extension is loaded (which is mostly by default).
You can check what curl extension provides by the following command:
php --re curl
which gives you list of functions, classes and its methods.
To temporary disable curl extension, you can run PHP with -n to simply ignore your php.ini, for example:
$ php -n -r "print_r(curl_version());"
Fatal error: Call to undefined function curl_version() in Command line code on line 1
Here is working example:
$ php -r "print_r(curl_version());"
Array
(
[version_number] => 463623
...
Lately when i was debugging some PHP file with XDebug (under Eclipse on Ubuntu) i came across a strange behaviour:
print(__FILE__);
resulted in
"xdebug eval"
GEE!
So this magic constant seems not to work with this.
Anyone know a fix or a viable workaround? How to debug the debugger?
(Hardcoding a path is a PITA!)
The output you get is not incorrect. __FILE__ is a special constant that gets evaluated at parser time. When the PHP script gets compiled, it would really read something like this:
// test.php
<?php
"test.php";
?>
even though the script source was:
// test.php
<?php
__FILE__;
?>
This means that after parsing, there is no such "constant" __FILE__ at all, as it has already been replaced.
This means that if you do in an IDE, through DBGp's eval command eval -- __FILE__ it can not give you the __FILE__ with any filename. Instead, it uses the filename for the current context which is xdebug eval or in later versions, xdebug://debug-eval.
In essence, it's the same as doing this:
php -r 'eval("__FILE__;");'
Which also outputs:
Command line code(1) : eval()'d code
Xdebug looks for this sort of format, and changes it to xdebug://debug-eval so that it can actually debug into eval'ed code.
__FILE__ works as expected in PHP source code, as can be proven with this snippet:
<?php $far = __FILE__; // now evaluate $far in your IDE ?>
Despite this is quite old topic, but it is still actual. That's why I'm going to copy-paste my answer from the similar topic here as well.
This is XDEBUG issue, which can be fixed by downgrading (or upgrading in case you work with very old PHP) of XDEBUG version to 2.6.1.
I accidentally faced this issue and wasn't able to find an answer. Reinstall of server, PHP, PHPStorm, different versions of XDEBUG didn't help.
For MacOS one can use
pecl install xdebug-2.6.1
In case you already have newer version you can use command
pecl uninstall xdebug
Answers in this article helped me a lot after several hours of investigation.
Not an answer, but you probably could use __DIR__ in php 5.3.
UPD. Found that it often contains not what you expect it to.
I know it is an old question. I solved by assigning it to a variable, then it works fine!
$file = __FILE__;
include dirname($file) . '/../whateverfile.php';
Create a breakpoint on line print(__FILE__); and analyse which variables are available to you.
I have a live server which I want to occasionally use for testing purposes. I only have access to FTP and some basic administration tools there.
Reading the documentation for dl() gives me hope I can load xDebug dynamically even though I can't add it to the loaded extension list. I have little idea how though.
Question: How to obtain the appropriate compiled version of xdebug (or any other PHP extension) which would be ready to be used with dl()?
BTW, AFAIK the OS is CentOS 4 in my case, but I'd appreciate a broader answer too - for future reference.
xdebug is a zend-engine extension and thus cant be loaded dynamically.
You can try with xhprof instead. That should be possible to load at run time (I haven't much experience with it though, so i cant offer you specifics)
I usually use php_uname to determine the server OS
function os_check() {
$os_string = php_uname('s');
if (strpos(strtoupper($os_string), 'WIN')!==false) {
return 'windows';
} else {
return 'linux';
}
Such information is in various places in phpInfo()
<?php
phpinfo();
?>
I'm having a critical issue where my WAMP installation for PHP 5.3.0 is not finding a file which exists within my computer. Does anyone know anything about this? Possibly a PHP Bug?
Any help would be much appreciated.
Here is the variable which creates the file:
$baseNewsUrl = "C:/reviews/reviews/$platform/$fullname";
And here is the code which grabs the contents:
if(is_file($baseNewsUrl)){
$contents = file_get_contents($baseNewsUrl);
} else {
echo "File not found. " . "\r\n";
continue;
}
Here is the output of $baseNewsUrl: C:/reviews/reviews/GBA/r20107_GBA.htm
And the file does exist.
Check that the entire path leading up to your file is readable by the user PHP is running as (if you are using IIS, this might be something like "Network Service," although I am not particularly experienced with PHP on Windows). Also, check whether the INI directives "open_basedir" or perhaps "safe_mode" are set--these would give PHP self-imposed limits on which files are accessible.
Do a var_dump (not an echo) on your variable.
var_dump($baseNewsUrl);
and look at the actual contents. You may have some invisible garbage characters in there that's preventing Windows if you're doing this in a browser to make sure there's no empty tags (or other browser-render-invisible) characters.
If that doesn't reveal anything, remove the is_file check and try to open the file with file_get_contents (or any file related function) and var_dump it's contents. You'll either open the file, or PHP will spit out an error/warning/notice (either to your browser or to your error log) that should let you know why it can't open the file.
I'm gonna say this, and it very well might not be your problem but it is a recurring one for me. If you use skype on your computer, it has a somewhat known compatibility issue with WAMP. It cause's WAMP to be unstable, not load files properly.. everything.
on windows
$baseNewsUrl = "C:\\reviews\\reviews\\$platform\\$fullname";
It's due to Windows Vista and WAMP.