Ingolme Posted May 21, 2018 Share Posted May 21, 2018 1 hour ago, westman said: Okay I got the biggest puzzle since early man. here is my code.. if (isset($_GET['active'])) { $active = $_GET['active']; if ($active == "logout"){ if(isset($_COOKIE["username"])){ setcookie("username", '', strtotime( '-5 days' ), '/'); } session_destroy(); // This code removes the cookie no problem. However it shows the header error echo "<script>setTimeout(\"location.replace('http://mysite.com')\",1000)</script>"; // this code does not show the header error but need to run the url (mysite/?active=logout) twice to kill the cookie (session destroy works just fine) header("location: http://www.mysite.com"); } } What do I do here? Remove the echo statement. The header has to be sent before any output, which includes all echo statements. In this case, the echo statement can be removed because the location header does the redirect. If you are working with sessions, you have to call session_write_close() before sending a redirect header. Link to comment Share on other sites More sharing options...
dsonesuk Posted May 22, 2018 Share Posted May 22, 2018 Then w3schools.com seriously need to correct their tutorial examples and advice on placement of setcookie(), to reflect this then. Even the php.net site gives confusing information "prior to any output, including <html>", which suggests the idea that doctype is fine, since the <!doctype > been around a long time now. It would be better to say " prior to ANY output including html output and any white spacing" Link to comment Share on other sites More sharing options...
westman Posted May 22, 2018 Author Share Posted May 22, 2018 Hi Foxy, Thank you very much for your contribution. I was really quite advance for me but I am sure it wasn't lost on others. In the end I added one more line of code to fix the problem - It probably didn't fix the problem but no errors are show to the page and the cookie gets killed. if (isset($_GET['active'])) { $active = $_GET['active']; if ($active == "logout"){ if(isset($_COOKIE["username"])){ setcookie("username", '', strtotime( '-5 days' ), '/'); } session_destroy(); echo "<script>setTimeout(\"location.replace('http://mysite.com')\",1000)</script>"; exit(); } } as you can see a just added "exit();" Link to comment Share on other sites More sharing options...
westman Posted May 22, 2018 Author Share Posted May 22, 2018 In my last topic i opened It was advised to have a new cookie and never use the same one. At the moment my code is setting a new cookie with each page view after being logged in. Is this too excessive? Link to comment Share on other sites More sharing options...
dsonesuk Posted May 22, 2018 Share Posted May 22, 2018 17 hours ago, Ingolme said: The setcookie() call has to be done before any HTML is printed, even before the <!DOCTYPE> declaration, because cookies are sent with the headers which have to go before the content. It seems with the introduction of output_buffer this is no longer true, and probably why w3schools developers with their years of experience, decided to ignore this rule as its no longer relevant for their setcookie() examples. Link to comment Share on other sites More sharing options...
justsomeguy Posted May 22, 2018 Share Posted May 22, 2018 Quote HMMM, strange that, It states here https://www.w3schools.com/php/func_http_setcookie.asp and here http://php.net/manual/en/function.setcookie.php It needs to be before <html> I wouldn't call that "strange", just uninformed. Saying that you need to send output before particular HTML tags would imply that PHP treats output different depending on what you're outputting, and it does not. That should be obvious. Also, the PHP manual does not say "put it before the <html> tag", it says this (emphasis mine): setcookie() defines a cookie to be sent along with the rest of the HTTP headers. Like other headers, cookies must be sent before any output from your script (this is a protocol restriction). This requires that you place calls to this function prior to any output, including <html> and <head> tags as well as any whitespace. It does not characterize the output. ALL output. Then w3schools.com seriously need to correct their tutorial examples Yeah, in general, they do. They also claim to have a "complete" PHP function reference, which is obviously not true if you compare theirs with the actual PHP reference. At the moment my code is setting a new cookie with each page view after being logged in. Is this too excessive? No, cookies take up a handful of bytes in the request/response. Setting new cookies on every response isn't going to be a bottleneck. It seems with the introduction of output_buffer this is no longer true, and probably why w3schools developers with their years of experience, decided to ignore this rule as its no longer relevant for their setcookie() examples. "The introduction of output_buffer" was 18 years ago. The w3schools developers are not the only ones with years of experience, some of us here even have computer science degrees, jobs as CTO, and 15+ years of experience working with server-side languages, and we understand things like the fact that output buffering is disabled by default and in general is rarely used other than in niche situations where you need to collect a bunch of data in the response buffer, then read it out the buffer and clear the buffer, and deliver a different response. Scripts that are meant to be shared should not rely on output buffering, in fact there is a whole series of functions to control the runtime behavior of the buffer. At a bare minimum, if they are showing examples of sending headers in the middle of output (which is a bad practice in general - it violates separation of concerns to be sending output before you know what the code even needs to do) then the examples should also show code on the top, before the output, calling ob_start. It's just a bad example, it's not going to work with a default PHP installation or the most popular web host configurations. Link to comment Share on other sites More sharing options...
westman Posted May 22, 2018 Author Share Posted May 22, 2018 Thank you for the answer to my question. Most of what you were discussing I did not follow but thanks. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now