I am using this script from Bit Repository.
<IMG SRC="resize_image.php?image=sunset.jpg&new_width=32&new_height=32">
My problem is that, it is not showing any image on my hosted server.
http://www.belowyellow.dx.am/resize_image/demo.html
but it works on my localhost, hope somebody can help me with this. Thank you.
Source: http://www.bitrepository.com/resize-an-image-keeping-its-aspect-ratio-using-php-and-gd.html
If you take a look at what your PHP script returns before trying to embed it in an img tag, you'll see there are some warning before your image data.
Since PHP output text before your image output, it can't change the HTTP header anymore, so your image is output as text.
set_time_limit(10000);
error_reporting(E_ALL ^ E_NOTICE);
You should remove these two lines from resize_image.php. set_time_limit is obviously disabled on your production server so the first line is useless and generates a warning. The error_reporting in the second line is the real source of the problem here, it tells PHP to display all kind of warnings and notice. This kind of error reporting should only be used in a local debugging environment and not on a production server. If you remove this line, you'll get the default error reporting that shouldn't show any warning and your image should be correctly output.
Related
I'm using codeigniter project (opensourcepos). I have done all configurations as said but there's an error.enter image description here
Please help me out...
I have tried to change the .htaccess file many times but in vain...
It looks like the actual error is not being displayed so you can't properly diagnostic it.
Depending on the CI settings and version (please specify) it hides the error and only shows a standard server 500.
Details:
https://codeigniter.com/user_guide/general/errors.html
The site works fine on Chrome/iOS/Safari/Android (you should be able to select and image and proceed to write a message on the next step). Firefox refuses to run my project's main script (you can't select an image or go forward), and gives the following error in the console:
> Content Security Policy: Directive ‘frame-src’ has been deprecated.
> Please use directive ‘child-src’ instead. (3) Unknown
It's very cryptic. I've tried the following:
1) Adding a meta tag for the CSP in the header.
Result: Creates more errors if restrictive, same amount of errors if
left to wildcards on all parameters.
2) Locally serving all scripts.
Result: I still get three unknown CSP errors. It also loads a lot
slower since the dependencies are not being loaded from a CDN.
3) Removing specific scripts.
Result: It reduces the errors by up to one, but it seems all scripts
are equally responsible. Very strange behavior.
Is this a bug in Firefox that is unsolvable? I'm tearing my hair out over this.
I needed to put listeners in $(document).ready as Firefox loads things differently as pointed out to me by Matt Gibson.
Content Security Policy did not cause the script to fail. However, it is a weird error message that gives you no information to where the error is originating, and can potentially break the site, but that is not what happened here.
CodeIgniter 2.0.2 syntax error blank page
i have CodeIgniter 2.0.2 (CI) and its annoing, that when i write lots of code and then just get blank page. Hard to debug without error. i got error reporting E_ALL in php.ini and in config of CI its turned on for every case of enviroment (devel, product) just for sure...
Does anyone knows, where the bug can be? How to turn it on? I think CI is rewriting php.ini error reporting setting somewhere somehow...
Thanks.
The other thing to check in your php.ini are the 'display_errors' and 'display_startup_errors' variables, they should both be set to 1.
In my (little) experience with CI this issue has been the most frustating one. I can understand that no framework is perfect, and any web developer is used to deal with errors (no matter if the framework or the developer is to blame). But that ANY error results in a blank page, with ZERO information in logs, console, whatever, is unacceptable.
If I recall correctly, in my case this was caused by of some combination of CI (ab)using the "silent error" PHP operator (e.g. prepending some db statements with the # operator, a not very clever way of avoiding leaking potentially private information to the end user), together with some bad use of *error_reporting*. See my post here (and see how many answers I got!).
I reported another related CI's idiocyidiosyncrasy related with logging here (again, zero answers)
please check the index.php which locate in the SAME LEVEL of the application folder
inside the index.php the second line
line 2:
ini_set("display_errors", "1"); //ensure it is set to 1
line 23:
define('ENVIRONMENT', 'development'); // development | testing | production
grep your php.ini for the word "error", turn them to On etc...
Do you have output compression turned on in the config? I find that will cause white pages when you have errors.
$config['compress_output'] = FALSE; // Should be set to this when developing.
I had the same problem and eventually fixed it when i noticed I had no 'logs' directory in my application folder
I'm using ABCPdf to convert HTML to a PDF. I'm using the method:
AddImageUrl()
This works fine in Dev and UAT, but on Production I continuously get the message:
Unable to render HTML. Unable to load
page
Anyone see this before? Need more info?
-Ev
I guess you are tying to do URL->pdf generation. It is difficult to directly to do URL->pdf conversion. We ended up URL-Save HTML in local folder ->read HTML and convert to PDF-> delete HTML file from folder - tricky approach but it works. The only flaw is that you need to give read/write permission on a folder on server. Its still better than decreasing security settings.
have you take a look at this http://www.itjungles.com/dotnet/abc2pdf-unable-to-render-html
The default timeout for abcpdf is 15 seconds. If the page is taking longer than 15 seconds, you will get this exception.
Add the line below just after object creation of the document to resolve the issue.
theDoc.XHtmlOptions.Timeout = 10000000;
I found by working backwards (removing elements) from a target html page that omitting the tag (of all things) created this error. also, calling localhost in the target url generated this error.
I have no idea what caused this error, but I stopped the scheduled task that was running, then restarted it and it's worked fnie ever since.
i got this error
A PHP Error was encountered
Severity: Warning
Message: Cannot modify header
information - headers already sent by
(output started at
/home/rapcomdk/public_html/system/language/danish/imglib_lang.php:1)
Filename: helpers/url_helper.php Line
Number: 541
i dont know what the problem is
here is my controller:
http://pastebin.com/EMtcMgsB
and here is my model file:
http://pastebin.com/iH6xQFGA
hope some one can help me out
Check and make sure in system/language/danish/imglib_lang.php that you have no whitespace before the <?php tag and make sure you do not have a closing ?> php tag in the file.
In addition to jondavidjohn's answer, if you're using Unicode encoding for the files, make sure there's not a byte order mark starting off the file. On some platforms, this can wreak havoc on PHP processing.
Make sure there are no errors in codeigniter, sometimes the errors can be covered by other errors, such as one error lead to another.
The problem is in system/language/danish/imglib_lang.php, which must have some character before the <?php part by the time it is parsed on the server. What's happening is that helpers\url_helper.php is trying to redirect (using this code;)
case 'refresh' : header("Refresh:0;url=".$uri);
But is failing because imglib_lang.php, line 1 has already sent some non-header text to the response. Since headers come first, it's giving you the warning.
I wonder at it working locally but not on the deployment server. It may be that the file is not being transferred cleanly, or that the servers use different versions of PHP with different handlings of character sets.
Several checks;
Be absolutely sure there is no BOM at the front of system/language/danish/imglib_lang.php. Let us know why you are certain. If you've edited the file in Notepad on windows, for instance, it'll have gained the Byte Order Mark. It can be very hard to tell since some tools 'swallow' the mark. Also make sure there's no plain whitespace.
When you save imglib_lang.php, make sure you save it in ASCII.
Compare local and remote versions of PHP. If there are differences, update your local copy to the same as the servers, and retest.
Check that the file is being transferred perfectly. If you are putting the file up using FTP, then FTP may be modifying it as it transfers it. FTP has two modes - an ASCII mode and a BINARY mode. If the files are being transferred as ASCII, then there may be some rewriting of the file going on. Try making sure imglib_lang.php is being transferred as BINARY to make sure the exact file is being uploaded.
If you think that you have everything configured correctly, maybe your library (or specifically, imglib_lang.php) is simply producing PHP warnings or notices. If you can get a hold of your logs from your host, it would be helpful.
Otherwise, you can try to turn off PHP's error reporting:
error_reporting(0);
(you can place that line in your index.php)