PHP require_once not working on Linux - php

I've transferred a PHP web-system from a Windows hosting provider to a Linux based hosting service.
In the system's scripts, when it comes to require_once, the script simply stops and leaves the user at a blank white page.
I've tried both of the below:
Try 1
require_once($_SERVER['DOCUMENT_ROOT'] . '\library\data\Dbec.php') or die("could not load file");
Try 2
require_once(dirname(__FILE__) . '/library/data/Dbec.php') or die("could not load file");
In both cases, the text in the die parenthesis is not showing and the page remains blank.
The script that is requiring the above files is in '/library/membership/theScript.php'
Based on the reading I've done on line up to now, maybe it has to do with changing the include_path in php.ini file or writing the paths in a different way.
If its any of the above, or something different, I'd appreciate some hints.

Check your error log, to see if anything is visibly wrong. Also try setting error_reporting = E_ALL, and make sure display_errors = On and log_errors = On in your php.ini.
Your file your trying to include is in '/library/membership/theScript.php', try doing:
require_once '../data/Dbec.php';

This isn't going to do what you want. Everything after require_once is being interpreted as a conditional. It's running ($_SERVER['DOCUMENT_ROOT'] . '\library\data\Dbec.php') or die("could not load file") and returning 1, then running require_once 1.
To make it work as you expect, you would need an extra set of parentheses:
(require_once($_SERVER['DOCUMENT_ROOT'] . '\library\data\Dbec.php')) or die("could not load file");
Although, I'm not certain the die() will ever get called. It's up to you to figure out.
See this related bug report which was ruled "not a bug."

Also problem can be in file permissions and filename. Windows filesystem is caseinsesetive but linux is not. So you have to check the filename and the fact that user who executes this script has read persmission on the file you try to include with require_once

Related

fopen creates the file, so why is the fwrite failing?

I have this stupid little test PHP script running on a Ubuntu system inside an instance of a virtual server (Oracle Virtual Box) running on my pc:
<?
error_reporting(E_ALL);
ini_set('display_errors', 1); // show errors
echo "<p>test</p>";
$filename = "andy.txt";
$fh = fopen($filename, 'w') or die('fopen failed');
fwrite($fh, "qwerty") or die('fwrite failed');
fclose($fh);
?>
Despite all appropriate directory and file permissions being set, it is failing on the fwrite. The fopen works and creates the file, so write access is clearly enabled, but the fwrite dies, and the 'fwrite failed' message is output (no other error output is displayed).
The same script works perfectly well when I upload to my real server, so I am completely stumped as to why it won't write to the file; maybe it's something about my virtual server that is causing the problem.
Seems like such a pathetic thing, but it's driving me nuts! Considerable time Googling has failed to yield an answer, so can anybody here please provide some insight? Many thanks.
Not sure why the fwrite() call would die, as it returns the number of bytes written.
That said, have you tried with file_put_contents() instead? It's a simpler way of writing to a file, and is the recommended way since early PHP 5.
With it you only need to do the following
$filename = "andy.txt";
if(!file_put_contents ($contents, $filename)) {
// Write failed!
}
No need to bother with opening and closing the file pointer, as that's automatically handled by the function. :)
Solved! It was a disk space error on my virtual server. At the back of my mind, I knew I had seen this mentioned elsewhere as an issue with write fails, but in this case I failed to make the connection.
#ChristianF Thanks! Switching to file_put_contents() was very helpful, since it also failed, but gave me a meaningful error message:
'file_put_contents(): Only 0 of 6 bytes written, possibly out of free disk space'
Aha! Having recalled that growing log files can be a problem, I took it upon myself to delete everything inside /var/log (after saving them) and Presto! it now works! So, thank you for that tip - I will switch to using file_put_contents from now on. BTW: The contents of error.log itself was 2GB, while the remaining size of everything else in /var/log was only about 15MB, but deleting error.log by itself did not work, so I deleted everything.
#Clayton Smith Thank you, but removing the "or die('fwrite failed')" part did not result in any further error info - which is what is so frustrating: It's a shame that those error reporting directives at the start of the script didn't seem to do much.
#NaeiKinDus Thank you, but I don't think I have SELinux running (I'm afraid I don't know anything about this). Although I have a /etc/selinux directory present, there's no config file in it, just what appears to be a skeleton semanage.conf - whatever that is. Commands such as sestatus are not recognised.

