This is a very strange issue. In my code I have a redirect that works perfectly on my local server.
header("location:/sign-up-success");
When I push to production, it just doesn't redirect. Is there a setting that I am missing?
I have even tried:
header("Location: https://www.myurl.com/sign-up-success");
It appears to just skip over the redirect. Any ideas?
possible reason: you have sent some output to the browser before the call of header()
solution : write ob_start() at the top of the page
Best practice : alwyas write exit() after header()..
Reference
Take a look at value of error_reporting on production server. If it is set to too low level, there will be nothing in the log, as errors of lower level than error_reporting are just silently ignored. Same applies to using # - it sets error_reporting to 0, so if anything bad happens (e.g., if function is not even defined), you won't see anything in the log.
From what you wrote about enabling output buffering, it seems that you have some output before header() (this is why enabling output buffering helps) and that your error_reporting is set to 0 (this is why warning about "Cannot modify header information" was not being reported/logged).
On a side note... To get the most of error reporting:
set error_reporting to E_ALL | E_STRICT (in both dev and production environments)
enable error logging (critical for production environment, though it won't hurt to have it enabled in dev environment as well)
set display_error to true in dev environment, false in production environment (critical!!! user does not have to see any PHP warnings/notices/errors)
additionally, you might want to set_error_handler() to output or log more information than default error handler does (e.g., you might want to store debug_backtrace(), when error occurs)
It appears to just skip over the redirect.
You need to have a look at exactly what the script is returning in headers / content. There are lots of tools available for this - HTTP fiddler, iehttpheaders for MSIE, for Firefox there's tamperdata, liveheaders, web developer toolbar and many more. Or sniff the network traffic (though decoding ssl can be a PITA)
Thank you for all the responses. It appears the answer to this question was given by #netcoder in the comments. The answer is found below:
In the php.ini file on my local machine I had "output_buffering = 4096" and on the production server it was set at "output_buffering = off". Turning it on fixed the header issue and some other problems as well.
For those with other headers problems, please review the other responses as they will be helpful if you have error reporting turned off. (I had run into that before, that's why I knew that wasn't the problem but that can certainly be a headache for people working with redirects and not knowing what the problem is).
Thank you all.
Related
When I try to install Jetpack on my Wordpress website I get the following error:
Error Details: The Jetpack server could not communicate with your
site’s XML-RPC URL. Please check to make sure example.com/xmlrpc.php
is working properly. It should show ‘XML‑RPC server accepts POST
requests only.’ on a line by itself when viewed in a browser and
should not have any blank lines or extra output anywhere.
When I goto the URL I see this:
XML‑RPC server accepts POST requests only.
Which is expected. It feels like I have tried everything I have googled and everything here:
https://jetpack.com/support/getting-started-with-jetpack/what-do-these-error-messages-mean/blank-lines-xmlrpc/
I have tried uninstalling all plugins and still does not work :(
What am I doing wrong?
Please help!
Looking at the link, they specifically mention whitespace or output that could be causing issues, and ask you to check there isn't any before the opening PHP tags etc.
The reason they talk about this is because if there has been any output at all, then PHP will no longer be able to send any HTTP headers!
If your files look ok, then I guess (guarantee even?) that your display_errors is turned on. Depending on the level of error_reporting in your ini file, any little notice or warning will create output, and therefore stop any further HTTP headers from being set.
For the best error logging experience (and hopefully to also fix your error), set error_reporting to -1, turn display_errors off, and set a custom error_log. Then in the terminal, type tail -f /path/to/error_log. Your notices, warnings and errors will now scroll past in real time, without distorting your web page's display.
I have recently changed hosts, on my old host if i had an error in my syntax the error would be displayed (showing me where the error was)
On my new host i do not see this, i just see
The website encountered an error while retrieving http://www.XXX.co.uk/delete_product.php?q=66550. It may be down for maintenance or configured incorrectly.
Is there any way i can show the error instead of this?
Turn on error reporting.
Include these lines are the top of your script:
ini_set('display_errors',1);
error_reporting(E_ALL);
If you have access to edit the php.ini file, you can edit it and include the following option:
error_reporting = E_ALL
These settings will help you troubleshoot code faster and makes it easy to identify errors. However, it is not appropriate for a production-level use. You should use the first method and then you can remove the lines once you've fixed the issues. On local development environments, it's okay to edit php.ini file and add the directive as mentioned above.
On production systems, do not use ini_set('display_errors', 1); as it can show information you might want to keep hidden. Use the server's logs instead. By default apache for example logs these errors in error_log.
And, anything that is open to the general internet public is considered "production" in my opinion. Development means it is a server sitting in your own local network.
Turning on error reporting would work, but perhaps it would be better to look into the server logs.
I'd like to see any PHP errors that are occuring, ie the "Expected ; on line 5 of myfile.php" sort of thing. Unfortunately, I cannot seem to figure out how to see this information.
I've set E_ALL, display_errors ON, friendly error messages are turned off, IIS is set to pass-through on errors, what am I missing?
Syntax errors used to show up as stated above on any page; they no longer do. We moved the server to a localhost for development, and I guess didn't mimic exactly the server config. Now I'm stumped.
Tried on IE and Chrome, neither of which show the errors.
Errors are logged in PHP's log file, but I'd still like them to be displayed on the page; at least for now.
UPDATE:
Just tried adding ini_set('display_errors', 'on'); directly into the requested page, and it now works.. but why? Why does it need to be set locally? My PHP.ini file has this declared already.
To answer the first part of the question; to see the errors when using ajax: You can use the developer tools of your browser to see the exact response from the server.
In FireBug for Firefox for example, you go to the Net tab and there you see all ajax request popping up as they happen. Opening one of these requests will give you an overview with more tabs like Response and HTML.
Try using:
error_reporting (-1);
E_ALL isn't really "all" for php < 5.4.
Also, make sure 'display_errors' is set.
ini_set( 'display_errors', 1 );
Well, looks like this is half my own stupidity, half the cloudiness of automatic installations.
Turns out there were TWO php.ini files, and that IIS used the one located within the iis express directory on the main drive, instead of the regular PHP directory.
So to anybody else having this problem, I'm providing the full list of crap you have to wade through to get the errors as you would like:
1) Turn off the IIS default error pages
2) Disable 'friendly error messages'
3) Ensure you are using the CORRECT php.ini file, and change the parameters as needed. Specifically error_reporting and display_errors.
All of this is necessary before seeing all of the error messages you need right in the browser.
I have my site live in which i echoed few strings for testing, so it displayed me those test strings but along with the warning message
Warning: Cannot modify header
information - headers already sent by
(output started at
/home/companyfolder/public_html/mycart.php:117)
in
/home/companyfolder/public_html/includes/functions/general.php
on line 50
But at the same time i do not get this error any where in my local machine so i want to know is there any difference in display of header information related to servers?
Because of output buffering
And not a single one, who volunteered to share their knowledge about error handling, mentioned a way more likely reason - display_errors turned off, as it on the live site ought to be.
Of course it should be. To
not to scare users with strange messages
not to reveal vital info of your application to possible attacker. nor to supply them with any feedback.
inform a programmer of all errors occurred, by turning log_errors setting on
Thus, on a development site
display_errors = on
log_errors = off
on a live site
display_errors = off
log_errors = on
while error reporting level should remain the same - E_ALL or better
You have the same issue in both places, just different error reporting levels. You can configure this in your php.ini file or at runtime with error_reporting()
This error is pretty general, but basically what is happening is what it says. You're including mycart.php in a page and on like 117 it starts outputting HTML (or something client-side), once this starts happening you can't modify any of the header information (ex. a redirect). Like jason said though, the reason the error isn't showing up is the error_reporting setting.
EDIT: You can solve some of these problems by using ob_start() and then ob_end_flush() after you've done your header modifying.
Your other server configuration might have output buffering turned on in the php.ini file.
The server has this in php.ini
error_reporting(E_ALL);
if you just want errors then use
error_reporting(E_ERROR | E_PARSE);
In this question the OP mentions PHP throwing a 500 error automatically when error_reporting is off, and XDebug changing that behaviour.
That got me curious, as I've never heard of PHP automatically emitting 500s before. According to various quotes and answers on SO and elsewhere, it seems to indeed be PHP's default behaviour to throw a 500 Internal Server Error header if display_errors is set to false.
However, I am unable to find anything official on this. The manual pages on display_errors and error_reporting say nothing.
Does anybody know a good source in the PHP docs that talks about this?
Not sure, but this may have been added in PHP 5.2.4:
Changed error handler to send HTTP 500 instead of blank page on PHP errors. (Dmitry, Andrei Nigmatulin)
There is also this discussion on the internals list that might be related:
[PHP-DEV] FW: php fastcgi
Quoting:
Current time most PHP instalations use setting 'display_error=0'.
This setting hides errors from user but may send to him just a blank page.
The proposed patch sends HTTP 500 response on errors instead of blank pages.
The pages that already wrote something are not affectd.
Any objections or additions?
and the proposed solution/patch seems to be shown here:
http://www.mail-archive.com/internals#lists.php.net/msg28557.html