I'm using #fopen to open a file in "rb" mode. the file that im opening here is running with no errors but if i open that file using #fopen then it is giving error.
code is something like this---
$file = #fopen("xyz.com","rb") or $flag=1;
if($flag==1)
{
mail($to, $subject, $message, $from);
die();
}
sometimes it opens up without sending any error mail but sometimes it starts giving so many error mails.
what is the solution to open this url without having any error mail? plz help!!
If you're trying to open a URL (presuming from the 'xyz.com' you included), then you need to include the schema declaration before it. E.g. http://xyz.com, otherwise PHP will attempt to open a local file. If you're referring to a local file, make sure to escape any back-slashes if you're on Windows.
However, there's nothing else inherently wrong with the rest of your code sample that should cause a problem. # simply suppresses error outputs, so it won't be causing any odd behaviour in and of itself.
Though, that said, a better way to handle it might be to do this:
$file = #fopen("xyz.com","rb");
if(!$file)
{
mail($to, $subject, $message, $from);
die();
}
Try to use the
file_get_contents();
function instead of fopen().
by the way, you are setting $flag = 1 when there is an error. but what if there was an error last time and this time there is no error? (then $flag is still 1 from the previous time).
remove the '#' charactor from the start of the fopen method, (ther presence of the # symbol supresses any php driven error message) this will give you the explanation of why php thinks you cant open that file - i would hazard a guess either the path to the file or the permissions of the file are invalid.
What is error message? We can just guess about the problem without it.
Is url fopen always allowed in your ini? Maybe this value overrides somewhere with ini_set()?
Are you sure, that url is correct and host is alive?
Finally, I recommend to use fsockopen instead. It provides more flexible remote connections, error handling for them and possibility to set the connection timeout.
The # symbols suppresses errors so $flag will never be set
Related
I was wondering when does file_exists() return an E_WARNING???
in the manual it says
Upon failure, an E_WARNING is emitted.
Can you tell me a simple example of this, cause i couldn't come up with anything?
UPDATE:
so, if i try to check a file that doesn't exist like:
if (false === file_exists('path/image.png')) {
//something
}
This will only return false, and NOT an E-Warning, right???
I'm srry if this is a stupid question (i'm still a total noob in php :-))
Thx
For example when the safe mode restrictions prevent the script from accessing the filesystem, or the file system is not reachable for another reason or an I/O or permission error occurs.
And I think, thats about it.
The following code works when i run it in localhost, but when I host it online, it gives an error.
if(isset($_POST['congressman'])){
$congressman = $_POST['congressman'];
$no_of_votes = mysql_result(mysql_query("SELECT no_of_votes FROM `tbcandidates` WHERE `identification_no`=$congressman"),0) + 1;
$query=mysql_query("UPDATE tbcandidates SET no_of_votes = '$no_of_votes' WHERE identification_no = $congressman");
This line:
no_of_votes = mysql_result(mysql_query("SELECT no_of_votes FROM `tbcandidates` WHERE `identification_no`=$congressman"),0) + 1;
It says mysql_result(): supplied argument is not a valid MySQL result resource in etc..
try to add ob_start() at the top of the code and ob_flush() at end
Headers already sent just means there was already an Data Output before you called that header() instruction...
So you are asking for the reason it is running on localhost while the server denies to run it: Strict modes and error handling - on your webhosts server the settings are probably more strict so errors won't get ignored as on localhost
search for any output made before the header and remove it.
You need to find out the output before the head function. It could be some html contents, may be the bom head, or may be some other warning message.
The quick fix is put the code at the top of your script.
<?php
if ($_POST['user']=="admin" && $_POST['pass']=="password"){
header('Location: adminview.php');
exit;
}
Does any body has any idea how to find where the leak is that provokes this "Content Encoding Error" with $config['compress_output'] = true in CodeIgniter?
I've trying to debug this error for days, but I can't seem to find where the leak is. LogLevel is at debug but I see no info in the log when this error happens.
So, any ideas how to debug this?
UPDATE
I really don't want to disable the compress_output feature, I just want to see how can I trace where the error is produced
UPDATE2
I've looked over and over again to see if there is any output in the controllers... and there is none, so some where else must be the error provoked. No models/database, just controllers, libraries, helpers and views
This issue is where the output buffering starts. The check for the config variable is in system/core/Output.php in _display(). It starts the gzipped buffering after a lot of code has already run. This leaves the potential for output to have occurred before it buffering starts.
With compress_output set to false it doesn't matter because nothing is encoded. With it set to true you end up with mixed content. Some output is encoded and some is not which causes the compression error.
There are two solutions:
1) You could leave compress_output set to false and add ob_start('ob_gzhandler'); to the top of your index.php file. This will ensure that all output is always gzipped, including errors.
2) The other solution is to add ob_flush(); before ob_start('ob_gzhandler'); in system/Output.php. This will gzip output when there are no errors and serve you unencoded content when there are errors.
I think 2 is the better solution and should be implemented by the CodeIgniter team. But if you don't want to muck with the system code (changes will go away when you upgrade) then 1 is the better solution for you.
This might be a long shot, but if you echo/print database output directly from your controller instead of sending it to the model you'll likely get error messages that have to do with output buffering. Are you echoing from your controller?
Putting the following line in config.php:
$config['compress_output'] = FALSE;
Solves it. The problem in my case was that I sent the post, but it did not recognize the FILLCATEGORIAS function. Inly by changing the $ config [ 'compress_output'] = FALSE; solved it.
THIS problem occurred when we send data using a POST request:
Failed to load resource: net::ERR_CONTENT_DECODING_FAILED
<script type="text/javascript">
$(document).ready(function() {
$("#idEmpresa").change(function() {
$("#idEmpresa option:selected").each(function() {
id = $('#idEmpresa').val();
$.post("<?php echo base_url();?>Admin/fillCategorias", {
idEmpresa : id
}, function(data) {
$("#idCategoria").html(data);
});
});
});
});
</script>
Any error in PHP will break compression.
To test this, in index.php change:
error_reporting(E_ALL);
to
error_reporting(E_ALL ^ E_NOTICE);
Do not echo/print to display output from controller.
Do not use "?>" at the end of controller file.
I hope it helps.
Update:
To check if the output is empty before starting buffering, you can open core/Output.php and add
ob_flush();
before
ob_start('ob_gzhandler');
If there is even a space or an empty line, compression will fail. (check page source from browser). This happens because with $config[‘compress_output’] = true , ob_start('ob_gzhandler') (line 379 in Output.php) is executed, wich will cause a "Cannot modify header information - Headers already sent ..." warning. This warning is the cause of compression failure.
So basically, any echo outside of Output class (json output included) will send headers to client, which will cause "Cannot modify header information - Headers already sent ..." warning, which will cause the "content encoding error".
I had the same problem. After searching, I found that my controller has ?> at end of file. So I removed it and it works perfectly. Here is a link for more detail.
More compliant solution:
$this->output->set_output($data);
Some CPanel lightspeed extension updates create this problem. You can try adding this code in your .htaccess file:
php_flag zlib.output_compression ON
How would I go about checking if and include or a require has an error in it. For example, and include would try to be included, if that page has an error the page isn't included and a message is throw?
Cheers.
You can't catch a parse error in PHP in the same language environment (for obvious reasons).
One approach might be to run php -l your_included_file.php using exec and then check the exit code. The -l (lint) argument checks that your code can be parsed correctly.
You can try using file_exist function, it check whether the file exist or not.
$filename = "/path/to/file.php";
if(file_exists($filename)){
include $filename;
}else{
include "errorpage.php";
}
You can't trap parser errors.
However, if the code executes something that causes an exception to be thrown, you could catch it with a try/catch block.
I have a PHP script that creates other PHP files based on user input. Basically, there are files containing language specific constants (define) that can be translated by the user. In order to avoid runtime errors, I want to test newly written files for parse errors (due to "unusual" character sequences). I have read several posts here on SO (like PHP include files with parse errors) and tried a function that uses
$output = exec("php -l $filename");
to determine whether a file parses correctly. This works perfectly on my local machine, but at on the provider's machine, the output of calls to exec("php ...") seems to be always empty. I tried a call to ls and it gives me output, leading me to the assumption that PHP is somehow configured to not react to command line invocations or so. Does anyone know a way around this?
EDIT: I forgot to mention, I had already tried shell_exec and it gives no result, either. In response to sganesh's answer: I had tried that too, sorry I forgot to mention. However, the output (second argument) will always be an empty array, and the return value will always be 127, no matter if the PHP file to test has syntax errors or not.
I had the same problem. The solution that worked for me was found in running-at-from-php-gives-no-output. I needed to add output redirection.
$output = exec("php -l $filename 2>&1");
You can try with exec second and third arguments.
second argument will have the output of the command.
third argument will have the return value.
And exec will return only last line of the command.
$filename = "a.php";
$output = exec("php -l $filename",$op,$ret_val);
print $output."\n";
print $ret_val."\n";
var_dump($op);
By executing shell_exec(), you can see the output as if you executed that file via command line. You can just see if there is an error right here.
<?php
if (strpos(shell_exec('php -l file.php'), 'Syntax Error')) {
die('An error!');
}
There may also be a possibility that shell_exec() or exec() may be disable by your host.
Nice idea to check the file validity :-)!
Now, from the PHP manual for exec():
Note: When safe mode is enabled, you can only execute files within the safe_mode_exec_dir. For practical reasons, it is currently not allowed to have components in the path to the executable.
Can you check if this is not the case for you?
Also, can you check by providing the full path of the PHP interpreter in the exec() instead of only php. Let me know how you fare.
Pinaki
the correct way is to add >2&1 as tested on a windows system using imagemagick!
I worked around my original problem by using a different method. Here is what I do now:
Write a temporary file with contents <?php include "< File to test >"; echo "OK"; ?>
Generate the correct URL for the temporary file
Perform HTTP request with this URL
Check if result equals "OK". If yes, the file to test parses without errors.
Delete temporary file
Maybe this could be done without the temporary file by issuing an HTTP request to the file to test directly. However, if there is a parse error and errors are suppressed, the output will be empty and not discernible from the output in the case of a file that gives no parse errors. This method is risky because the file is actually executed instead of just checked. In my case, there is only a limited number of users who have access to this functionality in the first place. Still, I'm naturally not entirely happy with it.
Why the exec() approach did not work, I still do not know exactly. pinaki might be right by suggesting to provide the full path to the PHP executable, but I cannot find out the full path.
Thank you everyone for answering, I upvoted you all. However, I cannot accept any of your answers as none of your suggestions really solved my problem.