Using file_exists with safe_mode enabled

I am trying to check if a file exists on the server. The difficulty that I am having is that file_exists returns false for a file that I know exists on the server.
My server is configured withsafe_mode = on in php.ini. Because of this I've added the directory that contains the file I want to check on using
include_path=".:/path/to/dir"
I've also added the path to
safe_mode_include_dir = /path/to/dir
file_exists("/path/to/dir/file") still returns FALSE.
Thanks in advance
If you have the ability to do so, disable safe_mode. It has been deprecated by the PHP development team, and is gone as of PHP 5.4.0, so you will need to stop depending on it sooner or later.
If you must use safe_mode, add the directory to open_basedir, not include_path.
Sorry, but it's just not possible to circumvent safe mode restrictions - that's sort of the point of safe mode. If you want to include the file, you will still be able to do so if you have set safe_mode_include_dir to a path that will allow it to be accessed, but there is no way to get stat() related functions to work with it.
EDIT
A horrible and incredibly dangerous and unreliable work around might be this:
function file_exists_safemode ($file) {
$oldErrorLevel = error_reporting(E_ALL);
$oldDisplayErrors = ini_get('display_errors');
ini_set('display_errors', 1);
ob_start();
include $file;
$result = ob_get_clean();
ini_set('display_errors', $oldDisplayErrors);
error_reporting($oldErrorLevel);
return strpos($result, 'failed to open stream') === FALSE;
}
...but it is so nasty in so many ways, and I definitely do not recommend this as an approach.

can't include("absolute_path")

I can't figure out why this won't work.
$docRoot = getenv("DOCUMENT_ROOT");
include_once($docRoot."/conn/connection.php");
include_once($docRoot."/auth/user.php");
It works locally through wamp, but it won't work on my live server. I tried this:
if(!include_once($docRoot."/auth/user.php")){
session_start();
$debug = array();
$debug["docRoot"] = $docRoot;
$debug["inc_path"] = $docRoot."/auth/user.php";
$debug["file_exists"] = file_exists($debug["inc_path"]);
$_SESSION['DEBUG'] = $debug;
// exit
header("Location:debug.php");
exit();
}
The debug page just echoes that array and it shows the correct absolute paths and indicates that the file does in fact exist. So why didn't the include_once() work? The server (a DV account on a MediaTemple server) has not been configured at all, so I wonder if there is an apache or php setting that is messing with me.
Ultimately, what I want here is a way to refer to a file in such a way that if I move the file, or include it in another file, nothing will break. Any ideas?
In your debugging you might try is_readable($docRoot."/conn/connection.php"). The file_exists function will return true even if the file does not have readable permissions.
If you get an error code we might be able to provide more info as to what is going wrong.
Turn on error reporting dummy. It turns out one of the includes on another file was breaking this page and I wasn't able to trace that out until I turned on error reporting.
Incidentally, the problematic include was missing a leading slash in the filepath ( include("dir/file.ext"); ) which works on my local wamp setup and breaks on the linux server.

php fopen function dies, though I have file permissions set to read and write

I'm following a tutorial on php, and am having difficulty getting this to work. I set the appropriate directory permissions to read and write, but every time I run this, I get the die string.
The code is:
$ourFileName = "testFile.txt";
$ourFileHandle = fopen($ourFileName, 'w') or die("can't open file");
fclose($ourFileHandle);
As far as my basic understanding goes, if "testFile.txt" does not exist, fopen should create that file (I have basic knowledge of Python, and remember this same principle in that language). But it...it doesn't. Even if I create the aforementioned file, and put it up, that line of code still returns a die string.
My hosting account does not give me permission to execute. Is this a problem?
My server runs on Windows. I am using Dreamweaver CS5, on OSX 10.5.8.
I've done some searching on this, and see other people having similar issues - but none of them keyed to exactly my range of problems. Being that I'm a beginner, I feel that it might be something I'm overlooking.
Thanks!!
The 'or die' doesnt really do much for you other than killing the script...
Seeing as your code should work... Try debugging:
Put this at the top of your php
error_reporting(E_ALL);
ini_set('display_errors','1');
Problem fixed. I use godaddy, and had them switch my account - which was previously housed on a Windows server - over to a Linux one. With Windows, I didn't have as much control over file permissions. Now I do - and now that code works as it should.

PHP Wamp is not finding a file which exists

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.

Categories