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)
Related
I've been modifying a module and for some reason prestashop does not take into consideration the code modifications in module.php.
I've made modifications a while back and I need to modify it again due to an update that raises an error, the problem is that I get the error even if I remove said line.
I get this type of error: PHP message: PHP Notice: Undefined index: ordersorderFilter!active in /modules/module/module.php on line 104
I've commented first than removed that line but I still get the error.
It seems like there is a cache somewhere that I can't find, I've deactivated all possible cache in prestashop, activated debug mode, deleted the dev and prod folders in /var/cache/ but I still get the error.
I've used grep on the server to try to find that line, and when I delete it from the file I can not find it anywhere else on the server (but can find it if I add it).
Anybody has any idea?
Thanks a lot!
Prestashop does not perform any kind of caching on the modules PHP files so the problem lies elsewhere or at "lower level" (webserver / proxy ie.).
So check your environment for server-side caching, proxies or PHP accelerators such as opCache that may not serve changes from the source server.
Also try renaming or deleting the offending file altogether and see if the error changes, if not you might simply be looking at the wrong file :)
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.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
PHP session start “Cannot send session cookie and cache limiter”
So I have been developing on my localhost, and I uploaded it to my actual web server finally, and kept getting messages saying:
Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent
Even though session_start() was at the top, no white space, etc...
So I did some googling, and the only way to get it to work properly was to put this at the very top:
ob_start("ob_gzhandler");
What does that exactly do? Is it related to my error.
Check for BOM at the start of your documents, this what probably causes the output before the session_start(); (Most text editors have a way to save your document without BOM; In Notepad++ you go to Encoding->Encode in UTF-8 without BOM).
and kept getting messages saying: Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent
This is your first fault. You have just omitted the most important part of the error message, playnly saying, where the problem code is. Did you try to read it through?
and the only way to get it to work properly was to put this at the very top: ob_start("ob_gzhandler");
This is your second fault. ob_start is not the only and not the way to go.
The only proper solution is
To read the error message and locate the place where output actually started.
Fix your code to make it send HTTP headers before any output.
Check for the possible Byte Order Mark at the beginning of your files and eliminate it.
php session weird error
This is your third fault. One cannot call "weird" an error which has been asked a zillion times already. I'd rather call it "extremely familiar and boring" one.
I am trying to call the API but I keep getting a soap error that can't load the file. I found that the reason is there are about 3 blank lines at the top of the XML file that is returned. I found this by doing wget url.
This use to work just fine, when I debug through the API controller the response or xml looks fine all the way through, I don't see any spaces at all. I have no idea what might be causing this. I don't think there is anything we modified that would do this.
UPDATE:: I have found that it appears to be because of an observer class I made for the controller_action_predispatch event. It appears I have some spaces above the
I'm not completely sure of what I am talking about as far as I've never used the API, but you should try to look at the end of the file which generates your XML for a closing '?>'. If there is this closing PHP marker, remove it and try again you API call...
In Magento, PHP file should never be ended by a closing php marker '?>'.
edit: as said in comments, also look at spaces before the opening tag '<?php'.
First thing need to check is api.php file in root folder, most of api blank space issues will come if any empty lines added in api.php file before starting
I'm using script which is uploading files to server via flash component. Sometimes, very rarely, when trying to upload images via Firefox I get following error: IO error #2038. Searching on the net I could find reason why is it really happening to me. But I found solution for my case:
I open IE6, do the same thing there (photos are always uploaded without problem) and the when I try again in Firefox problem disappears. If someone had similar problems maybe this could help or maybe this hint could help to someone discovering cause of the problem :)
I just had this error also using ASP.Net MVC and I discovered I just had my handler namespace wrong/missspellled in the web config section where the handlers go. HTH...
After far more time than I'd like to admit, here is the solution. Change the following variables in your php.ini to be large enough to handle your largest file:
; Maximum size of POST data that PHP will accept.
post_max_size = 32M
; Maximum allowed size for uploaded files.
upload_max_filesize = 32M
; Whether to allow HTTP file uploads. (this is on by default)
file_uploads = On
Since files are sent as POST data, both the first variables need to be set. Otherwise, there will be an error, but you won't see what the error is, except IO error #2038.
If you didn't add quote around the option names, try doing that. Sometimes in IE, quoting the option names fixes the issue. It would help if you posted some example code though.
Also make sure that the path to the server being used by the upload component is correct. If the path is a relative path, try to fully qualify it. IE can do some "magic" with relative paths that the other browsers cannot do, and sometimes trying the code from one browser to the other can tweak things.
Also, could be permissions...and having IE go there first could manipulate the permissions in a way that the other browser(s) then work "correctly".
I solved the problem.
In my office I use a proxy and I must change the settings to No Proxy.
Or if you do not use proxy, try to change in php.ini:
Hostname:Port localhost:0
to:
Hostname:Port localhost:80