PFMaBiSmAd

A setcookie() statement must exactly match the parameters (name, path, domain, secure, and httponly) of an existing cookie, otherwise you are actually trying to set a different cookie. For the record, the only way to actually 'delete' a cookie is to physically delete the cookie file on the client computer (for cookies that were set with a non-zero expire time) or to close all instances of the browser (for a cookie that was set with a zero expire time.) Once a cookie has been set, the only thing a web-server-side script or client-side javascript can do to it is to change the value or change the expire time, by setting the same cookie again with a new value or expire time. To 'delete' a cookie in this way, you are actually either setting the value to something that will cause the cookie to be 'ignored' by code using that value or to an expire time in the past so that the browser won't send the cookie to the server with the page request. @Nosbod, if your session id cookie was originally set without a domain parameter, the setcookie() statement that matches that cookie would also need to have no domain parameter.

Unsetting php variables has nothing to do with the question "How to delete session cookies?"

Any chance you have a $_COOKIE['test'] that only matches your root folder AND register_globals are on so that the cookie is overwriting your session variable with the same name 'test'? All indications are that your $_SESSION variable is getting overwritten. Have you tried using a different name than test?

Any .htaccess files in either or both the admin and root folder that could be affecting the session settings? I recommend that you echo session_id(); after the session_start() statements so that you can see if/when the session id is changing.

Add the following three lines of code after your first opening <?php tag and before your session_start() statement on both pages - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(E_ALL);

A url with the www. on it and a url without the www. on it is not switching domains, but sessions won't match both unless you set the session cookie parameters correctly. It sounds like your code on the page in the root folder is clearing the session variables. You would need to post your code if you want help with what it is doing.

Are you switching back and forth between url's that have and don't have the www. on them and/or what does a phpinfo(); statement show for the session.cookie_path setting?

Web servers are not designed to do what you are trying to do. Even if you get it to work on your current web server/php/browser combination, there is a good chance that it will stop working when either of those three things are changed, due to all the buffering and compression that goes on (your current problem could be due to something at your end of the connection, such as a proxy server your ISP is using on your connection.) If you want to output discrete pieces of information and have each of them displayed 'real time', you must use AJAX to periodically make http requests to a web page and have that page output the current information.

Sounds to me like the From: address you are using is not hosted at the sending mail server so the mail server thinks you are trying to relay email through it and it is requiring that SMTP Authentication be used. Is the From: address hosted at the sending mail server? It should be, which will also likely eliminate the need to use SMTP Authentication.

That's only the code that is checking the session variables. What about the code that is setting them or the code somewhere on your page that could be clearing them. Because you did not get errors about the whole $_SESSION not existing or an Undefined index error for $_SESSION['logged_in'], that implies that your code is setting 'logged_in' but is not setting 'accesslevel'. Best guess is that the part of your log in code that gets data from the database is not working and is not telling you what it is doing when it does not work. You could also have some code that either relies on register_globals to set same name session/cookie/program variables and your web host finally turned register_globals off (8 years too late) or you have some same name session/cookie/program variables and your web host managed to turn register_globals on and your variables are getting overwritten. Frankly, you are asking us what your code is doing without seeing your code. The quickest solutions come in help forums when you present all the relevant information and code so that someone can directly see the big picture and/or duplicate the problem.

For debugging, add the following immediately after the first opening <?php tag on the main pages involved in the problem (both where you log in and where you are being told access denied) - ini_set("display_startup_errors", "1"); ini_set("display_errors", "1"); error_reporting(E_ALL); And while your code might not have changed, seeing what method you are using in your code generally narrows down and suggests what could have been changed on the server that could cause the symptoms.

You probably have links/redirects that are switching between www. and no www. on the URL's and your need to setup the session.cookie_domain to match both versions of your domain or you need to force any non-www. request to redirect to the corresponding www. address.

How do you know other mysql_ functions are working? You could for example have the mysql_connect and mysql_select_db in an include file that is not being included, so there is no fatal error associated with them. What's your complete code?

The setcookie() section in the php manual shows how to delete a cookie.